Es gab viele Beiträge zu diesem Thema, aber ich muss noch die "echte" Lösung finden.
Wie verwaltet man ihre Abhängigkeitsstruktur (sowohl Kompilierzeit als auch Laufzeit) mit MSBuild-Projektdateien (d. h. 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 besteht, und selbst wenn copy-local = true. Daher wird jede lose gekoppelte Komponente nicht kopiert.
Der Hack zur Lösung dieses Problems besteht darin, die Abhängigkeit im übergeordneten Projekt mit copy-local = true zu verknüpfen. 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 besteht darin, eine benutzerdefinierte Zieldatei zu schreiben und sie aus jeder Projektdatei aufzurufen: Ссылка . 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.
Wie ich feststellen kann, besteht die Microsoft-Lösung darin, jede Abhängigkeit im GAC für jeden Entwicklungs-, Test- und Produktionsrechner zu registrieren. Aber das ist dumm und nervig. Ich werde diese Option und gebildete Widerlegung nicht geben.
Um die GAC-Option zu vermeiden, wie kann man MSBuild verwenden, um eine Abhängigkeitsbaumstruktur zu verwalten, die nur Laufzeitabhängigkeiten enthält? Wie macht es Microsoft? Sicherlich werden keine benutzerdefinierten Zieldateien wie die im obigen Link angezeigt.
Ich hoffe, dass jemand aus einem Enterprise-.NET-Hintergrund dazu beitragen kann, einige echte Ratschläge zu geben. Sonst werde ich alle meine Build-Skripte in NAnt ( shudder ) neu schreiben müssen.
Danke allen.
AKTUALISIEREN
Als Reaktion auf einige Kommentare ist das folgende ein praktisches Beispiel für das Problem meines aktuellen Projekts.
Die App ist ein Webanwendungsprojekt, das eine Reihe von WCF-Services verfügbar macht. 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, lassen Sie es mich wissen, wenn Sie weitere Erläuterungen benötigen.
Mein aktueller Buildprozess besteht in der Verwendung von MSBuild zum Generieren eines Bereitstellungspakets für die Webanwendung (in TFS Build). 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 externe Domänen-DLL, die einen Verweis auf die interne Domänen-DLL enthält, die viele Verweise auf Bibliotheken von Drittanbietern und verschiedene indirekte und lose gekoppelte Abhängigkeiten enthält, die von Bibliotheken Dritter 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, dadurch wird das Problem klarer. Bitte lassen Sie mich wissen, wenn etwas unklar ist. Es ist schwer, so etwas zu beschreiben.
Wenn jemand ein ähnliches Problem hat, sprechen Sie bitte mit ihm und teilen Sie Ihre Erfahrungen.
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 gegeben, also werde ich versuchen, Ihnen einige Ideen zu geben, und ich hoffe, einer von ihnen funktioniert.
>Am einfachsten ist es, einen separaten Ordner mit all Ihren Abhängigkeiten einzurichten und eine Zieldatei zu erstellen, die sie in Ihren bin-Ordner kopiert. Wenn Sie Abhängigkeiten haben, die sich nicht häufig ändern, funktioniert das möglicherweise. Wenn ein anderes Team aus Ihrer Firma sie baut und sie sich häufig ändern, ist dieser Ansatz nicht gut.
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 geschrieben werden. Auf diese Weise müssen Sie nicht direkt auf sie verweisen.
Verwenden Sie NuGet. Sie haben ein separates Team, das lose gekoppelte Abhängigkeiten erzeugt. Es kann sinnvoll sein, ein lokales NuGet-Repository einzurichten und es für diese Zwecke zu verwenden. Ссылка
Ich hoffe, das hilft.
Tags und Links visual-studio msbuild dependency-management