11

We are experimenting with nuget for our visual studio projects. However, we only (or at least mainly) use nuget for our own external references, and we store them in a local repository (network share). What I would like to know is how to handle the whole debug/release situation.

Concrete (simplified) situation:

We have a main project that has references to two shared components that we developed ourselves. These shared components are also used in other products of our company

When we build the main project (azure pipelines), we build the debug and release versions of the project. However, we can only specify a single nuget package for each external reference.

What we want to accomplish to to use the debug version of the shared components during the debug build, and the release version during the release build. However, these are (as far as I know) actually different packages.

What is the way of tackeling this issue? Is there, for instance, a way to include both the release and debug versions in a single nuget package? Is it possible to have to different nuget configurations for different build configuration settings?

I've found Best practices with Nuget: Debug or Release?, however this topic doesn't really address my issue. This thread is more a discussion about whether to publish debug or release versions to a remote server. We want to publish both and use both in a private repository. We have no intention of sharing our libraries with the rest of the world.

PaulVrugt
  • 1,682
  • 2
  • 17
  • 40

1 Answers1

3

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 since you are publishing the NuGet package to be consumed by other users. Normally you do not publish a debug and a separate release version of your application to end users.

You may be able to workaround this by using a custom MSBuild .targets file in the NuGet package that has its own references and configuration information. You can use this .targets file as an extension to your project. It will be imported so you can define the references as you need based on the configurations defined in your project. It is not ideal but it should work.

Matt Ward
  • 47,057
  • 5
  • 93
  • 94
  • Doesn't this mean that for our situation, nuget might not be the way to go? Is there a different approach besides nuget to include these kind of shared components in our project? How do other people accomplish this? I'm sure we're not the first company with this situation – PaulVrugt Mar 17 '16 at 11:28
  • Yes, NuGet might not be a good approach for you. Presumably your network share still works for debug and release builds, so maybe there is no need to change it. – Matt Ward Mar 17 '16 at 15:15
  • 2
    I don't really see why there are not more people with the same problem. I've sketched a situation that I believe is very common for a lot of companies. How do other companies set up their build server to build with external libraries? The advantage of using nuget is that it works out-of-the-box in tfs2015 build task builds, and it makes sure the version of the reference stays the same until manually updated. We lose this advantage if we move away of nuget. – PaulVrugt Mar 17 '16 at 16:38
  • NuGet is not designed to ship debug and release builds together. It is for a published artifact that is typically your release build which is then used by other people. For external libraries, that are not on NuGet, I tend to use a single set of binaries, normally release builds, and do not have two sets of binaries. However there is nothing rulling out having both on a file share or in version control. You could use a submodule for your binaries, say on GitHub for example. – Matt Ward Mar 17 '16 at 23:09
  • So if I understand you correctly you think we might be better off by creating a custom build task to restore external libraries ourselves? We actually did something like this in the old xaml build system. However, we were hoping to move away for such a custom implementation when moving to the tfs 2015 build tasks by using nuget. – PaulVrugt Mar 18 '16 at 07:59
  • No I did not say you would be better off using a custom build task. I mentioned a custom build task as a workaround to allow you to use NuGet. That would allow you to ship both debug and release assemblies in the NuGet package. However it is a workaround since NuGet is not designed to be used like that. – Matt Ward Mar 18 '16 at 09:13
  • 2
    Right, and since we need to have the debug/release configurations, we need to implement a custom build task. Clearly nuget doesn't suffice here, so we'll start working on a custom build task to implement it the way we want it to work. I still think it's very weird that there is no other default way to implement this – PaulVrugt Mar 18 '16 at 12:10
  • @PaulVrugt What did you end up doing here? I've encountered the same issue, and, like you, find it strange there's no real way to do this with nuget. – Jono Rogers Jul 29 '17 at 14:01
  • @JonoRogers we ended up not going with nuget at all. We were looking at a custom build task or powershell script, which should do the job to collect the right dll's, but for now we think it's too much work. We might revisit the topic soon since we still need to migrate from xaml builds to the new build task system – PaulVrugt Jul 31 '17 at 08:10
  • Thanks @PaulVrugt – Jono Rogers Aug 01 '17 at 08:40