Powershell: .NET Core 3.0 port

[SteveL-MSFT]

This issue is for tracking known issues with the 3.0 port happening in the feature-netcore30 branch.

• [x] PackageManagement failing (the prompt to install nuget provider causes tests to timeout)
• [x] WebListener not accepting connections on Windows
• [x] symlink tests failing
• [x] Measure-Object and Json tests failing due to change in precision
• [x] Import-Module tests failing on Windows
• [x] Get-Module tests failing on Windows
• [x] Constrained mode test failures on Windows
• [x] CompatiblePSEditions tests/Get-Module tests
• [x] #Requires tests

@edyoung can you have someone look at the PackageManagement failures? It causes other tests to fail that depend on it

Thanks @markekraus for fixing weblistener and now the tests are passing on Windows!

[markekraus]

Initial digging:

$WL = Start-WebListener
$WL[-1].Job.ChildJobs[0].Output

appEXE: C:\Git\PowerShell\test\tools\WebListener\bin\WebListener.exe
serverPfxPath: C:\Users\MarkLocal\AppData\Local\Temp\ServerCert.pfx
serverPfxPassword: ***********
HttpPort: 8083
Https: 8084
Tls11Port: 8085
TlsPort: 8086
info: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[0]
      User profile is available. Using 'C:\Users\MarkLocal\AppData\Local\ASP.NET\DataProtection-Keys' as key repository and Windows DPAPI to encrypt keys at rest.
info: Microsoft.AspNetCore.Server.HttpSys.HttpSysListener[0]
      Start
info: Microsoft.AspNetCore.Server.HttpSys.HttpSysListener[0]
      Listening on prefix: http://localhost:5000/
Hosting environment: Development
Content root path: C:\Git\PowerShell\test\tools\WebListener\bin
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.

I can access the HTTP site on http://localhost:5000, but not on any of the bindings which should be there. I'm going to guess that ASP.NETCore has changes up the bindings again. More to come.

[markekraus]

9427 for the WebListener fixes.

[SteveL-MSFT]

@rjmholt can you look at the CompatiblePSEditions/Get-Module test failures and the #Requires tests (look related)

[rjmholt]

@SteveL-MSFT Just ran the CompatiblePSEditions tests with the netcore3 branch on my machine and got no failures. Do you have a reference build for the current failures? Is there CI on the netcore3 branch?

[rjmholt]

Get-Module tests also just passed for me

[rjmholt]

As did #requires tests.

This is all on Windows btw

[SteveL-MSFT]

@rjmholt it might be due to a behavior change with long paths. See my latest PR for failures: https://github.com/PowerShell/PowerShell/pull/9447. You might be able to repro it by creating a local user with a long name.

[rjmholt]

Looks like there's a problem loading psm1s off the module path

[rjmholt]

I've got repros (although I'm now a new user, so my environment is very weird...). I don't think this can/should be fixed in the tests themselves -- I suspect path comparisons are failing inside PowerShell. It's something that's always been done badly inside the module cmdlet code, because there's no common abstraction for Path resolution.

Is there an explanation of the long path phenomenon occurring here (not long paths, but the way they're being shortened)?

[iSazonov]

is MSFT team working on https://github.com/dotnet/coreclr/issues/24064 internally or we should do this in the repo publicly?

[rjmholt]

@SteveL-MSFT In the case of the Get-Module tests, it's just been a matter of calling Resolve-FilePath on $TestDrive and subbing out the variable. Which makes me think the right solution is your PR on Pester

[SteveL-MSFT]

@iSazonov already working internally with .NET Core team on best configuration for pwsh startup perf

@rjmholt For now, can you make the change to use Resolve-FilePath so the tests pass? Once we have an updated Pester with my change available on PSGallery, we can bulk remove use of that helper function.

[edyoung]

See https://github.com/OneGet/oneget/pull/443

[adityapatwardhan]

Fixed by #9597