Nuget的最佳做法：调试或发布？ [英] Best practices with Nuget: Debug or Release?

问题描述

目前，我将Nuget的发布版本与官方版本一起打包到nuget.org，但是我使用Nuget打包调试版本，用于将符号来源推送到symbolsource.org。

$ b $编辑：（Jon Skeet，来自Noda Time开发的一些偏见）

NuGet现在支持推动NuGet画廊和符号源.org（或类似的服务器），如所记录的。不幸的是，这里有两个矛盾的要求：

• 只要使用一个库，而不需要调试，真的要发行版本。毕竟这是发布版本。


• 当进行诊断调试到库时，您真的需要一个禁用所有适当优化的调试版本。毕竟这是调试版本。

这样会很好，但是NuGet没有（据我所知）允许发布和调试版本在同一个包中以有用的方式发布。

所以，选择是：

• 将调试版本分发给所有人（如文档中的示例所示），并且可以使用任何大小和性能匹配。


• 将发布版本分发给每个人，并以稍微受损的调试体验生活。


• 去一个非常复杂的分发策略，可能提供单独的版本和调试包。

前两个真的归结于调试和发布版本之间的差异效果...虽然值得注意因为想要检查某些行为，而是想要调试库的代码，因为你相信你已经发现了一个错误，所以想要进入一个库的代码也有很大的区别。在第二种情况下，最好将库的代码作为Visual Studio解决方案，并以这种方式进行调试，所以我不会太注意这种情况。

我的诱惑是保持发布版本，预期相对较少的人将需要调试，而那些不会受到影响的人通过发布版本中的优化，可以很容易地。 （JIT编译器完成大部分的优化。）

那么我们还没有考虑过其他选项吗？是否还有其他考虑因素会导致平衡？将NuGet软件包推送给SymbolSource，新的最佳实践确实还没有建立？

解决方案

说到SymbolSource，我相信最好的做法是：

1. 仅将推出的二进制+内容包推送到nuget.org（或任何其他生产Feed） li>
   
2. 将调试二进制+内容包推送到开发源：
   
   
   
   • on-premise
   
   
   • on myget
   
   


3. 将发布和发布包都放在nuget.org上。调试二进制+符号包到symbolsource.org或任何其他符号存储。

虽然我们在，它是一个常见的误解在.NET中的发布和调试构建真的有很大的不同，但是我假设差异化在这里是因为可能或可能不包括在任何构建中的各种代码，如Debug.Asserts。

那就是说真的值得推荐两种配置到SymbolSource，因为你只是不知道什么时候需要调试生产代码。远程生产使其更难。当您发生这种情况时，您将需要从工具中获得的帮助。我显然不希望任何人。

还有一个需要考虑的版本控制问题：是否有两个不同的包（建立在调试和发布中）是正确的共享1个版本号？ SymbolSource会接受这一点，因为它提取包并将二进制文件存储在单独的构建模式分支中，如果只允许NuGet相应地标记包。目前无法确定包是否是调试或释放模式。

Currently, I package the release builds with Nuget for the official builds to nuget.org, but I package the debug builds with Nuget for the symbol source pushes to symbolsource.org.

EDIT: (Jon Skeet, with some bias from Noda Time development)

NuGet now supports pushing to both NuGet gallery and symbolsource.org (or similar servers), as documented. Unfortunately, there are two contradictory requirements here:

• When just using a library without any need for debugging, you really want a release build. That's what release builds are for, after all.
• When debugging into a library for diagnostic purposes, you really want a debug build with all the appropriate optimizations disabled. That's what debug builds are for, after all.

That would be fine, but NuGet doesn't (as far as I can tell) allow both the release and debug builds to be published in a useful way, in the same package.

So, the choices are:

• Distribute the debug builds to everyone (as shown in the example in the docs) and live with any size and performance hits.
• Distribute the release builds to everyone and live with a slightly impaired debug experience.
• Go for a really complicated distribution policy, potentially providing separate release and debug packages.

The first two really boil down to the effect of the differences between debug and release builds... although it's worth noting that there's also a big difference between wanting to step into the code of a library because you want to check some behaviour, and wanting to debug the code of a library because you believe you've found a bug. In the second case, it's probably better to get the code of the library as a Visual Studio solution and debug that way, so I'm not paying too much heed to that situation.

My temptation is to just keep with the release builds, with the expectation that relatively few people will need to debug, and the ones who do won't be impacted much by the optimizations in the release build. (The JIT compiler does most of the optimizing anyway.)

So, are there other options we hadn't considered? Are there other considerations which tip the balance? Is pushing NuGet packages to SymbolSource sufficiently new that "best practice" really hasn't been established?

解决方案

Speaking for SymbolSource, I believe that the best practice is to:

1. Push release binary+content packages to nuget.org only (or any other production feed)
2. Push debug binary+content packages to a development feed:
   • on-premise
   • on myget.org
   • on nuget.org as pre-release packages.
3. Push both release and debug binary+symbols packages to symbolsource.org or any other symbol store.

While we're at it, it is a common misconception that release and debug builds in .NET really differ much, but I am assuming that the differentiation is here because of various code that might or might not be included in either build, like Debug.Asserts.

That said, it is really worth pushing both configurations to SymbolSource, because you just never know when you're going to need to debug production code. Remotely in production to make it harder. You're going to need the help you can get from your tooling when that happens. Which I obviously do not wish upon anyone.

There is still a matter to consider regarding versioning: is it correct to have 2 different packages (build in debug and in release) sharing 1 version number? SymbolSource would accept that, because it extracts packages and stores binaries in separate build mode branches, IF ONLY NuGet allowed to tag packages accordingly. There is no way at present to determine if a package is debug or release-mode.

这篇关于Nuget的最佳做法：调试或发布？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！