I have a solution that includes multiple C# executables. Two of the executables are built as separate NuGet packages, with the utilities shipped in the package's tools directory. The projects are SDK-style .csproj.
One of the executables always depends on the other (one .exe invokes the other; not a linking dependency). How should the two executables, built at the same time, best be included together in a single NuGet package?
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?
I want to write that C# code convert-nunit-3-nunit-2-results-xml-file, but despite the added nuget package i'm missing the dll in my project.
I see it in the tool's directory of the package cache, but missing it in my project.
What do i overlook?
My project is at present for .Net Core 2.1. Is my issue therefore related to this: Add support for net standard ?
I'm new to .net and don't understand all the differences so far.
As zivkan explained, the package is a tool. In fact, it's an extension to another tool, the NUnit engine package. The NUnit engine knows how to find and use the extension.
NUnit does not publish a package that is intended for use by your code as a library, because we would then have to support it as a library in addition to it's use as an extension to NUnit.
However, NUnit's MIT license allows you to use the source code, which you can find at https://github.com/nunit/nunit-v2-result-writer
Since the code has not yet been ported to .NET Core, you would have to do that yourself.
You didn't overlook anything. Not all NuGet packages are libraries.
NuGet has conventions on how files must be packed in order to use various features. For example, files in the content or contentFiles get copied into the project directory, or build output, depending if the project using the package uses packages.config, or PackageReference. If the package author wants to give you a library that you can use in your code, they must put the library in the lib directory in the nupkg (technically it could be in ref, but those don't get copied to build/publish output, they're only used at build time). The tools directory is, unsurprisingly, intended for tools packages. It's often used by unit test runners, or in this case, a report generator.
So, since the package puts the dlls in the tools directory, this means the package author intends the package to be a tool to assist you during development, but not as a library for you to use in your code. You could try contacting the package author to see if they have published another package with the same dll, this time in the lib directory, so that you can use it your project.
Otherwise you'll need to find a solution that doesn't rely on NuGet bringing you this dll as a library. One option is to have a packages.config file that extracts the package in a solution packages directory, and then you use a dll reference to the dll. Your build script would then need to first restore the packages.config file before building your project. Another option is to check in the dll into your source control management tool, if the dll's license allows that, and again have a dll reference to it.
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'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.