Nuget 的最佳实践:调试还是发布? [英] Best practices with Nuget: Debug or Release?

问题描述

目前，我使用 Nuget 将发布版本打包到 nuget.org 的官方版本，但我使用 Nuget 打包调试版本以将符号源推送到 symbolsource.org.

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.

(Jon Skeet，对 Noda Time 开发有一些偏见)

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

NuGet 现在支持推送到 NuGet 库和 symbolsource.org(或类似服务器)、如文档所述.不幸的是，这里有两个相互矛盾的要求:

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.

这很好，但 NuGet 不允许(据我所知)以有用的方式在同一个包中发布发布和调试版本.

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.

所以，选择是:

• 将调试版本分发给所有人(如文档中的示例所示)，并接受任何规模和性能影响.
• 将发布版本分发给每个人，并忍受稍微受损的调试体验.
• 采用非常复杂的分发策略，可能会提供单独的发布和调试包.

前两个确实归结为调试和发布版本之间差异的影响......尽管值得注意的是，因为想要检查某些行为而想要进入库的代码之间也存在很大差异，并且想要调试库的代码，因为您认为自己发现了错误.在第二种情况下，最好将库的代码作为 Visual Studio 解决方案获取并以这种方式进行调试，因此我不会过多注意这种情况.

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.

我的诱惑是只保留发布版本，期望相对很少有人需要调试，而那些这样做的人不会受到影响太多 通过发布版本中的优化.(无论如何，JIT 编译器都会进行大部分优化.)

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.)

那么，还有其他我们没有考虑过的选择吗?是否还有其他因素可以打破平衡?将 NuGet 包推送到 SymbolSource 是否足够新，以至于最佳实践"真的还没有建立?

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?

推荐答案

OP 发帖已经 8 年了(之前的答案仍然在下面投票最高)，所以我会用现在使用的东西来破解它.

It's been 8 years since OP's post (with previous answer still top-voted below), so I'll give it a crack with what's used nowadays.

p>

进入"有两种方式.NuGet 包:

There are 2 ways of "stepping into" a NuGet package:

1.PDB的分布

.symbols.nupkg 符号包是 被视为旧版，并已替换为发布到 符号服务器.大多数供应商都支持它，Azure DevOps 是最大的局外人，其中 功能请求 仍处于审核中"；(感谢@alv 提供链接).

.symbols.nupkg symbol packages are considered as legacy and have been replaced with .snupkg packages that get published to Symbol Server. It’s supported by most vendors with Azure DevOps being the biggest outsider where the feature request is still "under review" (thank you @alv for the link).

这里是官方说明.只需将这两行添加到 csproj 文件中:

Here are the official instructions. Simply add these two lines to the csproj file:

<PropertyGroup>
  <IncludeSymbols>true</IncludeSymbols>
  <SymbolPackageFormat>snupkg</SymbolPackageFormat>
</PropertyGroup>

在消费者方面，确保为 NuGet.org(或 Azure 等)符号服务器配置了您的 IDE，以允许 调试时进入包代码.

On the consumer side, make sure that your IDE is configured for the NuGet.org (or Azure, etc.) Symbol Server to allow stepping into package code when debugging.

<强>2.Source Link.Linking 实际代码

在某些情况下，由于 MSIL/JIT 优化，PDB 可能会隐藏源代码的某些细节.所以有一种方法可以在调试时进入"你的 NuGet 的实际源代码.它被称为 Source Link 来自 .NET 基金会 - "与语言和源代码控制无关为二进制文件提供源代码调试体验的系统.

In some cases, the PDBs may hide some specifics of the source code due to MSIL/JIT optimisation. So there is a way of "Stepping Into" the actual source of your NuGet while debugging. It’s called Source Link from the .NET Foundation – "a language- and source-control agnostic system for providing source debugging experiences for binaries".

Visual Studio 15.3+ 和所有主要供应商都支持它(也支持私有存储库).

It’s supported by Visual Studio 15.3+ and all the major vendors (also supports private repos).

设置很简单(官方文档)——只需在项目文件中添加开发依赖项(取决于您的回购的类型)以及一些标志:

It’s trivial to setup (official docs) – just add a development dependency to the project file (depends on the type of your repo) along with some flags:

<PropertyGroup>
    <PublishRepositoryUrl>true</PublishRepositoryUrl>
    <EmbedUntrackedSources>true</EmbedUntrackedSources>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.SourceLink.GitHub" Version="1.0.0" PrivateAssets="All" />
</ItemGroup>

在改进 NuGet 包的 5 个步骤中查看有关此主题的更多信息;.

Check out more on this subject in "5 steps to better NuGet package".

这篇关于Nuget 的最佳实践:调试还是发布?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！