Publish PowerShell NuGet packages for Linux/OSX platforms

PowerShell Core builds separately for Windows and Unix, so the assemblies are different between Windows and Unix platforms. All PowerShell Core packages we published so far contain windows assemblies only.

The ideal solution is to have one package that contains assemblies for both Windows and Unix platforms. But dotnet pack doesn't seem to support this.

This is blocking hosting powershell in .NET Core applications on Linux/OSX.
The discussion of this issue originates from #3409

We need to publish the Windows version of the packages to NuGet as well.

Note: This issue seems very similar to #1152

I think we want a single set of reference assemblies for portability. If we have platform specific APIs, then hopefully there is a way to refactor those into another assembly if need be.

Take System.Management.Automation as an example, I think we will eventually end up with 2 set of NuGet packages:

A NuGet package that only contains the reference assembly. This will be the PowerShell Standard reference assembly, which exposes an API surface that is supported by both Windows PowerShell and PowerShell Core. But the API surface will a subset of the actual publish APIs exposed in Windows PowerShell or PowerShell Core.
- This reference assembly is an abstraction that doesn't have any runtime implementation that exactly maps to it, so there won't be any runtime DLLs in this NuGet package.
- This NuGet package is the friend of powershell binary module authors. Binary modules targeting this NuGet package and netstandard2.0 will theoretically work on both Windows PowerShell and PowerShell Core.
A NuGet package that is specific for PowerShell Core. It contains the reference assembly that exposes all public APIs from the latest System.Management.Automation.dll in PowerShell Core, as well as the runtime assemblies for both Win and Unix platforms, including the native dynamic library libpsl.so that powershell depends on in Unix plats.
- This NuGet package is supposed to be used by any netcoreapp2.0 application that needs to host PowerShell Core.

Dongbo Wang (@daxian-dbw)

As per Dongbo Wang (@daxian-dbw) workaround, I have replaced the powershell assemblies with those from a Linux/OSX package. But, I am getting the following error when starting the application.
Unhandled Exception: System.TypeInitializationException: The type initializer for 'System.Management.Automation.Runspaces.RunspaceFactory' threw an exception. ---> System.IO.FileLoadException: Could not load file or assembly 'Microsoft.PowerShell.CoreCLR.Eventing, Version=6.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

When checking the powershell assemblies of Linux/OSX package, all are having file version 1.0.0.0. Please help me on this issue?

michaelrajece

michaelrajece Maybe it's because you are still building your application targeting a Windows System.Management.Automation ref assembly. The Eventing dll is only available on Windows platform.

Aditya Patwardhan (@adityapatwardhan) is about to finish this nuget packaging work. Hopefully, we will be able to use it soon.

Dongbo Wang (@daxian-dbw)

Dongbo Wang (@daxian-dbw) Thanks for your update. When Replacing the System.Management.Automation dll with those from a Linux/OSX package is also failed with the same assembly's manifest definition mismatch error.
Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'System.Management.Automation, Version=6.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

So, How can I overcome this issue?

Aditya Patwardhan (@adityapatwardhan)

I am actively working on it right now. Hopefully will be done in just a few days.

Aditya Patwardhan (@adityapatwardhan) are there any updates on when this may be available?

Ian Byrne (@ianByrne)

Ian Byrne (@ianByrne) Sorry for the late response. I am currently testing the nuget packages and we are targeting a release by the end of next week (2/23).

Ian Byrne (@ianByrne)

Ian Byrne (@ianByrne) The PR for the required script changes is out #6167. Once this is merged, I will release the nuget packages.

Aditya Patwardhan (@adityapatwardhan)

Thanks Aditya Patwardhan (@adityapatwardhan) and Dongbo Wang (@daxian-dbw) for implementing this fix. I have tried my application with these new versions, however am still having some issues - are they related to this? Or am I doing something completely wrong.

Error:

This parameter set requires WSMan, and no supported WSMan client library was found. WSMan is either not installed or unavailable for this system.: Unable to load DLL 'libpsrpclient': The specified module or one of its dependencies could not be found

Code:

WSManConnectionInfo connectionInfo = new WSManConnectionInfo(new Uri("https://outlook.office365.com/powershell-liveid"), "http://schemas.microsoft.com/powershell/Microsoft.Exchange", new PSCredential(username, password));
connectionInfo.AuthenticationMechanism = AuthenticationMechanism.Basic;
connectionInfo.MaximumConnectionRedirectionCount = 2;

using (PowerShell ps = PowerShell.Create())
{
    ps.Runspace = RunspaceFactory.CreateRunspace(connectionInfo); // Exception gets thrown here
}

csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <RuntimeIdentifiers>linux-x64</RuntimeIdentifiers>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.PowerShell.SDK" Version="6.0.1.1" /> 
    <PackageReference Include="Microsoft.PowerShell.Commands.Diagnostics" Version="6.0.1.1" />
    <PackageReference Include="Microsoft.WSMan.Management" Version="6.0.1.1" />
  </ItemGroup>

</Project>

Ian Byrne (@ianByrne)

Ian Byrne (@ianByrne) Thanks for the feedback. I am having a look.

Dan Travison (@dantraMSFT)

/cc Dan Travison (@dantraMSFT)

Ian Byrne (@ianByrne) The libpsrpclient.so and libmi.so seem to be placed under the runtimes/linux-x64/native folder during the dotnet publish step.

A workaround for the issue is to use:
dotnet publish --runtime linux-x64

If a specific runtime is chosen at build time, then the issue with runtimes folder is mitigated.

Aditya Patwardhan (@adityapatwardhan)

Aditya Patwardhan (@adityapatwardhan) I ran dotnet publish -c Release --runtime linux-x64 but these two files do not seem to get created. Am I missing a reference or some other dependency?

This is the contents of my /bin/Release/netcoreapp2.0/linux-x64/publish dir:

libpsl-native.so
linuxtest.deps.json
linuxtest.dll
linuxtest.pdb
Microsoft.ApplicationInsights.dll
Microsoft.CodeAnalysis.CSharp.dll
Microsoft.CodeAnalysis.dll
Microsoft.Management.Infrastructure.dll
Microsoft.Management.Infrastructure.Native.dll
Microsoft.PowerShell.Commands.Management.dll
Microsoft.PowerShell.Commands.Utility.dll
Microsoft.PowerShell.ConsoleHost.dll
Microsoft.PowerShell.CoreCLR.Eventing.dll
Microsoft.PowerShell.SDK.dll
Microsoft.PowerShell.Security.dll
Microsoft.Win32.Registry.AccessControl.dll
Newtonsoft.Json.dll
System.Data.SqlClient.dll
System.IO.Packaging.dll
System.Management.Automation.dll
System.Net.Http.WinHttpHandler.dll
System.Private.ServiceModel.dll
System.Security.AccessControl.dll
System.Security.Cryptography.Pkcs.dll
System.Security.Permissions.dll
System.Security.Principal.Windows.dll
System.ServiceModel.dll
System.ServiceModel.Duplex.dll
System.ServiceModel.Http.dll
System.ServiceModel.NetTcp.dll
System.ServiceModel.Primitives.dll
System.ServiceModel.Security.dll
System.ServiceProcess.ServiceController.dll
System.Text.Encoding.CodePages.dll
System.Text.Encodings.Web.dll
System.Threading.AccessControl.dll

Ian Byrne (@ianByrne)

Ian Byrne (@ianByrne) Sorry I forgot to mention. Add the package psrp to your csproj. https://powershell.myget.org/feed/powershell-core/package/nuget/psrp

Aditya Patwardhan (@adityapatwardhan)

Thanks Aditya Patwardhan (@adityapatwardhan) - I am now seeing those files. However, the application continues to throw at the same point with the same error, that the DLL is missing.

Ian Byrne (@ianByrne)

Ian Byrne (@ianByrne) Found the root cause. Filed issue #6281

Navigation Menu

Repository navigation

Publish PowerShell NuGet packages for Linux/OSX platforms #3417

35 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Publish PowerShell NuGet packages for Linux/OSX platforms #3417

Description

Activity

mirichmo commented on Mar 25, 2017

lzybkr commented on Mar 26, 2017

daxian-dbw commented on May 11, 2017

35 remaining items

michaelrajece commented on Jan 31, 2018

daxian-dbw commented on Feb 1, 2018

michaelrajece commented on Feb 1, 2018

ianByrne commented on Feb 8, 2018

adityapatwardhan commented on Feb 14, 2018

adityapatwardhan commented on Feb 15, 2018

ianByrne commented on Feb 28, 2018

adityapatwardhan commented on Feb 28, 2018

adityapatwardhan commented on Feb 28, 2018

ianByrne commented on Feb 28, 2018

adityapatwardhan commented on Feb 28, 2018

ianByrne commented on Feb 28, 2018

adityapatwardhan commented on Mar 1, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions