Repository navigation
Publish PowerShell NuGet packages for Linux/OSX platforms #3417
Description
Activity
- added this to the milestone
on Mar 25, 2017 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.Automationas 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.0will 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.dllin PowerShell Core, as well as the runtime assemblies for both Win and Unix platforms, including the native dynamic librarylibpsl.sothat powershell depends on in Unix plats.- This NuGet package is supposed to be used by any
netcoreapp2.0application that needs to host PowerShell Core.
- This NuGet package is supposed to be used by any
-
- modified the milestones: ,
on May 15, 2017 - modified the milestones: ,
on May 15, 2017 35 remaining items
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 Maybe it's because you are still building your application targeting a Windows System.Management.Automation ref assembly. The
Eventingdll 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) 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?
Reacted by Dinesh Kumar PI 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) 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).
Reacted by Ian ByrneIan Byrne (@ianByrne) The PR for the required script changes is out #6167. Once this is merged, I will release the nuget packages.
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>
Reacted by slchIan Byrne (@ianByrne) Thanks for the feedback. I am having a look.
/cc Dan Travison (@dantraMSFT)
Ian Byrne (@ianByrne) The
libpsrpclient.soandlibmi.soseem to be placed under theruntimes/linux-x64/nativefolder during thedotnet publishstep.A workaround for the issue is to use:
dotnet publish --runtime linux-x64If a specific runtime is chosen at build time, then the issue with runtimes folder is mitigated.
Aditya Patwardhan (@adityapatwardhan) I ran
dotnet publish -c Release --runtime linux-x64but 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/publishdir: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.dllIan Byrne (@ianByrne) Sorry I forgot to mention. Add the package
psrpto your csproj. https://powershell.myget.org/feed/powershell-core/package/nuget/psrpThanks 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) Found the root cause. Filed issue #6281
Reacted by Ian Byrne
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 packdoesn'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