Wie funktioniert Visual Studio bestimmen, was mit Multi-Projektlösungen in das Ausgabeverzeichnis kopiert werden?

stimmen
26

Lassen Sie uns sagen, dass wir eine Lösung mit der folgenden Struktur:

  • Project.DAL - Datenzugriffsschicht, hängt von einer niedrigeren Ebene Bibliothek, zB Oracle.DataAccess w / kopieren lokale = true
  • Project.BLL - Business-Logik-Schicht, verweist Project.DAL als Projekt
  • Project.UI - UI-Ebene, um ausführbare kompiliert, verweist Project.BLL, Standardprojekt

Wenn Project.UI kompiliert wird, ist VS intelligent genug Project.DAL.dll in das Ausgabeverzeichnis kopiert werden, aber es ist nicht intelligent genug, um herauszufinden, dass ich Oracle.DataAccess wollte auch in das Ausgabeverzeichnis kopiert werden für die Verteilung an Kunden .

Kann mir jemand erklären, warum das so ist? Ist es, weil es Oracle.DataAccess im GAC sieht und geht davon aus, dass die Kunden es im GAC als auch haben?

Es ist nicht so große Sache, aber es ist ein bisschen ärgerlich, dass jedes Mal, wenn ich eine neue Montage Verweis hinzuzufügen, muss ich es einrichten erinnern lokal kopieren und fügen Sie ein Element in meinem Build-Skript als auch zu kopieren.

Veröffentlicht am 09/12/2008 um 18:46
quelle vom benutzer
In anderen Sprachen...                            


4 antworten

stimmen
27

Eine Sache noch.

Wenn Sie die referenzierte DLL in Ihrem Code nicht verwenden überhaupt, wird es die Copylocal ignorieren und nicht kopieren zu Ihrem Ausgabeverzeichnis es.

Beantwortet am 14/02/2010 um 18:36
quelle vom benutzer

stimmen
25

Ja, Visual Studio wird im Folgenden eine DLL in den Ausgabepfad in eines der beiden Bedingungen kopieren:

  1. Die DLL wird verwiesen explizit mit Copylocal = true
  2. Die DLL wird ohne Copylocal referenziert oder implizit durch eine andere referenzierte DLL und ist nicht im GAC

Der Grund, warum es nicht-lokale Kopie, wenn die Datei in GAC ist, das heißt, wenn die Anordnung der Namensauflösung der GAC höchste Priorität hat, das heißt, auch wenn Sie eine (andere) lokale Kopie hat, wird die Version aus dem GAC verwendet werden.

Ich schlage vor, Sie ein Bibliotheksverzeichnis eingerichtet, in dem Sie alle externen Baugruppen setzen, auf die verwiesen werden. Dann setzen Sie einen automatischen MSBuild-Skript auf einem Computer (oder VM), die nicht die Oracle-Datei gac'ed hat (noch Visual Studio für diese Gründe installiert ist). Auf diese Weise wird die Datei in die Build kopiert werden, und Sie werden mehr Kontrolle darüber, was als erfolgt, wenn VS. mit

Beantwortet am 02/02/2009 um 17:49
quelle vom benutzer

stimmen
15

Ich hatte eine seltsame Situation, in der, obwohl die Baugruppe ein Projektverweis war und wurde mit „Copy Local“ zeigt mich als „True“ in dem Referenzeigenschaftenfenster verwiesen wurde die DLL nicht in das Ausgabeverzeichnis kopiert werden. Ich hatte eine frühere Version der DLL im GAC aber ich habe nicht sehen, warum dies die DLL kopiert verhindern soll.

Ich fand, dass durch das Projekt Entladen und manuell die XML-Projekt Referenz Bearbeitung wie folgt:

<ProjectReference Include="..\SomeProject.csproj">
  <Project>{11111111-1111-1111-1111-111111111111}</Project>
  <Name>Some Project Name</Name>
  <Private>True</Private>
</ProjectReference>

Die DLL wurde das ouput Verzeichnis kopiert , wie erwartet. Ich fand , dass gerade im Eigenschaftenfenster auf True Copy Local Einstellung bedeutete das <Private>Element vollständig fehlt, aber im Fall es wird auf false gesetzt es war mit einem Wert von „False“.

Beantwortet am 13/05/2010 um 16:47
quelle vom benutzer

stimmen
3

@RenniePet Hier ist ein Link zu einem Blog, die das Verfahren RenniePet in einem Kommentar oben beschriebenen beschreibt (wenn Sie nicht wollen, Ihre Projektdatei manuell bearbeiten als @Shaun vorgeschlagen):

http://blogs.msdn.com/b/jjameson/archive/2009/11/18/the-copy-local-bug-in-visual-studio.aspx

Beantwortet am 29/11/2013 um 00:06
quelle vom benutzer

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more