A simpler way to pack debug and release dlls inside a nuget package

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

My idea is to have inside the nuget package both debug version and release version of the package, this way, when the project is running on debug mode, it uses the debug dlls, and source link, and many other features to improve development.

and when I publish my project, as release, it uses the release version of the library, this way I would get most performance features, and all the benefits to use in production, with transparency to all developers.

StackOverflow - Nuget packages with both debug and release

---

Original Comments

Feedback Bot on 7/21/2020, 08:15 PM:

Thank you for taking the time to provide your suggestion.  We will do some preliminary checks to make sure we can proceed further.  We'll provide an update once the issue has been triaged by the product team.

[JonDouglas]

Forwarded response regarding the scenarios:

1) when I use the release option, in the debugger I get some areas that the code can't be used in debugger because it's optimized, For example, I have a json reader that uses Repositories to load based on the ids, when I get errors in this code, the reflection doesn't show the types and properties, with messages of optimized code. I didn't change any compiler optimization, should I do this?

2) If the code isn't optimized anymore, what's the benefit from publish it in release mode?

[sebas77]

I would have assumed this was a more common issue. I am in the same pickle, I need two different dlls as the debug one is full of run time checks that won't be good in production. While it's true that these checks are very related to my framework, I am not sure how in a common design by contract scenario this is not an issue

[luizfbicalho]

My problem is to debug the libraries, the release source link has a lot of otimizations and it's not easy to do. How much performance do I loose in debug mode?

[tomdewilde]

My use case: we have a private NuGet server (BaGet) for our in house packages. The release version is obfuscated, so debugging is not even possible. Including both debug & release version in the same NuGet package would save a lot on development time.

[tasmin]

Like @tomdewilde our release version of the NuGet package is obfuscated and when the app that uses the NuGet package is run in Debug configuration, it breaks and cannot be debugged. We need to use the debug build of the NuGet package to be able to develop any code that uses the NuGet package that is obfuscated in Release configuration.

[StephaneDelcroix]

My use case is to provide an optimised lib for Releases, while the one used for Debug contains code instrumentation

[cgtyoder]

We have an in-house NuGet repository, and our in-house libraries/code have conditionally compiled code for DEBUG/etc, so making it easy to include arbitrary configurations in the package would be very helpful.

[cgtyoder]

@zkat what additional info specifically is needed for triage?

[zkat]

@cgtyoder this is already in our backlog. @JonDouglas will be taking care of hashing out the feature for us before implementation, but we have no timeline to give you on that.

[timcassell]

Looking forward to this. I have a Promise library that captures the stack-trace every time a new Promise object is created in DEBUG mode, which is extremely expensive, and although it can be disabled, it's stripped in RELEASE mode to reduce memory and CPU usage.

[cockroach888]

Looking forward to this too.

[GGAlanSmithee]

Has there been any progress on this?

[mrpmorris]

I need to create NuGet package that uses System.Text.Json by default, but I want the consuming app to be able to define FLUXOR_NEWTONSOFTJSON and have it depend on that instead.

At the moment I have to reference both json libraries, and that makes my Blaxor WASM app payload bigger then it should need to be.

[akanwischer]

Still waiting