Runtime packages not restoring properly?
SamVanheer opened this issue · 12 comments
I'm trying to use ClangSharp v9.0.0 beta from NuGet and i had a lot of trouble getting the libClang and libClangSharp native dependencies to load. I had to manually add the win-x64 runtime packages in order to have them deployed to the runtimes directory to be loaded.
Are we supposed to do this manually, or is NuGet supposed to automatically add the dependencies based on the main dependency specified in the libClang and libClangSharp packages? I'm not knowledgeable enough on NuGet to know what it can do so i'm at a loss here.
I think it's what you said, but just to be clear: I see the error loading libClangSharp even with:
<PackageReference Include="libClangSharp" Version="9.0.0-beta1" />However, the error goes away with:
<PackageReference Include="libClangSharp.runtime.win-x64" Version="9.0.0-beta1" />Yeah that's what i'm referring to. The native dependencies need to be manually added for it to load.
It is meant to automatically resolve them based on the host runtime identifier. I'll see if I can reproduce in a bit.
I actually assumed the root of my issue was that my code in in a class library, but this reproduces in a very simple console app.
I can repro.
The simple fix for now is to add <RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == '' AND '$(PackAsTool)' != 'true'">$(NETCoreSdkRuntimeIdentifier)</RuntimeIdentifier> to your project (under a PropertyGroup), unfortunately because of the way NuGet restore works, we can't just add this to a build/*.targets in the ClangSharp nuget package.
The issue is essentially that libClang and libClangSharp just contain a runtime.json file which point to the real packages. This was done to avoid users needing to download hundreds of megabytes just to consume ClangSharp (when they only need one of the native binaries most often). You can see some more details on the sizes here: #46 (comment), noting that that is the size of the compressed NuGet.
I had thought this was working for dev scenarios where the RID wasn't specified, but it apparently isn't. I'll log an issue on NuGet to see if this is something that can be improved.
I am getting following error when downloading libclangsharp from nuget.
"Install-Package : Could not install package 'libClangSharp.runtime.win-x64 9.0.0-beta1'. You are trying to
install this package into a project that targets '.NETFramework,Version=v4.6.1', but the package does not
contain any assembly references or content files that are compatible with that framework. For more
information, contact the package author."
Do I need to change my project .Net Framework to 2.0?
libClangSharp.runtime.win-x64 9.0.0-beta1 isn't meant to be referenced directly. You are meant to reference libClangSharp and specify a RuntimeIdentifier so NuGet downloads and resolves the correct assets.
Not sure if it's the SDK's responsibility or if this is something that could be fixed in ClangSharp, but in my case the issue was doubly confusing because the runtime picked up a random libclang.dll (version 5) that happened to be on my path. As you might imagine I was very confused why C++17 wasn't supported in the latest version of Clang.
Is there something we can do to make something complain when the RID is invalid/incompatible with the package? (I'm not particularly up to speed on how RIDs work in NuGet in the first place.)
The simple fix for now is to add
<RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == '' AND '$(PackAsTool)' != 'true'">$(NETCoreSdkRuntimeIdentifier)</RuntimeIdentifier>to your project (under aPropertyGroup), unfortunately because of the way NuGet restore works, we can't just add this to abuild/*.targetsin the ClangSharp nuget package.
I suppose this fixes the issue for regular dotnet build/dotnet publish scenarios, but the problem remains for dotnet pack'd global tools, right?
If so, if I don't mind the size increase of the package (in my case, I'm only using LLVM, not Clang, so it's not quite as bad), is there a way to explicitly include the RID-specific packages in my tool package for the RIDs I care about?
I'll log an issue on NuGet to see if this is something that can be improved.
@tannergooding Was an issue ever created?
No, there are a few existing issues that largely cover this, such as NuGet/Home#6083
ClangSharp and libClangSharp now provide a linux-x64 component which should assist in many scenarios "just working".
It's worth noting, however, this is a "best attempt" and LLVM/Clang themselves often need "per distro" and even "per distro version" builds for things to work end to end as expected.
As indicated above, the broader restore issue is an issue with NuGet and something that issues have been logged around.