MSBuild kopiert keine Referenzen (DLL-Dateien), wenn Projektabhängigkeiten in der Lösung verwendet werden

Question

Ich habe vier Projekte in meiner Visual Studio-Lösung (alle auf .NET 3.5 ausgerichtet) - für mein Problem sind nur diese beiden wichtig:

1. MyBaseProject <- diese Klassenbibliothek verweist auf eine Drittanbieter-DLL-Datei (elmah.dll)
2. MeinWebProjekt1 <- dieses Webanwendungsprojekt hat einen Verweis auf MyBaseProject

Ich habe den Verweis auf elmah.dll zu MyBaseProject in Visual Studio 2008 durch Klicken auf "Verweis hinzufügen..." Wählen Sie auf der Registerkarte "Durchsuchen" die Datei "elmah.dll" aus.

Die Eigenschaften der Elmah-Referenz sind wie folgt:

• Aliasnamen - global
• Lokal kopieren - wahr
• Kultur -
• Beschreibung - Fehlerprotokollierungsmodule und -handler (ELMAH) für ASP.NET
• Dateityp - Baugruppe
• Pfad - D:\webs\otherfolder\_myPath\__tools\elmah\Elmah.dll
• Gelöst - Wahr
• Laufzeitversion - v2.0.50727
• Angegebene Version - false
• Starker Name - falsch
• Version - 1.0.11211.0

で MeinWebProjekt1 Ich habe den Verweis auf das Projekt MyBaseProject von hinzugefügt: "Referenz hinzufügen..." Registerkarte "Projekte", Auswahl von "MyBaseProject". Die Eigenschaften dieser Referenz sind die gleichen, mit Ausnahme der folgenden Mitglieder:

• Beschreibung -
• Pfad - D:\webs\CMS\MyBaseProject\bin\Debug\MyBaseProject.dll
• Version - 1.0.0.0

Wenn ich den Build in Visual Studio Die Datei elmah.dll wird in mein MyWebProject1's Mülltonne Verzeichnis, zusammen mit MyBaseProject.dll!

Wenn ich jedoch sauber mache und MSBuild für die Lösung (über D:\webs\CMS > C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe /t:ReBuild /p:Configuration=Debug MyProject.sln) die elmah.dll fehlt im bin-Verzeichnis von MyWebProject1 - obwohl der Build selbst keine Warnungen oder Fehler enthält!

Ich habe bereits sichergestellt, dass die .csproj von MyBaseProject die privat Element mit dem Wert "true" (das sollte ein Alias für " lokal kopieren " in Visual Studio):

<Reference Include="Elmah, Version=1.0.11211.0, Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\mypath\__tools\elmah\Elmah.dll</HintPath>
    **<Private>true</Private>**
</Reference>

(Das private Tag erschien standardmäßig nicht in der .csproj-xml, obwohl Visual Studio sagte, dass "copy local" true sei. Ich schaltete "copy local" auf false - gespeichert - und setzte es wieder auf true - gespeichert!)

Was ist mit MSBuild los? Wie bekomme ich die (elmah.dll) Referenz in MyWebProject1's bin kopiert?

Ich möchte NICHT zu jedem Postbuild-Befehl eines Projekts eine Kopieraktion hinzufügen! (Stellen Sie sich vor, ich hätte viele Projekte, die von MyBaseProject abhängen!)

Answer 1

Die Referenzierung von Baugruppen, die während der Erstellung nicht verwendet werden, ist nicht die richtige Vorgehensweise. Sie sollten Ihre Build-Datei so erweitern, dass sie die zusätzlichen Dateien kopiert. Entweder durch Verwendung eines Post-Build-Ereignisses oder durch Aktualisierung der Eigenschaftsgruppe.

Einige Beispiele finden Sie in anderen Beiträgen

• MSBuild zum Kopieren dynamisch generierter Dateien als Teil der Projektabhängigkeit
• VS2010 Wie kann man Dateien in ein Projekt einbinden, um sie während der Erstellung oder Veröffentlichung automatisch in das Ausgabeverzeichnis zu kopieren?

Answer 2

Ein weiteres Szenario, in dem dieses Problem auftritt, ist die Verwendung des älteren Projekttyps "Web Site" in Visual Studio. Bei diesem Projekttyp ist es nicht möglich, auf .dlls zu verweisen, die sich außerhalb der eigenen Verzeichnisstruktur (aktueller Ordner und abwärts) befinden. In der obigen Antwort sieht Ihre Verzeichnisstruktur also wie folgt aus:

Wenn ProjectX und ProjectY übergeordnete/untergeordnete Verzeichnisse sind und ProjectX auf A.dll verweist, die wiederum auf B.dll verweist, und B.dll sich außerhalb der Verzeichnisstruktur befindet, z. B. in einem Nuget-Paket auf der Wurzel (Pakete), dann wird A.dll einbezogen, B.dll jedoch nicht.

Answer 3

Dies erfordert das Hinzufügen einer .targets Datei zu Ihrem Projekt hinzufügen und festlegen, dass sie in den Include-Abschnitt des Projekts aufgenommen wird.

Siehe meine Antwort hier für das Verfahren.

Answer 4

Ich hatte das gleiche Problem, und die DLL war eine dynamisch geladene Referenz. Um das Problem zu lösen, habe ich ein "using" mit dem Namespace der dll hinzugefügt. Jetzt wird die Dll in den Ausgabeordner kopiert.

Answer 5

Ich hatte heute ein ähnliches Problem, und dies ist ganz sicher nicht die Antwort auf Ihre Frage. Aber ich möchte alle informieren und vielleicht einen kleinen Einblick geben.

Ich habe eine ASP.NET-Anwendung. Der Erstellungsprozess ist auf bereinigen und dann erstellen festgelegt.

Ich habe zwei Jenkins CI Skripte. Eines für die Produktion und eines für Staging. Ich habe meine Anwendung in Staging bereitgestellt und alles hat gut funktioniert. Bei der Bereitstellung in der Produktion fehlte eine DLL-Datei, auf die verwiesen wurde. Diese DLL-Datei befand sich nur im Stammverzeichnis des Projekts. Nicht in einem NuGet-Repository. Die DLL war festgelegt auf do not copy .

Das CI-Skript und die Anwendung waren bei beiden Bereitstellungen identisch. Auch nach der Bereinigung und Bereitstellung in der Staging-Umgebung wurde die DLL-Datei im Bereitstellungsort der ASP.NET-Anwendung ersetzt ( bin/ ). Dies war in der Produktionsumgebung nicht der Fall.

Es stellte sich heraus, dass ich in einem Testzweig einen Schritt in den Erstellungsprozess eingefügt hatte, um diese DLL-Datei in das Verzeichnis bin Verzeichnis. Jetzt kommt der Teil, der eine Weile gedauert hat, um herauszufinden. Der CI-Prozess hat sich nicht selbst bereinigt. Die DLL wurde im Arbeitsverzeichnis belassen und versehentlich mit der ASP.NET .zip-Datei gepackt. Im Produktionszweig wurde die DLL-Datei nie auf die gleiche Weise kopiert, und sie wurde nie versehentlich bereitgestellt.

TLDR; Prüfen Sie, ob Sie wissen, was Ihr Build-Server tut.