Powershell: dotnet fires a resolve event for "System.Core.dll", when it should not

[andschwa]

The "deprecated" PsSnapIn system believes that System.Management.Automation.dll depends on System.Core.dll, which is false when building for .NET Core. Unfortunately, PowerShell (through the InitialSessionState constructor CreateDefault2()) still uses the PsSnapIn system to load the SMA assembly, and so throws an internal exception when it can't find System.Core.dll.

The PsSnapIn system really needs to be fully removed.

[joeyaiello]

@JamesWTruher: "Please add a stack trace"

[andschwa]

Unfortunately, the latest versions of VS Code no longer debug very well...

[andschwa]

"Could not load file or assembly 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified under any probing paths." [string]

At:

Unfortunately, VS Code doesn't support capturing that stack trace as text :frowning:

[andschwa]

@BrucePay Do you know what's causing this?

[andschwa]

@lzybkr Could you help me out with this some time?

[andschwa]

Repro: run PowerShell in debugger with "uncaught exception" allowed.

[vors]

@andschwa this issue is unrelated to Snapins system.
The stack trace indicates that it's comming from static ctor of PSVersionInfo.

It looks like dotnet core problem with custom ALC.
Here is a minimal repro that doesn't include anything from PS, except our ALC.
They still fire the event to resolve System.Core.
System.Core is a reference assembly, all the types are forwarded into the implementation assembly from it.

using System.Management.Automation;
namespace Microsoft.PowerShell
{
    /// <summary>
    /// Defines an entry point for the .NET CLI "powershell" app
    /// </summary>
    public sealed class ManagedPSEntry
    {
        /// <summary>
        /// Starts the managed MSH
        /// </summary>
        /// <param name="args">
        /// Command line arguments to the managed MSH
        /// </param>
        public static int Main(string[] args)
        {
            // Open PowerShell has to set the ALC here, since we don't own the native host
            PowerShellAssemblyLoadContextInitializer.SetPowerShellAssemblyLoadContext(string.Empty);          

 System.Console.WriteLine(System.Diagnostics.FileVersionInfo.GetVersionInfo("/Users/vors/dev/PowerShell/debug/powershell").FileVersion.ToString());
            return 0;
        }
    }
}

[vors]

Since it's external, I will keep issue around for references.
We don't needed this for 0.6.0.

[andschwa]

System.Core is a reference assembly

That's a key piece of information right there.

I imagine this might not repro now with the catalog being automatically generated.

[andschwa]

Confirmed, this still repros with v6.0.0-alpha.10-8-gdd2394b1e608.

[iSazonov]

I can not repo - I think after we migrated to .Net Core 2.0 it's gone and we can close the Issue.

/cc @SteveL-MSFT @daxian-dbw

[daxian-dbw]

I cannot reproduce the issue either. We have stopped using a custom implementation of AssemblyLoadContext in powershell. Instead, we solely depend on the default loader (AssemblyLoadContext.Default) for loading assemblies. I think we can close this issue now.