首页 文章

Nuget的最佳实践：调试还是发布？

提问于
浏览 次
78

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

编辑:( Jon Skeet，与Noda Time开发有一些偏见）

NuGet现在支持推送到NuGet gallery和symbolsource.org（或类似的服务器），as documented . 不幸的是，这里有两个相互矛盾的要求：

  • 当只使用库而不需要调试时，你真的想要一个发布版本 . 毕竟，这就是发布版本的用途 .

  • 在调试库以进行诊断时，您确实需要一个禁用所有适当优化的调试版本 . 毕竟，这就是调试构建的目的 .

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

所以，选择是：

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

  • 将发布版本分发给每个人，并且稍微有点受损的调试体验 .

  • 寻找一个非常复杂的分发策略，可能提供单独的发布和调试包 .

前两个真的归结为调试版本和发布版本之间差异的影响......虽然它想要进入库代码之间也是一个很大的区别，因为你想检查一些行为，并想要调试库的代码，因为你相信你可能更好地将库的代码作为Visual Studio解决方案并以这种方式进行调试，所以我不会过分关注这种情况 .

我的诱惑是继续发布版本，期望相对较少的人需要调试，并且那些不会受发布版本中的优化影响很大的人 . （无论如何，JIT编译器完成了大部分优化 . ）

那么，还有其他我们未考虑过的选择吗？是否有其他考虑因素可以达到 balancer ？是否将NuGet软件包推向SymbolSource足够新，以至于“最佳实践”还没有真正 Build 起来？

visual-studio debugging release nuget

3 回答

  • 27

    我完全同意你的结论 . NuGet使用RELEASE和SymbolSource打包并进行调试 . 直接进入软件包似乎非常罕见，并且启用优化的偶尔调试失误可能是可以接受的 .

    如果确实存在问题，我认为理想的解决方案是让NuGet支持它 . 例如，假设在调试时，它可以使用SymbolSource包中包含的版本替换版本DLL .

    理想情况下，发生的情况是 nuget pack SomePackage -Symbols 对发布版本会创建一个发布nuget包，但是一个调试符号包 . 并且VS插件将被更新为足够聪明，以便在调试器中运行时查看关联并引入Debug程序集并加载它们 . 有点疯狂，但会很有趣 .

    但是，我只是没有看到有足够的人抱怨这一点，目前它是值得的 .

    NuGet团队接受拉取请求 . :)

    回复于
  • 1

    Creating and Publishing A Symbol Package中的示例引用Debug目录中的文件作为dll和pdb文件的源 .

    指定符号包内容符号包可以按约定，按照上一节中描述的方式构建的文件夹构建，也可以使用files部分指定其内容 . 如果您想构建前面描述的示例包，可以将其放入您的nuspec文件中：

    <files>
  <file src="Full\bin\Debug\*.dll" target="lib\net40" /> 
  <file src="Full\bin\Debug\*.pdb" target="lib\net40" /> 
  <file src="Silverlight\bin\Debug\*.dll" target="lib\sl40" /> 
  <file src="Silverlight\bin\Debug\*.pdb" target="lib\sl40" /> 
  <file src="**\*.cs" target="src" />
</files>

    由于发布符号的目的是允许其他人在调试时逐步执行代码，因此最好谨慎地发布用于调试的代码版本，而不会进行可能影响代码步骤的优化 .

    回复于
  • 4

    对于SymbolSource，我认为最佳做法是：

    • 仅将二进制内容包发布到nuget.org（或任何其他 生产环境 订阅源）

    • 将调试二进制内容包推送到开发订阅源：

    • 内部部署
      myget.org上的

    • 在nuget.org上作为预发布包 .

    • 将发布和调试二进制符号包推送到symbolsource.org或任何其他符号存储区 .

    虽然我们在这里，但是一个常见的误解是，.NET中的发布和调试版本确实有很大不同，但我假设差异化在这里是因为各种代码可能会或可能不会包含在任何一个版本中，例如Debug .Asserts .

    也就是说，将这两种配置推送到SymbolSource是非常值得的，因为您根本不知道何时需要调试 生产环境 代码 . 远程 生产环境 使其更难 . 当发生这种情况时，您将需要从工具中获得的帮助 . 我显然不希望任何人 .

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

    回复于

相关问题