Nugetのベストプラクティス：デバッグまたはリリース？

Question 1

現在、公式ビルド用のリリースビルドはNugetでnuget.orgにパッケージ化していますが、シンボルソースプッシュ用にデバッグビルドをNugetでパッケージ化し、symbolsource.orgにプッシュしています。

編集：（Jon Skeet、Noda Time開発からの偏見あり）

ドキュメントに記載されているように、NuGetはNuGetギャラリーと symbolsource.org（または同様のサーバー）の両方へのプッシュをサポートするようになりました。残念ながら、ここには2つの矛盾する要件があります。

デバッグを必要とせずにライブラリを使用する場合、リリースビルドが本当に必要です。結局のところ、それがリリースビルドの目的です。
診断目的でライブラリにデバッグする場合、適切な最適化をすべて無効にしたデバッグビルドが本当に必要です。結局のところ、それがデバッグビルドの目的です。

それでもかまいませんが、NuGetでは（私が知る限り）リリースビルドとデバッグビルドの両方を同じパッケージで便利な方法で公開することはできません。

したがって、選択肢は次のとおりです。

（ドキュメントの例に示されているように）デバッグビルドをすべての人に配布し、サイズやパフォーマンスに影響を与えずに実行します。
リリースビルドをすべての人に配布し、わずかに障害のあるデバッグエクスペリエンスでライブします。
非常に複雑な配布ポリシーを採用し、個別のリリースパッケージとデバッグパッケージを提供する可能性があります。

最初の2つは、デバッグビルドとリリースビルドの違いによる影響を実際に要約したものです。ただし、動作を確認するためにライブラリのコードにステップインすることと、バグを発見したと思われるため、ライブラリのコードをデバッグします。2番目のケースでは、おそらくライブラリのコードをVisual Studioソリューションとして取得し、そのようにデバッグする方が良いので、その状況にあまり注意を払っていません。

私の誘惑は、リリースビルドをそのまま維持することです。デバッグする必要のある人は比較的少なく、リリースビルドの最適化による影響はそれほど大きくないはずです。（いずれにしても、JITコンパイラーはほとんどの最適化を行います。）

それで、私たちが考慮していなかった他のオプションはありますか？バランスを傾ける他の考慮事項はありますか？NuGetパッケージをSymbolSourceにプッシュすることは、「ベストプラクティス」が実際に確立されていないほど新しいものですか？

Question 2

SymbolSourceについて言えば、ベストプラクティスは次のとおりであると思います。

リリースバイナリ+コンテンツパッケージをnuget.orgのみ（またはその他の本番環境フィード）にプッシュする
デバッグバイナリ+コンテンツパッケージを開発フィードにプッシュします。
- 敷地内に
- myget.org
- nuget.orgでプレリリースパッケージとして。
リリースとデバッグのバイナリ+シンボルパッケージの両方をsymbolsource.orgまたはその他のシンボルストアにプッシュします。

私たちがそれをしている間、.NETでのリリースビルドとデバッグビルドは実際に大きく異なるというのはよくある誤解ですが、Debugのように、どちらのビルドにも含まれる、または含まれない可能性があるさまざまなコードのために、ここに違いがあると想定しています.Asserts。

とは言え、どちらの構成もSymbolSourceにプッシュする価値があります。本番用コードをデバッグする必要がある時期がわからないためです。生産をリモートで行うことで、より困難になります。あなたはそれが起こったときにあなたがあなたのツールから得ることができる助けを必要とするでしょう。これは明らかに誰にも望まないことです。

バージョニングに関して考慮すべき問題がまだあります：1つのバージョン番号を共有する2つの異なるパッケージ（デバッグとビルドでビルド）を持つことは正しいですか？SymbolSourceはパッケージを抽出し、バイナリを個別のビルドモードブランチに格納するため、それを受け入れます。NuGetがそれに応じてパッケージにタグを付けることができる場合のみです。現在、パッケージがデバッグモードかリリースモードかを判別する方法はありません。

Question 3

私はあなたの結論に完全に同意します。RELEASE付きのNuGetパッケージとデバッグ付きのSymbolSource。パッケージに直接ステップインすることは非常にまれであり、最適化を有効にしてデバッグを誤って実行することは許容できる場合があります。

本当に問題があった場合、理想的な解決策はNuGetでサポートすることだと思います。たとえば、デバッグ時にリリースDLLをSymbolSourceパッケージに含まれているDLLに置き換えることができると想像してください。

理想的にはnuget pack SomePackage -Symbols、リリースバージョンに対してリリースnugetパッケージが作成され、デバッグシンボルパッケージが作成されます。そして、VSプラグインは、関連付けを確認し、デバッガーで実行しているときにデバッグアセンブリをプルし、代わりにそれらを読み込むのに十分スマートになるように更新されます。ちょっとクレイジーですが、面白いでしょう。

しかし、現時点でそれだけの価値があると思うほど、これについて文句を言う人が十分にいないようです。

NuGetチームはプルリクエストを受け入れます。:)

Question 4

シンボルパッケージの作成と公開の例では、dllおよびpdbファイルのソースとして、Debugディレクトリのファイルを参照しています。

シンボルパッケージの内容の指定

シンボルパッケージは、前のセクションで説明した方法で構造化されたフォルダーから規則に従って構築するか、またはファイルセクションを使用してその内容を指定できます。前述のサンプルパッケージをビルドする場合は、これを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>

シンボルを公開する目的は、デバッグ時に他のユーザーがコードをステップ実行できるようにすることであるため、コードのステップ実行に影響する可能性のある最適化なしのデバッグ用のバージョンのコードを公開することが最も賢明なようです。