NuGetまたは共有サードパーティ製DLLのアセンブリフォルダ？

Question

私は、Microsoft .NETストアでサードパーティのDLLを参照する別々のソリューションで約10-15のプロジェクトを持っています。私たちが取り組んでいきたい問題の1つは、プロジェクト間で使用されるDLLのバージョンの整合性です（プロジェクトが作成されたときに別々のバージョンではなく、すべてのプロジェクトでE.G.Netwonsoft 8.0.3）。

私は以前の職場でこれを2つの方法で行ってきましたが、この問題を解決する他の選択肢があるかどうかは疑問でした。

1. 私は会社内のプロジェクトのソリューション内で参照されているすべてのサードパーティ製DLLに企業NuGetを使用しています。 DLLは更新され、プロジェクト内の開発者がソリューション内でプルダウンおよびアップグレード（必要な場合）できるようになります。
2. 別の会社には、すべての「承認された」サードパーティのDLLとこのディレクトリ内に存在するすべての参照が格納されているアセンブリフォルダがソースにありました。

私はこの質問を見ましたが、それだけで上記の2つのソリューションのいずれかを提供：Where should you store 3rd party assemblies?

は、上記とは別に存在し、他のオプションはありますか？

Answer 1

可能な限りNuGetを使用してください。主な理由は、Gitが大きなバイナリをうまく処理せず、LFSをこのために使用することは、有効な選択肢があるので、あまり意味がありません。 TFVCは大きなバイナリでは問題が少なくなっていますが、あなたがTFVCを利用しているなら、Gitへの今後の移行を念頭に置いておいてください。

この場合、NuGetだけでなく、npmや他のパッケージソースも関係している可能性があることに注意してください。

特定のバージョンを使用する場合は、CIパイプラインにフックするカスタムタスクを作成します。そうすれば、警告や設定を簡単に行うことができます。カスタムタスクはpackages.configファイルを取得し、参照されているパッケージをスキャンし、TFS/VSTSパッケージ管理フィードを照会して、最新バージョンを使用しているか（最新のマイナーバージョンを使用しているかを確認する）少なくともxバージョンのバック）...または、どこかからjsonファイルまたはxmlファイルから承認されたバージョンを取得し、それに対して検証します。

Answer 2

ソースコントロールで、リポジトリが最初に設定されたときに、必要な依存関係のDLLを使用して、コミットしてプッシュマスタにします。他のブランチ上のすべてのユーザーがリポジトリから引き出すので、必要なすべてのDLLを確実に受け取ることができます。これは、GACUtilによって解決されるGACのDLLを参照している場合、または誰もが同じWindowsバージョンを使用していることを確認する場合にのみ問題になります。