-
Notifications
You must be signed in to change notification settings - Fork 7.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
psrp is unable to load libmi from nuget cache #6281
Comments
For those hitting this issue, such as PowerShell hosts, the work around is to build targetting a specific platform. This will place the binaries from the psrp and mi packages directly in the output directory with the app itself. |
Hi @dantraMSFT - I am targeting linux-x64 in both my publish command, and my csproj file: <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" />
<PackageReference Include="psrp" Version="1.4.1" />
</ItemGroup>
</Project> The files do indeed get placed into the same output directory as the app itself, however when the app is run I still receive the above error. |
@ianByrne: I'm still working on a viable solution to this. |
Thanks for the tip @dantraMSFT , however I haven't had any luck. I am testing this using a docker image (built on a Linux machine): FROM microsoft/dotnet:2.0-sdk
WORKDIR /app
RUN mkdir /app/src
COPY . ./src
RUN dotnet publish ./src/testapp/testapp.csproj -c Release -o /app/ --runtime linux-x64
RUN cp ./libmi.so /root/.nuget/packages/psrp/1.4.1/runtimes/linux-x64/native/libmi.so
WORKDIR /root/.nuget/packages/psrp/1.4.1/runtimes/linux-x64/native
RUN ls
WORKDIR /app
ENTRYPOINT ["dotnet", "testapp.dll"] The build output reveals that the two files are indeed in the
However, on running the app, same error. |
@dantraMSFT do you have any other suggestions for a workaround, or an ETA of when it may get resolved? Thanks |
How is this even supposed to work? And what kind of nuget package is psrp anyway? Since when are we using packages that are only applicable to certain OS? Why isn't it just part of the Microsoft.WSMan.Management? Native libraries for certain OS is done all the time isn't it? Running the project on a Linux Machine with the SDK also does not work. The files are present in my .nuget folder but I still get |
By the way: Copying However this requires the the app to be run from the SDK Looking at your Dockerfile, you are both exporting the app to run without a dotnet Runtime by specifying --runtime and starting it from the SDK anyway. |
I'll be releasing a nuget package by EOW that solves the problem on Linux by incorporating libmi into the psrp package. Building with and without --runtime or --output works as expected. On macOs, the results are more limited. Currently, it will only work when building for a specific runtime. FYI: the reason we're hitting this problem is due to RPATH usage in psrp and mi. Both are configured to work with PowerShell Core which builds to a specific runtime and third party binaries are restored to the bin directory at build time. I'll post again when I've published the packages. |
Release 1.4.2-2 (https://github.com/PowerShell/psl-omi-provider/releases/tag/v1.4.2-2) has been published. |
Thanks @dantraMSFT and @adityapatwardhan - I can see that the psrp package was updated on the 20th, although I still seem to be struggling with this... Can you see where I'm going wrong? NuGet.conf <?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
<add key="dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />
<add key="powershell-core" value="https://powershell.myget.org/F/powershell-core/api/v3/index.json" />
</packageSources>
</configuration> PSTest.csproj <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<RuntimeIdentifiers>linux-x64</RuntimeIdentifiers>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.PowerShell.Commands.Diagnostics" Version="6.0.2" />
<PackageReference Include="Microsoft.PowerShell.SDK" Version="6.0.2" />
<PackageReference Include="Microsoft.WSMan.Management" Version="6.0.2" />
<PackageReference Include="psrp" Version="1.4.2" />
</ItemGroup>
</Project> Dockerfile FROM microsoft/dotnet:2.0-sdk
WORKDIR /app
RUN mkdir /app/src
COPY . ./src
RUN dotnet publish ./src/PSTest.csproj -c Release -o /app/ --runtime linux-x64
# Have also tried without --runtime linux-x64
# Have also tried copying the file directly:
# RUN mkdir -p /root/.nuget/packages/psrp/1.4.1/runtimes/linux-x64/native
# RUN cp ./libmi.so /root/.nuget/packages/psrp/1.4.1/runtimes/linux-x64/native/libmi.so
WORKDIR /app
ENTRYPOINT ["dotnet", "PSTest.dll"] Program.cs using System;
using System.Management.Automation;
using System.Management.Automation.Runspaces;
namespace PSTest
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Creating PowerShell");
PowerShell powerShell = PowerShell.Create();
Console.WriteLine("Creating runspace");
powerShell.Runspace = RunspaceFactory.CreateRunspace(new WSManConnectionInfo()); // Throws exception
Console.WriteLine("We didn't make it this far");
}
}
} Output
The Docker image is being built on a VSTS Hosted Linux Preview agent, and is being run on an AWS Fargate ECS cluster. |
The manual workaround of copying libmi to a 1.4.1 directory is not likely to solve the problem. From your build steps, you should expect to see the update libpsrpclient.so and libmi.so binaries in the --output directory (-o app) and running your app from that directory should work. |
Good point 😁 I forgot to update that when I changed to 1.4.2... I'll add some steps to peek into the /app/ dir to ensure that the files are indeed there, and will also try to explicitly delete from the nuget cache. Might not get around to this for another couple days so will report back then. |
psrp
nuget package haslibpsrpclient.so
which depends onlibmi.so
.When an netcore app adds reference to
psrp
nuget package in its csproj and executesdotnet publish
, both the nuget packages are downloaded to nuget cache.libpsrp.so
expects thelibmi.so
to be present in the same folder, butlibmi.so
is located in the nuget cache under it's package folder.Example:
Location of
psrp
in nuget cache./home/user/.nuget/packages/psrp/1.4.1/runtimes/linux-x64/native/libpsrpclient.so
Location of
libmi
in nuget cache./home/user/.nuget/packages/libmi/1.4.101000/runtimes/linux-x64/native/libmi.so
psrp
expectslibmi.so
to be at/home/user/.nuget/packages/psrp/1.4.1/runtimes/linux-x64/native/
Thanks @ianByrne for finding the issue.
Steps to reproduce
Sample located at: #3417 (comment)
Expected behavior
Actual behavior
Error:
Environment data
The text was updated successfully, but these errors were encountered: