I Have a .NET class library (no core or std) and I would like to add a NuGet package as a runtime dependency. With runtime dependency i mean i do not like to add the package as a normal reference, since my project does not use this package. I however DO need all the dlls in the package to be copied to the output folder, because i need them at runtime.
'Why?'
Because i am working with a plugin-based model.
Related
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>
I have created a Nuget package on a private Azure Artifacts environment, that houses a custom configuration for StyleCop.Analyzers so that the configuration for coding standards can be centralised. This all works absolutely fine and can be installed in other projects with no issue.
I have a separate class library which is being built into a Nuget package, and this project utilises my custom StyleCop package. This package also builds correctly, but in the list of dependencies is my custom StyleCop.Analyzers package. This means that everywhere the class library gets installed, the custom StyleCop.Analyzers package will be installed as well. I don't feel this is correct as it is purely a development-scoped package and should not be included as an actual dependency.
The class library does not feature a .nuspec file, everything is handled through the .csproj and some Azure Pipeline's wizardry. Is the dependency chain correct, or is there something that can be done to ensure that the custom StyleCop.Analyzers package is not listed as a dependency?
Turns out if you add <devDependency>true</devDependency> node to the .nuspec file then the dependency does not get shipped to packages that consume it.
I have an old project that runs on ASP.NET Core 2.1. The project has dependencies folder in which we have
assemblies
packages(nuget packages)
SDK
I am little bit confused by their usage and what does dependencies folder mean.
As far I know
assemblies are .net libraries that referenced into this project and it has a global scope in solution and cant be update until you manually update them.
nuget packages are installed using nuget package manager and are managed and updated when a new update but nuget package has only project scope.
sdk is like a set of tools that is used same like nuget package I think.
Here is the screenshot showing the dependencies format
.net core class library 2.1 Dependecies image
Another thing is that I am creating a new project when I add .net core class library. I have dependecies folder but it's missing
assemblies
packages(nuget packages)
SDK
but it has a new folder called framework
.net core 3.0 class library dependency image
I think I have to manually add these packages in my project. And what's the difference between these three?
Assemblies:- When we compile our source code then assembly gets generated in Visual Studio. Assembly consists of two parts Manifest and IL(Intermediate Language). Manifest contains assembly metadata means assembly's version requirements, security identity, names and hashes of all files that make up the assembly.
Packages:- A package is a container for the definitions of UML elements such as classes, use cases, and components. A package can also contain other packages. In UML Model Explorer, all the definitions inside a package are nested underneath the package.
Nuget Packages:- NuGet packages are pre-defined pieces of code which are reusable for other developers. You can add a NuGet package to your project and use it's functionality wherever you want in your project. We can also say that NuGet behaves like a platform, where developers can create and share code with the world.
SDK:-A SDK(software development kit) is a collection of APIs(Application Programming Interface) that you can reference as a single item in Visual Studio. The Reference Manager dialog box lists all the SDKs that are relevant to the project. When you add an SDK to a project, the APIs are available in Visual Studio.
Packages can not be added manually
here is the link in which it's been clearly explained how to add packages in visual studio:-
https://learn.microsoft.com/en-us/nuget/quickstart/install-and-use-a-package-in-visual-studio
I'm working on upgrading one of our WPF applications. During my upgrade, I converted the application from using the packages.config format for NuGet packages to using the PackageReference format.
Everything seemed to work fine locally, but our build agent started complaining about our NuGet packages:
Error MSB3188: Assembly
'C:\Users\tfs\.nuget\packages\Utils\1.0.0\lib\net45\Utils.dll' must be
strong signed in order to be marked as a prerequisite.
This sort of makes sense because the Utils package is not referenced directly anymore. When you utilize the packages.config format, every NuGet package is referenced by the project, but when you utilize the PackageReference format, only the top-level packages are referenced; package dependencies are not included. Additionally, any projects which are referenced which have a NuGet dependency not explicitly referenced by the WPF project are also affected.
Adding the package dependencies directly to the WPF project solves this issue, but it seems like it shouldn't have to be done that way.
What's strange is when I go into the publish settings / application files for the project, the assemblies are not listed as Prerequisite, but they are marked as Install (Auto) instead.
Short of adding the NuGet package dependencies (not simply the top-level packages), what are my options here? Is there some sort of setting or msbuild parameter, etc. which I can use that allows me to use the PackageReference format while still only referencing the top-level packages?
I'm moving over a project to make it into a nuget package. The project has preprocessor directives in it to check which custom build configuration the developer is in. If they are in Build config A then it pulls A service settings, if they are in B, then it pulls B's settings. The problem is when I package this service up and the nuget package is being used in a separate process with the same build configuration it doesn't respect the devs build configuration choice because the nuget has been compiled with whatever setting it was built in. We have set it up into 3 dlls in a single nuget package.
Is there a way to choose which nuget dll it uses based on the custom build configuration without modifying the csproj code?
Is there a way to choose which nuget dll it uses based on the custom build configuration without modifying the csproj code?
This is not supported as far as I am aware with the NuGet. You can only have one NuGet package with a specific build configurations in a single project's file. Moreover, NuGet now only supports multiple .NET framework versions, not supported multiple configurations.
You can have different NuGet packages if you have different build configurations. This project is specific use by library authors who have platform specific projects that need different NuGet packages.
Besides, It may be simpler to not use NuGet to add the assemblies to your project. Just use NuGet to pack the package with multiple dlls file, then directly reference the assemblies you need with conditions.