3

私たちは、すべての Web サイトで認証やログ記録などに使用されるプライベートな「エンタープライズ サービス」DLL をいくつか持っています。それらはプライベートであるため、これらの DLL のバージョン管理とソースも管理しています。File | New Projectインクルードを作成した後のこれまでの (エラーが発生しやすい) 手順

  1. 「エンタープライズ サービス」プロジェクトを追加します。
  2. 上記への参照を追加
  3. Authentication、HttpHandlers などの web.config セクションを編集します。

NuGet は上記のプロセスを自動化します

プライベートにホストされたサーバーから VS2010 パッケージをダウンロードしてインストールし、以前は手動で行っていた構成設定を自動化できる NuGet (MVC3 にバンドルされている) に出会いました。

質問：

  • dll をプライベート NuGet サーバーに公開することは理にかなっていますか?
  • 必要に応じて、この dll をデバッグしてステップ インすることができなくなりますか?
  • プロジェクトの残りの部分が TFS に基づいている場合、他にどのようなことを考慮する必要がありますか?
4

3 に答える 3

1

私は marcind に同意します: プライベート フィードを持つことは理にかなっています。

私の 2 セントは、プライベート サーバーを構成する必要がないということです。パッケージを配布するには、共有フォルダーをターゲットにするように VS を構成するだけで十分であり、TFS ビルドで簡単に更新できます。NuGet パッケージを作成してドロップするだけです。共有フォルダに。

私がテストした最新の NuGet ビットでは、クライアント (コンソールと GUI の両方) は依存関係を見つけるために他のフィードを調べないため、自動的に解決できないと文句を言うことに注意してください。手でインストールする必要があります。

于 2010-11-02T23:53:17.377 に答える
1

はい、プライベートな NuGet フィードを持つことは理にかなっています

dllにステップインするかどうかはわかりませんが、NuGetパッケージにPDBを提供し、共有にライブラリソースを提供する場合（そして、それらのソースがどこにあるかを知るようにVSを構成する場合）、ステップインできるはずです.NET フレームワーク自体に対して現在できるのと同じようにコードを記述します。

NuGet は、ソース管理にマップされたプロジェクトでうまく機能するように設計されているため、他に必要なものが何もないことを願っています。

于 2010-10-31T16:06:12.827 に答える
0

@Ghidello NuGet は、特定のリポジトリを使用していない限り、依存関係を自動的に解決します (コンソールのパッケージ ソース ドロップダウンは、プライベート リポジトリではなく [すべて] に設定されています)。

于 2011-02-22T20:57:13.137 に答える