web-dev-qa-db-ja.com

「ローカルのコピー」をデフォルトでFalseに設定しますか？

Visual Studioの「ローカルコピー」のデフォルトオプションをFalseに設定できますか？ほとんどの場合、プロジェクトの依存関係としてdllを追加するとき、ローカルコピープロパティをFalseに設定します。デフォルトではTrueです。 Visual Studioのデフォルトの動作を変更する方法はありますか？ （2008）

visual-studiocopy-local
36
dr pain

いいえ-Visual Studioは内部ルールセットを使用して、[ローカルにコピー]を何に設定するかを決定します。

から [〜＃〜] msdn [〜＃〜] ：

  1. 参照がプロジェクト間参照と呼ばれる別のプロジェクトである場合、値はtrueです。
  2. アセンブリがグローバルアセンブリキャッシュにある場合、値はfalseです。
  3. 特殊なケースとして、mscorlib.dll参照の値はfalseです。
  4. アセンブリがFramework SDKフォルダーにある場合、値はfalseです。
  5. それ以外の場合、値はtrueです。
38
Leom Burke

実際にできます。あなたはいくつかのものが必要です：

  1. Copylocalとなる.targetsファイルを作成します（正確には<Private>タグ） デフォルトではfalse 。
  2. ターゲットを.csprojファイルにインポートします。最後の行に追加できます。</Project>タグを閉じる前は、<Import Project="..\Build\yourtarget.targets" />のようになります。

これで、このターゲットを持つ各プロジェクトでは、デフォルトでcopylocalが無効になっています。

欠点は、新しいものを含め、すべてのcsprojファイルを変更する必要があることです。 VSプロジェクトテンプレートを変更する で、新しいプロジェクトの問題を回避できます。ブログ記事に記載されているClass.csの代わりに、Class.vstemplateを（同じZipファイルで）変更する必要があります。

そのアプローチでは、もう1つの問題があります。それはパス自体です。新しく生成されたcsprojファイルでハードコードされた相対パスを使用する場合、フラットなプロジェクト構造でない限り、それらは間違っている可能性があります。

あなたはできる：

  • VSに正しい相対パスを生成させます。それを行う方法とそれが可能かどうかさえわからない。
  • これを無視し、新しいcsprojごとに手動でパスを変更します（使用している新しいプロジェクトの数によっては、理想的ではありませんが、許容できる場合があります）。
  • 相対パスの代わりに環境変数を使用します。その場合、すべての開発者が同じ変数セットを必要とします。

そのためのより良い解決策があるはずですが、それをまだ見つけていません。

27
ya23

（ya23の回答で提案されているように）.targetsファイルは使用しないため、テキストエディターで.csprojプロジェクトファイルを手動で編集し、<Private>要素を参照に追加するだけです。この：

<Reference Include="[...]">
  <Private>False</Private>
  [...]
</Reference>

<Private>要素の値は、「ローカルをコピー」プロパティの値と一致します。たとえば、<Private>がFalseに設定されている場合、「ローカルにコピー」もfalseになります。

7
herzbube

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>

これ以上することはありません！これは、Visual Studio 2017およびvNextビルドでもうまく機能します。 Visual Studioを閉じてから、ソリューションを再度開いてファイルを有効にする必要がある場合があります。

https://docs.Microsoft.com/en-us/visualstudio/msbuild/customize-your-build#directorybuildprops-and-directorybuildtargets

6
gReX

ちょうどこれを許可するnugetパッケージがあるように見えるのでこれをぶつけます...

https://nuget.org/packages/CopyLocalFalse

まだ試していない、それが役に立てば幸いです。

4
mabian69

@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 ...>の前にこれらのオーバーライドを必ず配置してください。次に、do実際にローカルにコピーしたいものがいくつかある場合は、それらをオーバーライドできますback個別に（つまり、個別のタグ自体の中で）、今回はTrueを使用します。

より高度なケースでは、同じ.csprojファイルで上書き値をTrueとFalseの間で何度も切り替えることができます。もう1つの高度な手法は、これらの参照の下にいくつかの参照を戦略的に配置し、他の参照を上に配置することです。これにより、後者は影響を受けません。

これらすべてにより、.csproj内のXMLがよりクリーンで読みやすくなります。しかし、さらに良いニュースがあるので、読んでください...

どのプロジェクトを<Private>False</Private>としてマークするかを選択する場合、これは通常、特定の状況に依存しますが、基本的なものがありますすべての人canおよびshould do 初心者向け。それはとても基本的でシンプルで効果的な一歩であり、そのような巨大なMSBuild信頼性の改善を提供します1。 ビルド時のスピードアップ-そして、マイナス面がほとんどない-デフォルト（つまり、プロジェクトごとのローカル）を使用するすべての大規模なソリューションC＃出力場所は、ほとんど常にこの調整を行う必要があります。

複数のC＃クラスライブラリを任意の数の<ProjectReference>相互依存関係でビルドし、さらに1つアプリケーション（つまり実行可能ファイル）をビルドするすべてのVisual Studioソリューション）：

  1. すべてのclass libraryの.csprojの上部に、上記の<ProjectReference>ブロックを挿入します。
    理由：実行可能ファイルがその場所から実行されることはないため、参照するライブラリを独自のサブディレクトリに収集するために。dllを使用する必要はありません。このような乱暴なコピーは無駄な作業であり、ビルドを不必要に遅くする可能性があります。

  2. 一方、notソリューションの.csprojを変更します（applications。
    理由：実行可能ファイルには、それぞれのサブディレクトリに必要なすべての非公開で作成されたライブラリが必要ですが、各アプリのビルドだけで、それぞれのサブディレクトリから直接各依存関係を個別に収集する必要があります。アプリのサブディレクトリに。

クラスライブラリの.csprojが他の複数のクラスライブラリを参照する可能性があるため、これは完全に機能しますが、実行可能ファイルの.csprojは通常、別の実行可能ファイルを参照することはありません。したがって、すべてのローカルで構築されたライブラリでは、binフォルダー内の。dllがそれ自体になりますが、すべてのローカルで構築されたアプリケーションには、ローカルで構築されたライブラリの完全なセットが含まれます参照。

通常、これらは<Reference>ではなく<ProjectReference>を使用し、以前のタグをまったく変更しなかったため、ソリューションによってビルドされない参照ライブラリの変更はありません。しかし、今述べた仮定に注意してください。プロジェクトの一部に違反している場合は、調整が必要になることがあります。

[1.]信頼性の向上は、特に並行ビルドで、依存関係グラフの複数のばらばらのパスから同じライブラリを収集するときに発生する可能性があるファイルの衝突に関連している可能性があります。

2
Glenn Slayden