100

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

編集: (Jon Skeet、Noda Time 開発からの偏りあり)

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

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

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

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

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

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

私の誘惑は、デバッグを必要とする人が比較的少なく、リリース ビルドの最適化による影響をあまり受けないことを期待して、リリース ビルドを維持することです。(いずれにせよ、JIT コンパイラーはほとんどの最適化を行います。)

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

4

4 に答える 4

33

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

  1. リリース バイナリ + コンテンツ パッケージを nuget.org のみ (またはその他の運用フィード) にプッシュする
  2. デバッグ バイナリ + コンテンツ パッケージを開発フィードにプッシュします。
    • 敷地内に
    • myget.org で
    • nuget.org でプレリリース パッケージとして入手できます。
  3. リリースとデバッグの両方のバイナリ + シンボル パッケージを、symbolsource.org またはその他のシンボル ストアにプッシュします。

開発中は、.NET のリリース ビルドとデバッグ ビルドが実際には大きく異なるというのはよくある誤解ですが、どちらのビルドにも含まれる場合と含まれない場合があるさまざまなコード (Debug など) が原因で、違いがあると考えています。 .アサートします。

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

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

于 2013-02-01T07:31:07.097 に答える
4

私はあなたの結論に完全に同意します。RELEASE を含む NuGet パッケージとデバッグを含む SymbolSource。パッケージに直接ステップインすることはほとんどないように思われ、最適化が有効になっている場合に時折発生するデバッグの失敗は許容されるかもしれません。

本当に問題があるのであれば、NuGet に対応してもらうのが理想的な解決策だと思います。たとえば、デバッグ時に、リリース DLL を SymbolSource パッケージに含まれているものに置き換えることができるとします。

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

ただし、現時点では、これに値するだろうと不平を言う人が十分にいない.

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

于 2013-02-04T21:41:11.443 に答える
1

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

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

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

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

于 2013-02-01T07:28:22.993 に答える