I used Nuget package explorer to pack some third party DLLs into one package and published to my nuget server, many of my projects need refer to those third party DLLs and I don't want to add DLL references over and over again. With nuget I only need to install one package.
But after installing that package, i can see those DLLs in the packages folder, but I cannot use classes in those DLLs.
Is that possible to use classes in the DLLs of that nuget package?
Related
Background: I am using Visual Studio 2019 Professional Version 16.11.15, and NuGet Package Manager 5.11. I was provided some 3rd party assemblies to use for my .NET Standard 2.0 class library. These dlls were installed locally on my machine by an installer. I added them to my project via "Add Project Reference". Here's a screenshot of them working.
Goal: Create a NuGet package for my .NET Standard 2.0 class library to be used internally by our dev team. It should encapsulate these 3rd party dlls as part of it. But I keep running into dead ends.
Important note: Xceed does not host these .NET Standard assembly versions on nuget.org, purposefully making my life difficult it seems...
I have tried:
Using the "Generate NuGet package on build" in the Package section of the project properties. This option does not attach the 3rd party assemblies with it. This includes setting the Copy Local option to "Yes".
Adding these 3rd party dlls to their own NuGet packages via NuGet Package explorer following this answer. I tried several different flavors of folder structures:
placing the dll at the root
placing the dll inside a "lib" folder
placing the dll inside a "lib/netstandard2.0" folder
None of these options worked when adding the NuGet packages to my project. The references to the assembly namespace weren't resolving in the code.
Has anyone had any success doing something like this before?
It turns out I was running into the problem of the NuGet packages not refreshing when updating it. I followed this the first part of this answer to solve that.
When using the folder structure "lib/" inside the NuGet package, I was running into this warning:
Warning NU1701 Package 'Xceed.Document.NETStandard 2.3.2' was restored using
'.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2,
.NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1,
.NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8'
instead of the project target framework '.NETStandard,Version=v2.0'.
This package may not be fully compatible with your project.
Once I updated to use "lib/netstandard2.0/" inside the NuGet package, I was able to add the NuGet packages to my library successfully and compile. Great success!
I have a large project that needs to use several Nuget packages, but Nuget packages cannot be used on our corporate network. So I have extracted the dlls from all of the packages and linked directly to them instead. This package, however, does not have a dll: VideoLAN.LibVLC.Windows
Instead, it contains a large build folder with a lot of native libraries. How can I build this to create the dll and only the needed libraries? I don't need all of the different language libraries.
I have an internal NuGet package that is dependent on another NuGet package that has native dependencies. In a .NET SDK console application I am referencing the internal NuGet package and indirectly referencing the other NuGet package that has the native dependencies.
When the NuGet package with native dependencies is referenced indirectly, the native dependencies are not copied properly to the bin directory.
If the NuGet package with native dependencies is installed directly as a direct dependency, then the native dependencies are copied over properly.
Will this always be the case, and we just need to add the NuGet package with native dependencies as a direct dependency to any project using our internal NuGet package? Or is there something that could be added to our internal NuGet package or something that could be added to the other NuGet package to get native dependencies to copy correctly when referenced indirectly?
Our internal NuGet package is build with dotnet pack using info from the csproj file to create the NuGet package.
I was able to resolve this using the package reference modifiers described here Controlling dependency assets
The default for PrivateAssets is to prevent contentfiles, analyzers, and build files from propagating to referencing projects. The native files were in the build folder of the NuGet package that I was referencing along with the .targets file to define what files needed to be copied. Changing PrivateAssets to only exclude contentfiles and analyzers fixed the problem of downstream projects not copying the native files properly.
<PackageReference Include="SomeLibraryWithNativeDependenciesInTheBuildFolder" Version="1.2.3">
<PrivateAssets>contentfiles,analyzers</PrivateAssets>
</PackageReference>
Struggling to find any information online for this but I am in a scenario where I have a class library project that has dependencies on plenty of nuget packages, but also requires a local assembly which is not on nuget.
So for example godot creates a project for you which bungs in the dlls into a local folder for your project to reference and just adds Reference with hints to your csproj, now I need to depend on those assemblies for the library to work, but the consumers of this package would have to have those assemblies available locally.
So is there a way for nuget to be told that an assembly is needed but it isnt provided via nuget?
I have published a package in Nuget few years ago. From time to time, I was updating it with new versions and all was ok until now.
Few days ago I've published an update to Nuget and when I've updated my package, it was installed successfully but it never added any references to my project.
I've even started from blank console applications and tried to add my package. Same problem.
You can try. This is a package
https://www.nuget.org/packages/63BITS-Libraries/
This is how I built my package
Any ideas?
If you download your nuget package, and unzip it (yep its just a zip file). You will find that your DLL is not in the lib directory.
Typically, inside a nuget package, any dlls need to be in lib/<FrameworkVersion>
For example if your DLL targeted netstandard1.6 then in the nuget package the path to your dll would be lib/netstandard1.6/SixtyThreeBits.Libraries.dll
In your package, your dll is in SixtyThreeBitsLibraries/SixtyThreeBits.Libraries.dll