Powershell: [Preview6] [PSWindowsPowershellCompatibility] *-Job cmdlets load PSScheduledJob module in WinCompat

[JustinGrote]

Steps to reproduce

Enable WinCompat Experimental Feature

PS> start-threadjob 'test'
Start-ThreadJob: Invalid file path extension.  Extension should be .ps1.
WARNING: Module PSScheduledJob is loaded in Windows PowerShell using WinPSCompatSession remoting session; please note that all input and output of commands from this module will be deserialized objects. If you want to load this module into PowerShell Core please use 'Import-Module -SkipEditionCheck' syntax.

Notes

Start-Threadjob doesn't try to load psscheduledjob if experimental feature is disabled.

[anmenaga]

Yes, PSScheduledJob module is not-Core-compatible; and currently starting any job attempts to load PSScheduledJob module and fails quietly. With WinCompat enabled, module is getting loaded and that generates the warning.
It is an interesting side discussion: why starting a job is supposed to autoload a module that user never wanted to load.

As mentioned in original post, experimental feature can be disabled to prevent this; also WinCompat RFC discusses more narrow 'wincompat module blacklist' mechanism, feel free to provide your opinion on this.

[lzybkr]

This warning fires when calling Get-Job as well, and I think it is just as surprising.

[jazzdelightsme]

I just filed #11166, because this one looked specific to Start-ThreadJob/PSScheduledJob. But actually sounds like it's the same thing.

(and I would expect Start-Job to just work with no warnings or twiddling of experimental features)

[anmenaga]

@lzybkr , right. JobCmdletBase.BeginProcessing() -> CommandDiscovery.AutoloadModulesWithJobSourceAdapters

[JustinGrote]

@anmenaga can you reference the 'original post' you referred to? Is that the RFC?

I don't think it's reasonable once Wincompat goes GA that if I want to use Start-Threadjob natively in PS7 I have to add PSScheduledJob to a blacklist right off the bat, that's a huge usability issue, so either:

• adjust the code to not try to autoload PSScheduledJob on PS Core (potentially breaking but best option)
• add it to the blacklist by default (bad option, not very discoverable)
• fix PSScheduledJob to be core compatible at least for Windows (doesn't need a xplat implementation)

[anmenaga]

@JustinGrote thank you for your feedback;

I was referring to your original post :) where you mentioned the workaround Start-Threadjob doesn't try to load psscheduledjob if experimental feature is disabled.

[SteveL-MSFT]

The current behavior to auto load modules with job source adapters is causing this side effect. I agree that it's surprising as the user shouldn't be aware of this implementation detail. Perhaps we should update the AutoloadModulesWithJobSourceAdapters to explicitly not use PSWindowsPowerShellCompatibility when loading modules.

[JoeSalmeri]

@SteveL-MSFT

I too was surprised by this behavior and am still a little confused by what is going on.

In my profile I create a function which runs whenever I exit PS.

I created the function to detect if any jobs exist or if any PSSessions exist in the current session and to prompt to confirm the exit if either exists.

I originally created the function because I only use SSH remoting which is not supported by Disconnect-PSSession (which only supports WSMan remoting) and wanted to be warned before those SSH PSSessions were lost and then later modified the function to also call Get-Job to check for any jobs run in the current session.

After installing PS 7 preview 6, the first time I exited PS, my function ran and showed the WinPSCompatSession as existing.

At first I was not sure what commands I had executed which created that session but after some experimentation I found that it was created when my "exit" function ran the Get-Job command to check for any jobs created.

"Get-Command Get-Job" shows that the Cmdlet version is 7.0.0.0 and the source of the command
is Microsoft.PowerShell.Core so I am still somewhat unclear why compatibility mode would be needed?

Are you saying this is a bug with the autoloading of modules or is compatibility mode really needed for "jobs"?

Are there any plans for Disconnect-PSSession to support disconnecting a remote PSSession that uses SSH?

On my Linux machines, I always use the Screen program so that I can easily disconnect and reconnect to the remote SSH sessions and was hoping that Disconnect-PSSession would also provide similar functionality from PS.

[msftbot[bot]]

:tada:This issue was addressed in #11194, which has now been successfully released as v7.0.0-rc.1.:tada:

Handy links:

• Release Notes