NuGetパッケージのベストプラクティス - きよくらの備忘録
タイトルは若干釣りです。 Stack Overflowでこんなディスカッションを見つけました： Best practices with Nuget: Debug or Release? NuGet自体が一つのパッケージにReleasaeとDegubの両方のビルドを含めれたら一番いい…とも思いましたが、ビルド時にどちらを参照するか切り替える必要があるとか考えるとその仕組みをうまく提供するのが面倒な気もしますね。手動でビルドスクリプトなんかをカスタマイズすればできなくない気がしますが…。 とは言え、『ライブラリのソースにステップインしたい』だけなら何もDebugビルドは必要なく、昨日のエントリのようにReleaseビルドでシンボルパッケージを作成し、シンボルサーバにパブリッシュしておけば十分です。ですので、『ライブラリ自体のデバッグ』が必要な時以外の大抵の場合は以下で十分なんだとは思います。
プライべートなNuGetリポジトリでプライベートなシンボルサーバーを使う - きよくらの備忘録
NuGetには対象のライブラリの他に、デバッグシンボルとソースを含んだシンボルパッケージ(Symbol Package)を作成することが出来ます。公式のNuGetギャラリーで公開する場合、SymbolSource.orgにシンボルパッケージをデプロイすることで自動的にパッケージを関連付けてPDBファイルをダウンロードし、Visual Studioでソースコードにステップインを行うことができます。 これを『ローカルネットワーク上のプライベートリポジトリでも行えないか？』と思って調べてみると、NuGet.Serverを拡張したNuPeekというプロダクトがありました。 これを試してみたので、以下のステップでエントリにまとめてみたいと思います。 NuPeekの準備 ライブラリおよびシンボルパッケージの作成と配置 Visual Sutdioでの設定 パッケージの利用 ＜2013/04/09 23:
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
