.NET Coreライブラリでのdepencenciesを制限する必要がありますか？

Question

私は完全な.NETで書かれたライブラリを持っており、.NET Coreに移植しています。私はそれを.netstandard1.1（.NET45との互換性を持たせるため）をターゲットにするつもりです。

Visual Studioでプロジェクトを作成すると、自動的にNETStandard.Library Nugetパッケージに依存します。

• System.Runtime
• System.Runtime.InteropServices

つの質問：

1. は私を制限する必要がありますか

   は

   マイライブラリにはたった2つのパッケージを必要としますプロジェクト依存関係は、これらの2つのパッケージだけになりますか？言い換えれば、ナゲット（またはビジュアルスタジオや別の魔法のようなもの）が、完全なNETStandard.Libraryではなく、必要なパッケージだけに制限することができますか？

2. 最初の質問に対する回答が「いいえ」の場合は、その制限を実行することをお勧めしますか？

ありがとうございます。

Answer 1

...

1. netstandard1.1フレームワークの選択は、そのバージョン利用可能なものに（ここでは、コードVS）エディタで利用できるAPI表面が制限されます。 netstandard1.1（利用できません）とnetstandard1.6（利用可能）のVSコードのFile.OpenReadでテストされています。
2. NETStandard.Library依存性（バージョン1.6は両方の場合に適しています）はパッケージの依存関係です。アセンブリがコンパイルされると、アセンブリ自体は、NETStandard.Libraryメタパッケージにあるすべてのアセンブリではなく、実際に使用された外部アセンブリ（別名参照アセンブリ）（たとえば、System.RuntimeおよびSystem.Linq）を宣言します。

NuGet用にパッケージ化していない限り、アセンブリの参照の制限が行われます。 NuGetパッケージは、しかし、あなたはNuGetを使用し、その低減が重要な場合、私は正しい用語がトリミングNuGet依存だと思いNETStandard.Libraryパッケージ

を参照することになり、手動のプロセスは、（ショートバージョンをhereを説明：メタからのすべての参照をコピーしますあなたが使用していないものすべてをパッケージ化して削除してください）。

Answer 2

1. 私はしかし、ライブラリを構築し、NETStandard.Libraryパッケージが含ま持っていない好きではないVSのように思える、それはVSのバグだかどうかわからないです（私の英語のため申し訳ありませんが、私はネイティブスピーカーではないよ）:)そう、いいえ。
2. Visual Studioコードやメモ帳などを使用していない限り、VSはプロジェクトの作成などを妨げるため、開発が遅くなります。

最終行 時期尚早な最適化は、利益よりも多くの問題を引き起こす可能性があります。まずライブラリを移植し、最適化が必要かどうかを確認してください。あなたの問題のいくつかの側面があります