3
Nugetのベストプラクティス：デバッグまたはリリース？
現在、公式ビルド用のリリースビルドはNugetでnuget.orgにパッケージ化していますが、シンボルソースプッシュ用にデバッグビルドをNugetでパッケージ化し、symbolsource.orgにプッシュしています。 編集：（Jon Skeet、Noda Time開発からの偏見あり） ドキュメントに記載されているように、NuGetはNuGetギャラリーと symbolsource.org（または同様のサーバー）の両方へのプッシュをサポートするようになりました。残念ながら、ここには2つの矛盾する要件があります。 デバッグを必要とせずにライブラリを使用する場合、リリースビルドが本当に必要です。結局のところ、それがリリースビルドの目的です。 診断目的でライブラリにデバッグする場合、適切な最適化をすべて無効にしたデバッグビルドが本当に必要です。結局のところ、それがデバッグビルドの目的です。 それでもかまいませんが、NuGetでは（私が知る限り）リリースビルドとデバッグビルドの両方を同じパッケージで便利な方法で公開することはできません。 したがって、選択肢は次のとおりです。 （ドキュメントの例に示されているように）デバッグビルドをすべての人に配布し、サイズやパフォーマンスに影響を与えずに実行します。 リリースビルドをすべての人に配布し、わずかに障害のあるデバッグエクスペリエンスでライブします。 非常に複雑な配布ポリシーを採用し、個別のリリースパッケージとデバッグパッケージを提供する可能性があります。 最初の2つは、デバッグビルドとリリースビルドの違いによる影響を実際に要約したものです。ただし、動作を確認するためにライブラリのコードにステップインすることと、バグを発見したと思われるため、ライブラリのコードをデバッグします。2番目のケースでは、おそらくライブラリのコードをVisual Studioソリューションとして取得し、そのようにデバッグする方が良いので、その状況にあまり注意を払っていません。 私の誘惑は、リリースビルドをそのまま維持することです。デバッグする必要のある人は比較的少なく、リリースビルドの最適化による影響はそれほど大きくないはずです。（いずれにしても、JITコンパイラーはほとんどの最適化を行います。） それで、私たちが考慮していなかった他のオプションはありますか？バランスを傾ける他の考慮事項はありますか？NuGetパッケージをSymbolSourceにプッシュすることは、「ベストプラクティス」が実際に確立されていないほど新しいものですか？