Set „Copy Local“ auf False standardmäßig?

Question

gesetzt Kann ich die Standard-Option "Copy Local" in Visual Studio auf False? In den meisten Zeiten, in denen ich eine DLL als Abhängigkeit von einem Projekt hinzufügen, mag ich die Copy Local Eigenschaft auf False fest. Standardmäßig ist es wahr. Gibt es eine Möglichkeit das Standardverhalten von Visual Studio zu ändern? (2008)

Answer 1

Nein -. Visual Studio verwendet einen internen Satz von Regeln, um zu bestimmen, was zu kopieren Lokale zu setzen

MSDN :

  

  
1. Wenn die Referenz ein weiteres Projekt, ein Projekt zu Projekt Referenz genannt wird, dann ist der Wert true .
  
2. Wenn die Assembly im globalen Assembly-Cache gefunden wird, ist der Wert false .
  
3. Als Sonderfall, der Wert für die mscorlib.dll Referenz false .
  
4. Wenn die Assembly in dem Framework SDK-Ordner gefunden wird, dann wird der Wert false .
  
5. Andernfalls ist der Wert true .
  

Answer 2

Eigentlich Sie können. Sie müssen ein paar Dinge:

1. Erstellen .targets-Datei, die Copylocal (<Private> Tag, um genau zu sein) false per Default macht.
2. Importieren das Ziel in .csproj Dateien. Sie können es in der letzten Zeile hinzufügen, bevor </Project> Tag zu schließen, ist es wie <Import Project="..\Build\yourtarget.targets" /> aussehen.

Jetzt jedes Projekt mit diesem Ziel hat Copylocal standardmäßig deaktiviert.

Der Nachteil ist, dass Sie benötigen jeden csproj Datei, einschließlich neue zu ändern. Sie können das neue Projekt Ausgabe von die VS Projektvorlage ändern. Statt Class.cs in dem Blog-Artikel beschrieben wird, müssen Sie Class.vstemplate (in der gleichen ZIP-Datei) ändern.

Mit diesem Ansatz gibt es ein weiteres Problem - der Weg selbst. Wenn Sie in relativen Pfad fest einprogrammiert verwenden neu generierten csproj Dateien, können sie falsch sein (es sei denn, Sie flache Projektstruktur haben).

Sie können:

• Erstellen VS korrekten relativen Pfad zu erzeugen. Nicht sicher, wie das zu tun, und wenn es das ist auch möglich.
• es ignorieren und den Pfad manuell für jeden neuen csproj ändern (abhängig von der Anzahl der neuen Projekt, das Sie haben, wenn auch nicht ideal, das tolerierbar sein kann).
• Verwenden Sie die Umgebungsvariable anstelle von relativem Pfad. In diesem Fall müssen alle Entwickler die gleiche Variable gesetzt.

Es muss eine bessere Lösung für das sein, aber noch nicht gefunden es noch.

Answer 3

Wir haben keine .targets Dateien verwenden (wie in der Antwort von ya23 vorgeschlagen), so dass wir nur die .csproj Projektdatei manuell in einem Texteditor bearbeiten und das <Private> Element zur Referenz hinzufügen, wie diese:

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

Der Wert des <Private> Elements entspricht den Wert der „Copy local“ Eigenschaft. Zum Beispiel, wenn <Private> auf False gesetzt ist, dann wird „lokale Kopie“ ist auch falsch ..

Answer 4

Bumping dies, weil es scheint, gibt es jetzt ein nuget Paket ermöglicht genau dies ...

https://nuget.org/packages/CopyLocalFalse

Haben Sie noch nicht versucht, nur hoffen, dass es hilft.

Answer 5

Beginnend mit msbuild v 15 können Sie eine einzelne Datei genannt kopieren Directory.Build.props im Stammordner, die Ihre Quelle enthält:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemDefinitionGroup>
  <Reference>
    <Private>False</Private>
  </Reference>
  <ProjectReference>
     <Private>False</Private>
  </ProjectReference>
</ItemDefinitionGroup>
</Project>

Nichts mehr zu tun! Das funktioniert gut mit Visual Studio 2017 und auch die vNext gebaut. Können Sie Visual Studio und als offen Ihre Lösung wieder nehmen Sie die Datei Effekt schließen müssen.

https: // docs .microsoft.com / en-us / Visual Studio / msbuild / customize-your-build # directorybuildprops-and-directorybuildtargets

Answer 6

Im Hinblick auf die Lösung von @herzbube geschrieben, wenn Sie wollen „Copy Local“ auszuschalten für alle (oder die meisten) der Referenzen in Ihrer CSPROJ Datei, nicht wahr setzen müssen <Private>False</Private> individuell auf jedem Reference, können Sie nur setzen die folgenden direkt in der CSPROJ :

<ItemDefinitionGroup>
  <Reference>
    <Private>False</Private>
  </Reference>
</ItemDefinitionGroup>

Dies hat keine Auswirkungen auf Projekte mit <ProjectReference> verwiesen, aber Sie können das gleiche tun - entweder statt oder auch - für die:

<ItemDefinitionGroup>
  <ProjectReference>
    <Private>False</Private>
  </ProjectReference>
</ItemDefinitionGroup>

Wenn Sie diese beiden wollen, können Sie sie in einer einzigen Gruppe zusammenführen:

<ItemDefinitionGroup>
  <Reference>
    <Private>False</Private>
  </Reference>
  <ProjectReference>
    <Private>False</Private>
  </ProjectReference>
</ItemDefinitionGroup>

Stellen Sie sicher, dass diese Überschreibungen setzen vor dem ersten tatsächlichen <Reference ...> oder <ProjectReference ...> Sie beeinflussen wollen, weil diese Blöcke nur auf solche Referenzen gelten, die unter ihnen erscheinen. Wenn dann gibt es ein paar, dass Sie Sie wollen tatsächlich lokal kopiert werden, können Sie einfach überschreiben diese zurück einzeln (dh innerhalb der einzelner Tag selbst), diesmal mit True.

Für fortgeschrittenere Fälle können Sie die zwingenden Wert zurück schalten und her zwischen True und False mehrmals in der gleichen CSPROJ Datei. Eine andere fortgeschrittene Technik wäre strategisch einige Ihrer Referenzen unterhalb dieser Blöcke zu platzieren, und andere oben, so dass die letztere nicht beeinträchtigt werden.

All dies sollte die XML in Ihre CSPROJ viel sauberer und einfacher zu lesen. Aber es gibt noch mehr gute Nachrichten, lesen Sie so weiter ...

---

Wie zur Auswahl, welche Projekte sollten <Private>False</Private> gekennzeichnet sein werden hängt dies in der Regel von der spezifischen Situation, aber es ist etwas Grundsätzliches alle können und sollte tun für den Anfang. Es ist ein Schritt so einfach, einfach und effektiv und liefert so große MSBuild Zuverlässigkeit Verbesserungen ¹ und Build-Zeit Speedup -. Und mit wenig Nachteile - dass jede große Lösung dass verwendet den Standard (dh lokales pro Projekt) C # Ausgabestellen sollten fast immer diese Einstellung vorzunehmen:

  

In jeden und jede Visual Studio-Lösung, die in dem Aufbau einer mehr mehrere C # Klassenbibliotheken mit jeder nicht-trivialer Anzahl von <ProjectReference> Interdependenzen und der gipfelt baut Anwendungen (dh ausführbare Dateien):

     

  

1. In der Nähe der Spitze der CSPROJ für jeden Klassenbibliothek , legen Sie die <ProjectReference> Block gezeigt oben.
     Grund: Es gibt keine Notwendigkeit für ein .dll eine der Bibliotheken es Verweise in ein Unterverzeichnis der eigenen zu sammeln, da keine ausführbaren jemals von diesem Ort ausgeführt wird. Solche grassierende Kopieren nutzlos busywork ist und Sie Ihre Build unnötig verlangsamt werden kann, möglicherweise ziemlich dramatisch.

  

2. Auf der anderen Seite, machen nicht Ändern Sie den CSPROJ für jede Ihrer Lösung Anwendungen .
     Grund: Ausführbare Dateien müssen alle privat gebauten Bibliotheken sie in ihren jeweiligen Unterverzeichnissen müssen, aber das Build für jedes allein App soll verantwortlich sein für jede Abhängigkeit einzeln zu sammeln, direkt von seinem jeweiligen Unterverzeichnis, in den Teil App Verzeichnis.

  

Das funktioniert perfekt, weil die CSPROJ für eine Klassenbibliothek mehr andere Klassenbibliotheken verweisen kann, aber die CSPROJ für eine ausführbare Datei in der Regel verweist nie wieder eine ausführbare Datei. So kann jeder lokal erstellten Bibliothek, die nur .dll in seinem bin Ordner selbst sein wird, während jeder lokal erstellten Anwendung den vollen Satz von lokal erstellten Bibliotheken es Verweise enthalten wird.

Günstig, ändert sich nichts für die referenzierten Bibliotheken, die nicht von Ihrer Lösung gebaut werden, da diese in der Regel Verwendung <Reference> InsteAnzeige von <ProjectReference>, und wir haben nicht den ehemaligen Tag überhaupt ändern. Aber machen die Annahme, beachten Sie gerade erwähnt; wenn es von einigen Ihrer Projekte verletzt wird, müssen Sie eventuell einige Anpassungen vornehmen.

_{[1.] Zuverlässigkeit Verbesserungen Datei Kollisionen zusammenhängen könnte, die auftreten können, wenn die gleiche Bibliothek von mehreren disjunkten Pfaden in einem Abhängigkeitsgraphen zu sammeln, vor allem in Concurrent baut.}