Die Abhängigkeitsverwaltung in Visual Studio/MSBuild

Question

Es gab viele Beiträge zu diesem Thema, aber ich muss noch die "echte" Lösung finden.

Wie schafft man ihren Abhängigkeitsbaum (beide kompilieren und Laufzeit) mit MSBuild-Projektdateien (das heißt Visual Studio Projektdateien über Projekt- und Dateireferenzen)?

Es ist bekannt, dass Projektreferenzen von untergeordneten Projekten nicht in ein bin-Anwendungsverzeichnis kopiert werden, wenn keine Kompilierzeitreferenz vorhanden ist, selbst wenn eine Laufzeitabhängigkeit vorliegt, und selbst wenn copy-local = true. Daher wird jede lose gekoppelte Komponente nicht kopiert.

Der Hack, dieses Problem zu lösen, ist die Abhängigkeit in dem übergeordneten Projekt mit Kopie-local = true enthält. Dies zerstört jedoch im Grunde Ihren Abhängigkeitsbaum, da Sie nicht mehr wissen, wo die Abhängigkeit liegt und schließlich, wenn Ihre App wächst und morpht, Sie mit einer Version von DLL-Hölle enden. Ihr übergeordnetes Projekt endet mit 10 bis 100 DLLs, von denen die meisten Laufzeitabhängigkeiten von DLLs in untergeordneten Projekten sind.

Ein weiterer Hack ist eine benutzerdefinierte Zieldatei zu schreiben und von jeder Projektdatei aufrufen: http://blog.alexyakunin.com/2009/09/making-msbuild-visual-studio-to.html. Aber sicherlich gibt es eine bessere Option. Das ist so eine Sache mit Brot und Butter. Java-Entwickler müssen sich nie mit solchen trivialen Problemen herumschlagen.

Von dem, was ich sammeln kann, die Microsoft Weg, dieses Problem zu lösen, ist jede Abhängigkeit im GAC für jeden Entwickler, Test- und Produktionsmaschine zu registrieren. Aber das ist dumm und nervig. Ich werde diese Option und gebildete Widerlegung nicht geben.

die GAC Option vermeiden, wie könnte man MSBuild verwenden, um eine Abhängigkeitsstruktur zu verwalten, die Abhängigkeiten Laufzeit nur beinhaltet? Wie macht es Microsoft? Sicherlich werden keine benutzerdefinierten Zieldateien wie die im obigen Link angezeigt.

Ich hoffe, dass jemand von einem Unternehmen .NET Hintergrund treten kann und einige echte Beratung bieten. Sonst werde ich einfach alle meine Build-Skripte in NAnt (shudder) neu schreiben müssen.

Vielen Dank.

UPDATE

In Reaktion auf einige Kommentare, die folgenden ein praktisches Beispiel für die Ausgabe von meinem aktuellen Projekt.

Die App ist ein Web Application Projekt, das eine Reihe von WCF-Dienst bereitstellt. Es enthält eine externe Domänen-DLL mit den externen Serviceklassen und eine interne Domänen-DLL mit internen Service-POCOs, Domänenobjekten und DAOs. Es gibt eine separate Integrations-DLL mit Schnittstellen (DTOs) für alle internen Domänenklassen, die es uns ermöglicht, die externen und internen Domänen vollständig zu entkoppeln. Das Ganze ist mit Spring.net verbunden. Ich hoffe, das ist klar, lass es mich wissen, wenn du mehr Klarheit brauchst.

Mein aktueller Build-Prozess ist MSBuild zu verwenden, um ein Bereitstellungspaket für die Web-Anwendung (in TFS Build-) zu erzeugen. Während also die gesamte Lösung anfänglich erstellt wird, wird nur die Ausgabe der Webanwendung gepackt. Daher wird die Webanwendung als Abhängigkeits-Root behandelt, und ich erwarte, dass alle lose gekoppelten untergeordneten Referenzen beim Build kopiert werden, wenn sie auf 'copy-always = true' gesetzt sind. Die Webanwendung enthält also einen Verweis auf die DLL der externen Domäne, die einen Verweis auf die DLL der internen Domäne enthält, die viele Verweise auf Bibliotheken von Drittanbietern und verschiedene indirekte und lose gekoppelte Abhängigkeiten enthält, die von Bibliotheken von Drittanbietern benötigt werden.

Das Problem tritt auf, wenn eine Drittanbieterabhängigkeit in der internen Domänen-DLL vorhanden ist, z. oracle.dataaccess, das zur Laufzeit von NHibernate benötigt wird. Selbst wenn ich für diese DLLs 'copy-always = true' festlege, werden sie nicht in das Web-App-Paket kopiert. Die einzige Möglichkeit, sie in das Paket aufzunehmen, besteht darin, diese DLLs den Referenzen der Web-App hinzuzufügen. Ich möchte das nicht machen, weil ich keinen sinnvollen Abhängigkeitsbaum mehr habe.

Ich hoffe, dass dies das Problem klarer macht. Bitte lassen Sie mich wissen, wenn etwas unklar ist. Es ist schwer, so etwas zu beschreiben.

Wenn jemand auch ein ähnliches Problem hat, sprechen Sie bitte Ihre Erfahrungen aus.

Answer 1

Ich möchte Ihnen wirklich eine bessere Antwort geben, aber leider haben Sie nicht genug Informationen über Ihre Lösung/Projekte und Ihre Abhängigkeiten, also werde ich versuchen, Ihnen einige Ideen zu geben und ich hoffe, einer von ihnen funktioniert.

1. Die einfachste Sache zu tun, wie Sie gesagt hat, einen separaten Ordner mit allen Ihren Abhängigkeiten einzurichten und Zieldatei erstellen, die sie zu Ihrem Ordner ist kopiert. Wenn Sie Abhängigkeiten haben, die sich nicht häufig ändern, funktioniert das möglicherweise. Wenn ein anderes Team aus Ihrem Unternehmen sie baut und sie sich häufig ändern, ist dieser Ansatz nicht gut.

2. Ein weiterer einfacher Ansatz - wenn Sie nur auf Ihre Abhängigkeiten von Ihrer Lösung verweisen, können Sie den Build-Pfad ändern, sodass sie direkt in den Ordner bin Ihres Hauptprojekts erstellt werden. Auf diese Weise müssen Sie sie nicht direkt referenzieren.

3. Verwenden Sie NuGet. Sie haben ein eigenes Team lose gekoppelten Abhängigkeiten produzieren sie einen Sinn machen, können lokale NuGet Repository einzurichten und zu verwenden es, dass für http://juristr.com/blog/2012/04/using-nuget-to-distribute-our-company/

Ich hoffe, das hilft.