Powershell: Cannot load Microsoft.PowerShell.Diagnostics when using the SDK on .Net Core on Windows

[svick]

Steps to reproduce

1. Use Windows 10, dotnet CLI preview 2; don't install PowerShell Core.
2. Create a .Net Core project that references Microsoft.PowerShell.SDK version 1.0.0-alpha9 from the powershell-core MyGet feed.

3. Add the following code to Program.cs:

   ``` c#
   using System.Management.Automation;

   public class Program
   {
   public static void Main()
   {
   var ps = PowerShell.Create();

      ps.AddCommand("gci");
   
      ps.Invoke();
   

   }
   }
   ```

   The complete project is here.

4. dotnet restore, dotnet run.
   

   Expected behavior

ps.Invoke() does not throw.

Actual behavior

ps.Invoke() thows:

System.Management.Automation.Runspaces.PSSnapInException: Cannot load Windows PowerShell snap-in Microsoft.PowerShell.Diagnostics because of the following error: Could not load file or assembly 'Microsoft.PowerShell.Commands'. The system cannot find the file specified.
   at System.Management.Automation.Runspaces.RunspaceConfigForSingleShell.LoadMshSnapinAssembly(PSSnapInInfo mshsnapinInfo)
   at System.Management.Automation.Runspaces.RunspaceConfigForSingleShell.LoadPSSnapIn(PSSnapInInfo mshsnapinInfo)
   at System.Management.Automation.Runspaces.RunspaceConfigForSingleShell.LoadPSSnapIns(Collection`1 mshsnapinInfos, PSConsoleLoadException& warning)
   at System.Management.Automation.Runspaces.RunspaceConfigForSingleShell.LoadConsole(PSConsoleLoadException& warning)
   at System.Management.Automation.Runspaces.RunspaceConfigForSingleShell.CreateDefaultConfiguration()
   at System.Management.Automation.Runspaces.RunspaceConfiguration.Create()
   at System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace(PSHost host)
   at System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace()
   at System.Management.Automation.PowerShell.Worker.CreateRunspaceIfNeededAndDoWork(Runspace rsToUse, Boolean isSync)
   at System.Management.Automation.PowerShell.CoreInvokeHelper[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
   at System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
   at System.Management.Automation.PowerShell.CoreInvoke[TOutput](IEnumerable input, PSDataCollection`1 output, PSInvocationSettings settings)
   at System.Management.Automation.PowerShell.Invoke(IEnumerable input, PSInvocationSettings settings)
   at System.Management.Automation.PowerShell.Invoke()
   at Program.Main()

Puzzling things I found when looking into this:

• There is no package for Microsoft.PowerShell.Commands.Diagnostics.
• PSSnapInReader.DefaultMshSnapins contains Microsoft.PowerShell.Diagnostics only when UNIX is not set. But there is only one netstandard1.6 version of System.Management.Automation.dll in the System.Management.Automation 1.0.0-alpha9 package, compiled without the UNIX flag set.
• PSSnapInInfo.AbsoluteModulePath treats the ModuleName of Microsoft.PowerShell.Commands.Diagnostics as file name with extension and returns just Microsoft.PowerShell.Commands (as shown in the exception message above).

[JanivZ]

Can verify this reproduces

[vors]

Thank you for reporting it @svick !

Indeed, the nuget package provided Microsoft.PowerShell.SDK for alpha9 has windows-specific implementation.
The scenario that you are describing (hosting PS in you own program) is not currently supported. There are mulitply issues that we need to address first to enable it. Here are few:

• Remove need in custom Assembly Load Context (ALC for short). This is CoreCLR hosting model and we are blocked until CoreCLR will have an equivalent of AppDomain.GetAssemblies(). This is the biggest issue and external blocker for us.
• Create nuget packages that contains both unix and windows compiled assemblies.
• Publish Microsoft.PowerShell.Diagnostics nuget package (the current list is here)

The scenario that we are targeting with current Microsoft.PowerShell.SDK is the following:
You should be able to author a binary powershell module and use it later in the powershell session.

[enriquelk]

I am doing the following as a workaround, but it is not ideal. Anyone knows of a better way to use powershell from dotnet core linux?

        ProcessStartInfo psi = new ProcessStartInfo();
        psi.FileName = "powershell";
        psi.UseShellExecute = false;
        psi.RedirectStandardOutput = true;

        psi.Arguments = "Get-Host";
        Process p  = Process.Start(psi);
        string strOutput = p.StandardOutput.ReadToEnd();
        p.WaitForExit();
        Console.WriteLine(strOutput);

[sonphnt]

Hi @svick

Did you find out the way to execute PS file in .Net core?
I have installed .Net core 2.0 preview but it does not seems to work.

[WilliamWsyHK]

How's the progress of "hosting PS in you own program" doing?
I need this feature badly. :sweat_smile:

[jherby2k]

I'm encounting this issue now, trying to unit test a binary module I am writing for PowerShell core. This is a big issue! Any workaround??

Still an issue with .NET core 2.0 (rtm) test project and PowerShell Core 6.0.0 beta 6.

[michaelherndon]

@sonphnt, @WilliamWsyHK, @jherby2k

It works, but it's not like the old way where you just reference System.Management.Automation. I ran into the same issue and found this page. Then I started to look in the docs in the repo and found:
https://github.com/PowerShell/PowerShell/tree/master/docs/host-powershell

There is a sample app here: https://github.com/PowerShell/PowerShell/tree/master/docs/host-powershell/sample-dotnet2.0-powershell.beta.3

you need to copy the Nuget.config from the project. If you're using VS, target the powershell feed withing the UI.

then install the following packages

    <PackageReference Include="Microsoft.PowerShell.SDK" Version="6.0.0-beta.7" />
    <PackageReference Include="Microsoft.WSMan.Management" Version="6.0.0-beta.7" />
    <PackageReference Include="Microsoft.PowerShell.Commands.Diagnostics" Version="6.0.0-beta.7" />

[iSazonov]

@SteveL-MSFT Can we close the Issue because we update nuget SDK package and docs?

[ahmadalli]

I'm getting the same exception in version 6.0.1

[SteveL-MSFT]

A new nuget package is being published (6.0.1.1) which will include cross platform runtimes instead of being Windows specific. Should be this week.

[cosminstirbu]

This is still reproducing for me with <PackageReference Include="System.Management.Automation" Version="6.2.2" /> on Windows 10 with dotnet test

[iSazonov]

@cosminstirbu Please open new issue with repo steps.

[steinbachio]

@cosminstirbu for me it was enough to install Microsoft.PowerShell.SDK (6.2.3)

[cosminstirbu]

Yeap, I confirm that installing Microsoft.PowerShell.SDK (6.2.3) did the trick.