Visual Studioの「ローカルコピー」のデフォルトオプションをFalseに設定できますか?ほとんどの場合、プロジェクトの依存関係としてdllを追加するときは、ローカルコピープロパティをFalseに設定する必要があります。デフォルトでは、Trueです。Visual Studioのデフォルトの動作を変更する方法はありますか?(2008)
6 に答える
いいえ-VisualStudioは、内部のルールセットを使用して、[ローカルコピー]を何に設定するかを決定します。
MSDNから:
- 参照がプロジェクト間参照と呼ばれる別のプロジェクトである場合、値はtrueです。
- アセンブリがグローバルアセンブリキャッシュで見つかった場合、値はfalseです。
- 特別な場合として、mscorlib.dll参照の値はfalseです。
- アセンブリがFrameworkSDKフォルダーにある場合、値はfalseです。
- それ以外の場合、値はtrueです。
実際、できます。いくつか必要なものがあります。
.targets
デフォルトでcopylocal(<Private>
正確にはタグ)をfalseにするファイルを作成します。- ターゲットを
.csproj
ファイルにインポートします。タグを閉じる前に、最後の行に追加できます。</Project>
のようになります<Import Project="..\Build\yourtarget.targets" />
。
現在、このターゲットを持つ各プロジェクトでは、デフォルトでcopylocalが無効になっています。
欠点は、新しいファイルを含め、すべてのcsprojファイルを変更する必要があることです。VSプロジェクトテンプレートを変更することで、新しいプロジェクトの問題を回避できます。ブログ記事で説明する代わりに、(同じzipファイルで)Class.cs
変更する必要があります。Class.vstemplate
そのアプローチでは、もう1つの問題があります。それはパス自体です。新しく生成されたcsprojファイルでハードコードされた相対パスを使用する場合、それらは間違っている可能性があります(フラットなプロジェクト構造を持っている場合を除く)。
あなたはできる:
- VSに正しい相対パスを生成させます。それを行う方法がわからず、それが可能かどうかさえわかりません。
- それを無視して、新しいcsprojごとに手動でパスを変更します(新しいプロジェクトの数によっては、理想的ではありませんが、許容できる場合があります)。
- 相対パスの代わりに環境変数を使用してください。その場合、すべての開発者は同じ変数セットを必要とします。
そのためのより良い解決策があるはずですが、まだそれを見つけていません。
msbuild v 15以降では、ソースを含むルートフォルダーにDirectory.Build.propsという単一のファイルをコピーできます。
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemDefinitionGroup>
<Reference>
<Private>False</Private>
</Reference>
<ProjectReference>
<Private>False</Private>
</ProjectReference>
</ItemDefinitionGroup>
</Project>
これ以上することはありません!これは、VisualStudio2017およびvNextビルドでもうまく機能します。ファイルを有効にするには、Visual Studioを閉じてから、ソリューションを再度開く必要がある場合があります。
(ya23の回答で提案されているように).targetsファイルを使用しないため.csproj
、テキストエディターでプロジェクトファイルを手動で編集し、次の<Private>
ように要素を参照に追加します。
<Reference Include="[...]">
<Private>False</Private>
[...]
</Reference>
要素の値<Private>
は、「ローカルコピー」プロパティの値と一致します。たとえば、<Private>
がFalseに設定されている場合、「ローカルコピー」もfalseになります。
これをバンピングするのは、これを正確に許可するnugetパッケージがあるように見えるからです...
https://nuget.org/packages/CopyLocalFalse
まだ試していませんが、お役に立てば幸いです。
@herzbubeによって投稿されたソリューションに関して、 .csprojファイル内のすべて(またはほとんど)の参照に対して「ローカルコピー」をオフにする場合は<Private>False</Private>
、それぞれに個別に設定する必要はありませんReference
。次のように入力するだけです。.csprojに直接:
<ItemDefinitionGroup>
<Reference>
<Private>False</Private>
</Reference>
</ItemDefinitionGroup>
これは、で参照されるプロジェクトには影響しません<ProjectReference>
が、代わりに、または同様に、次のプロジェクトに対して同じことを行うことができます。
<ItemDefinitionGroup>
<ProjectReference>
<Private>False</Private>
</ProjectReference>
</ItemDefinitionGroup>
これらの両方が必要な場合は、それらを1つのグループにマージできます。
<ItemDefinitionGroup>
<Reference>
<Private>False</Private>
</Reference>
<ProjectReference>
<Private>False</Private>
</ProjectReference>
</ItemDefinitionGroup>
これらのブロックは、それらの下に表示される参照にのみ適用されるため、これらのオーバーライドを最初の実際の前に<Reference … >
配置するか<ProjectReference … >
、影響を与えたいことを確認してください。次に、実際にローカルにコピーしたいものがいくつかある場合は、今度はを使用して、それらを個別に(つまり、個別のタグ自体の中で)オーバーライドすることができますTrue
。
より高度なケースでは、同じ.csprojファイルでオーバーライド値をTrueとFalseの間で複数回切り替えることができます。もう1つの高度な手法は、参照の一部をこれらのブロックの下に配置し、他の参照を上に配置して、後者が影響を受けないようにすることです。
これらすべてにより、.csprojのXMLがよりクリーンで読みやすくなります。しかし、さらに良いニュースがあるので、読んでください...
どのプロジェクトにマークを付けるかについて<Private>False</Private>
は、通常、特定の状況によって異なりますが、初心者のために誰もができる基本的なことがあります。これは非常に基本的でシンプルかつ効果的なステップであり、MSBuildの信頼性を大幅に向上させます1.ビルド時のスピードアップ(およびほとんど欠点はありません)により、デフォルトの(つまり、プロジェクトごとのローカル)C#出力の場所を使用するすべての大規模なソリューションほとんどの場合、この調整を行う必要があります。
自明ではない数の相互依存関係を持つ複数のC#クラスライブラリを構築し、さらに1つのアプリケーション(実行可能ファイル)を構築するすべてのVisual Studioソリューションでは、次のようになります。
<ProjectReference>
すべてのクラスライブラリの.csprojの上部近くに、
<ProjectReference>
上記のブロックを挿入します。
理由:実行可能ファイルがその場所から実行されることはないため、.dllが参照するライブラリを独自のサブディレクトリに収集する必要はありません。このような横行するコピーは無駄な忙しい作業であり、ビルドを不必要に遅くする可能性があり、おそらく非常に劇的に遅くなる可能性があります。一方、ソリューションのアプリケーションの.csprojは変更しないでください。 理由:実行可能ファイルには、それぞれのサブディレクトリに必要なすべてのプライベートビルドライブラリが必要ですが、各アプリのビルドだけで、それぞれのサブディレクトリからアプリのサブディレクトリに各依存関係を個別に収集する必要があります。ディレクトリ。
クラスライブラリの.csprojは他の複数のクラスライブラリを参照する可能性があるため、これは完全に機能しますが、実行可能ファイルの.csprojは通常、別の実行可能ファイルを参照することはありません。したがって、すべてのローカルで構築されたライブラリについて、そのフォルダー内の唯一の.dllはそれ自体になりますが、すべてのローカルで構築されたアプリケーションには、それが参照するローカルで構築されたライブラリの完全なセットが含まれます。bin
便利なことに、ソリューションによって構築されていない参照ライブラリについては何も変更されません。これらは通常、の<Reference>
代わりに使用され<ProjectReference>
、以前のタグはまったく変更されていないためです。ただし、今述べた仮定に注意してください。一部のプロジェクトで違反している場合は、調整が必要になる場合があります。
[1.]信頼性の向上は、特に同時ビルドで、依存関係グラフの複数の互いに素なパスから同じライブラリを収集するときに発生する可能性のあるファイルの衝突に関連している可能性があります。