Platzieren Sie alle Ausgabe-DLLs in einem gemeinsamen Verzeichnis von Visual Studio

Question

Ich habe verschiedene Lösungen, bei denen einige Projekte möglicherweise von der Ausgabe von Projekten in anderen Lösungen abhängen.Um dies zu verwalten, habe ich DLL-Dateien aus dem Ordner /bin/ in jedem Projekt nach dem Build an einen gemeinsam genutzten Bibliotheksspeicherort kopiert und sie dann von dort in das abhängige Projekt kopiert bzw. auf sie verwiesen.

Wenn die Bibliothekslösung jedoch größer wird, wird dies tendenziell nicht mehr wartbar.Ich verbringe zu viel Zeit damit, Lösungsverzeichnisse im Windows Explorer zu durchsuchen, nach /bin/-Ordnern zu suchen und herauszufinden, welche oder welche DLL-Dateien ich jeweils benötige.

Gibt es eine Möglichkeit, Visual Studio einen Hinweis zu geben, den ich möchte? alle Projekte in einer Lösung sollen dasselbe Ausgabeverzeichnis haben?Zum Beispiel ein /bin/-Ordner direkt unter dem Lösungsordner, wo alle Projekte stellen ihre Ergebnisse zur Verfügung.

Wenn möglich, möchte ich dies ohne fest codierte Post-Build-Ereignisse erreichen, die die Dateien kopieren, da dies fehlschlägt, wenn eine Projektausgabe den Dateinamen ändert oder eine weitere Datei hinzufügt.Ich würde lieber den Speicherort des tatsächlichen Ausgabeverzeichnisses ändern – den Speicherort von $(OutDir), wenn Sie so wollen.

Answer 1

Sie können das Ausgabeverzeichnis in den einzelnen Projekteigenschaften festlegen.

Klicken Sie mit der rechten Maustaste auf das Projekt und wählen Sie es aus Properties

Für C# ist es eines der Build Eigenschaftenseite, unter Output, Output directory.

In VB.Net-Projekten ist es auf der Compile Registerkarte, im Textfeld oben.

Answer 2

Ich weiß, dass Sie gesagt haben, dass Sie keine Post-Build-Ereignisse verwenden möchten, aber Ihre Begründung, warum das nicht der Fall ist, hat mich fasziniert.Es hört sich so an, als ob Sie den Namen der DLL in Ihrem Post-Build-Ereignis hart codieren würden.Das lässt sich leicht vermeiden.

xcopy "$(TargetDir)*" "c:\common\" /Y

Der * würde nur verursachen alles in Ihrem bin/Debug/-Ordner, um in Ihren gemeinsamen Ordner kopiert zu werden.Sie können DLLs auch einfach kopieren, wenn Sie möchten.Oder, wenn Sie verwenden $(TargetPath), kopieren Sie nur die eine DLL, die das Ergebnis des Projekts ist, und keine anderen zugehörigen Abhängigkeiten.

AKTUALISIEREN

Wir machen es so, dass der gesamte bin-Ordner jedes Projekts in einen kopiert wird subOrdner.Angenommen, Sie haben zwei Projekte, WebUtil Und HtmlParser, wobei WebUtil von HtmlParser abhängt.Verwenden Sie für beide Projekte xcopy "$(TargetDir)*" "c:\common\$(ProjectName)" /Y.Dadurch werden c:\common\WebUtil\ und c:\common\HtmlParser erstellt.Fügen Sie in WebUtil einen Verweis auf c:\common\HtmlParser\HtmlParser.dll hinzu.Es gibt jetzt zwei Kopien von HtmlParser.dll in c:\common.

c:\common\HtmlParser\HtmlParser.dll // der neueste Build.c:\common\WebUtil\HtmlParser // was War der letzte Build, als WebUtil erstellt wurde

Das hat allerhand Vorteile.Wenn Sie die API von HtmlParser ändern, funktioniert WebUtil weiterhin, da es über die ältere HtmlParser.dll verfügt, bis Sie versuchen, WebUtil neu zu erstellen (an diesem Punkt erhalten Sie aufgrund der geänderten API Buildfehler).

Wenn nun ein drittes Projekt in den Mix aufgenommen wurde, das von WebUtil abhängt, und Sie einen Teil von WebUtil verwenden, der Klassen in HtmlParser verfügbar macht, müssen Sie einen Verweis darauf hinzufügen beide Projekte aus Ihrem neuen Projekt.Wenn Sie einen Verweis auf HtmlParser.dll hinzufügen, verwenden Sie den Verweis in c:\common\WebUtil.Sie tun dies, weil Sie es nur als notwendige Anforderung von WebUtil einbeziehen.Jetzt verfügen Sie immer über die Version von HtmlParser.dll, die Ihrer aktuellen Version von WebUtil.dll entspricht.

Ich hoffe das ergibt Sinn.Es kann definitiv schwierig sein, damit umzugehen.Warten Sie einfach, bis Sie alle Ihre Abhängigkeiten mit svn:externals =P herunterziehen müssen