質問

認証、ロギングなどのためにすべてのWebサイトで使用されるプライベートな「エンタープライズサービス」DLLがいくつかあります。それらはプライベートなので、これらのDLLのバージョンとソースも制御します。作成後の歴史的な(エラーが発生しやすい)ステップ File | New Project 含む

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

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

出会ったばかりです ヌゲット (MVC3にバンドル)。これにより、個人ホストのサーバーからVS2010パッケージをダウンロードしてインストールし、以前に手動で作成していた構成設定を自動化できます。

質問:

  • 私のDLLをプライベートNugetサーバーに公開することは理にかなっていますか?
  • 必要に応じて、デバッグしてこのDLLに足を踏み入れる能力を失いますか?
  • 私のプロジェクトの残りの部分がTFSに基づいている場合、他にどのようなことを考慮する必要がありますか?
役に立ちましたか?

解決

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

私の2セントは、プライベートサーバーを構成する必要がないということです。vsを構成するVSの構成共有フォルダーに。

私がテストした最新のNugetビットの場合、クライアント(コンソールとGUIの両方)は、依存関係を見つけるための他のフィードを調べないため、自動的に解決できないと苦情を申し立てます。手でそれらをインストールする必要があります。

他のヒント

はい、あなたがプライベートヌゲットフィードを持っていることは理にかなっています

DLLに足を踏み入れるかどうかはわかりませんが、NugetパッケージにPDBを提供し、シェアのライブラリソースを提供する場合(そして、それらのソースがどこにあるかを知るように構成します)、 .NETフレームワーク自体の今日と同じようにコード。

Nugetは、ソースコントロールにマッピングされたプロジェクトでうまく機能するように設計されていたため、必要なものは他にないことを願っています。

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

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top