Powershell: Background operator (&) seems to have dependency on Windows PS

[bergmeister]

The new implicit remoting to WinPS in preview6 brings this to light.

Steps to reproduce

git push &

Expected behavior

Creates background job using Start-Job and returns job object.

Actual behavior

There is warning, which tells me that for some of its work, Windows PowerShell is involved, I though it was just Start-Job with no dependency on WPS

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.0-preview.6
PSEdition                      Core
GitCommitId                    7.0.0-preview.6
OS                             Microsoft Windows 10.0.18362
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[jhoneill]

I had the same message in VS code for no obvious reason this afternoon. And on my home pc
cmd /c dir &
gets the result above
I tried breaking the psscheduledJob module (take ownership and assign full control, and rename the psd1 file).
cmd /c dir & still works, but the module is not loaded and the message doesn't appear. So I think this is something odd about that module, not the & operator.

[vexx32]

/cc @PaulHigin

@jhoneill I'd try to repro without your profile loaded, as you may have some code in your profile that is triggering the attempted loading of the winPS module.

[SteveL-MSFT]

This is already fixed via https://github.com/PowerShell/PowerShell/pull/11194

This happens because when using a PSJob cmdlet, PowerShell will try to import modules that implement the JobAdapter. With the new WinPS code path, it imports ScheduledJob module since it implements JobAdapter. It does this because ScheduledJob (along with PSWorkFlow) support serialized jobs. This means that when you do Get-Job, it will find and show these jobs. But to be able to do that, it has to load those modules and get them to enumerate their jobs. Since ScheduledJob doesn't actually work with PowerShell 7 and PSWorkFlow is already not supported, the fix is to not automatically load these two modules.

[jhoneill]

/cc @PaulHigin

@jhoneill I'd try to repro without your profile loaded, as you may have some code in your profile that is triggering the attempted loading of the winPS module.

Just tried that ... no change :-( It's possible that some of the other cases where modules autoload for reasons I can't see _are_ caused by something in my profile. But it happens rarely and I haven't stopped what I've been doing to investigate, so I don't have any kind of pattern of "x will auto-load if I do Y". It sounds like Steve has explained what causes this module to load and there is already a fix in the works :-)

@SteveL-MSFT so it still tries to load modules which implement the jobadapter but has a hard coded exception for one or two ?

[bergmeister]

Thanks, I can confirm, it is not happening any more with the daily build