(古い)から切り替えたばかりですMicrosoft.Bcl.Immutable
NuGetパッケージを System.Collections.Immutable
そして、私のプロジェクトでこれらすべての新しいパッケージの依存関係を見つけて驚いた:
System.Collections
System.Diagnostics.Debug
System.Globalization
System.Linq
System.Resources.ResourceManager
System.Runtime
System.Runtime.Extensions
System.Threading
それらはNuGetパッケージの依存関係としてリストされているため、そこに存在する権利がありますが、フレームワークに付属しているため、明らかに私のPCとターゲット環境(Azure btw)にも既にインストールされています。
私のプロジェクトにはすでに多数のパッケージがあり、これらの8つのパッケージが原因で発生する追加のオーバーヘッドをできるだけ避けたいと思います(そして、足を踏み入れずに)。
これらの依存関係を削除しても安全ですか?
これらのパッケージは、インストールされているバージョンとは異なる場合があり、プロジェクトの一部が間違ったものを使用する可能性があるため、プロジェクト全体で使用する必要がありますか? (DLL狂気をリンクするために?)
編集:前にコメントがあったので、完全を期すために:依存関係は実際のパッケージ(名前空間ではない)であり、ダウンロードする必要があるため、対象としていますVS2015で動作する.NET 4.6でコンパイルします。何かが古く、パッケージを正常にロードする必要がないことは完全に可能ですか?
Nugetパッケージがlotの人々を満足させなければならないという副作用があるだけです。このパッケージは膨大な数のターゲットをサポートし、最近では急速に増殖しています。 Xamarin for OSXおよびiOS、Windows Phone 8.0および8.1、Windows Store、CoreCLR(オープンソースプロジェクト)、. NET 4.5、MonoTouch for iOSおよびAndroidおよび.NETCore(Silverlight )。
これらの依存パッケージには参照アセンブリのみが含まれています。これは通常、c:\ programファイルx86 \参照アセンブリディレクトリにインストールされます。 Nugetパッケージは、そのような参照アセンブリが欠落している可能性があるわけではなく、キット全体とkaboodleが含まれています。
すべてがダウンロードされた後、パッケージインストーラーが実行され、プロジェクトに実際に参照needが追加されます。何が起こったかを簡単に確認できます。プロジェクトの参照ノードを開くだけです。 .NET 4.5以上のデスクトップバージョンを対象とする場合、追加される参照の合計はoneであり、System.Collections.Immutableのみです。はい、削除できます。