Custom nuget package with configuration framework

Question

I'm creating a private NuGet package for my company and I want to distribute two different versions of my .dll. The release .dll was for some developers who can call this dll for development. And the debug .dll id for some developers to develop the dll itself for the second version.

So my question is that if I wanted to accomplish this by using only one NuGet package, is this possible? Do I have to create a script on the installation of the package that adds references in the MSBuild, or am I overcomplicating things?

Any suggestion? Thanks in advance.

Answer 1

You can create the same dll and each team can get the dlls like yournuget -release or yournuget -debug.

I normally use a buildscript to create the nugets, paket and FAKE will help you do the job.

And here a related answer to your question: How to create a nuget package with both release and debug dll's using nuget package explorer?

Answer 2

Do I have to create a script on the installation of the package that adds references in the MSBuild, or am I overcomplicating things?

To my knowledge, you may overcomplicating this things. That means you want to use one dll for debug mode to test and another dll for release mode to develop, so those two dll files should be independent, which should be distributed to different packages. Because a NuGet package will normally hold just a single set of assemblies for a particular target framework. It is not really designed to ship a debug and release version.

Besides, when we publish nuget package, the release version of your dll is the best choice since users wont debug into your dll, they will only care about if it works fine and how it works.

In addition, NuGet supports use any string as a suffix to denote a pre-release version, as NuGet treats any such version as pre-release and makes no other interpretation. So you can use -beta to specify a new version of that dll for develop.

https://docs.microsoft.com/en-us/nuget/reference/package-versioning#pre-release-versions

Basically per my understanding, use a different version of the package should be better. Of course, if you persist on using one package, Nekeniehl provided the correct direction.

Hope this help you.