Visual Studio Referenzen und Versionierung - wie funktioniert es?

Question

Wir haben mehrere gemeinsame Bibliotheken. Im Idealfall wollen wir sie alle die neueste Version einer DLL verwenden, auch wenn sie gegen eine ältere andere Version kompiliert wurden (nehmen die neueste Version ist abwärtskompatibel)

zB haben wir:

Projekt dll
Gemeinsame Kontrollen dll
Logging dll
Datenbank Zugang dll

Projekt und gemeinsame Kontrollen v2 von Datenbank-dLL verweisen. Logging jedoch Referenzen v1.

Wenn verschiedene Versionen in verschiedenen Komponenten referenziert werden, wie wählt VS welche?
Müssen wir die V1-DLL neu kompilieren, um die neueste Datenbank (v2) zu verwenden, oder können wir das automatisch abholen lassen?
Kann eine bestimmte Version erzwungen werden?

Danke,

Alex

Answer 1

standardmäßig für versioniert DLLs glaube ich VS eine genaue Übereinstimmung zwingen wird. Wenn Sie in den Eigenschaften der Referenz nachsehen, finden Sie jedoch eine Eigenschaft namens "Spezifische Version". Setze das auf "false" und es wird mit späteren Versionen übereinstimmen.

Ich habe leider nicht die Vollversion von VS, um einen passenden MSDN-Link zu finden.

Darüber hinaus können Sie das Element assemblyBinding in app.config verwenden.

Answer 2

Wenn Sie die Quelle haben, könnten Sie Projektreferenzen anstelle von DLL-Referenzen verwenden. So würden Sie immer das Neueste bekommen.

Answer 3

ich auf diese Seite gekommen, die ein paar Vorschläge hat: http://blog.fredrikhaglund.se/blog/2008/02/23/get-control-over-your-assembly-dependencies/

Um anscheinend eine bestimmte Version erhalten Sie web.config bearbeiten oder app.config?

"Betrachten Sie schließlich Ihre csproj-Datei mit Notepad (oder entladen Sie das Projekt in Visual Studio, um es als Text zu öffnen). Wenn Sie Referenzen mit Visual Studio hinzufügen, erhalten Sie eine Assembly-Referenz mit beiden Versionen Nummer und öffentlicher Schlüssel. Dies kann zu Problemen führen, wenn Sie eine Hersteller-Assembly auf eine neuere Version aktualisieren. "
http://blog.fredrikhaglund.se/blog/2008/02/23/get-control-over-your-assembly-dependencies/

Answer 4

Es gibt zwei Szenarien - starke Namen/GAC oder keine starken Namen.

Wenn Sie starke Namen verwenden und die Komponenten im GAC installieren, wird .NET die Version der Komponente verwenden, auf die der Client bei der Kompilierung verwiesen hat. In Ihrem Beispiel wäre es also durchaus möglich, dass Project die Datenbank V2 referenziert, während die referenzierte Datenbank V1 protokolliert, da die DLLs parallel im GAC gespeichert werden können. Wenn Sie also wollen, dass Logging V2 anstelle von V1 verwendet, müssen Sie die Konfigurationsdateien so ändern, dass "ein Verweis auf V1 auf V2 verweist". Es gibt verschiedene Orte, um dies zu tun - App-Datei, Maschinendatei usw.

Wenn Sie keine starken Namen verwenden, dann.Net verwendet standardmäßig die Version der DLL, die sich im selben Ordner wie der Client befindet. Angenommen, Sie stellen Project, CommonControls und Logging im selben Ordner wie die Datenbank V2 bereit. Selbst wenn Logging für die Datenbank V1 erstellt wurde, wird versucht, die Komponente im selben Ordner zu verwenden, dh in der Datenbank V2. Solange V2 die gleichen öffentlichen Klassen und Methoden bereitstellen kann, die Logging verwenden möchte, wird es funktionieren.

In meiner Umgebung - wo alle unsere Anwendungen intern sind - verwenden wir nicht den GAC. Wir stellen einfach alle Dateien bereit, die die Anwendung in einem einzigen Ordner benötigt. Wenn Sie viele gemeinsame Komponenten haben, wäre es nur ein Alptraum, die Konfigurationsdateien synchron zu halten.

Das ist alles ganz anders als bei COM, wo alle Anwendungen die aktuell registrierte Kopie der DLL aufnahmen (vorausgesetzt V1 und V2 waren binärkompatibel).