Auflösen/Verwenden mehrerer Assemblyversionen aus Abhängigkeiten von Drittanbietern

Question

In meinem Projekt habe ich ein Problem mit der Abhängigkeitshierarchie. Ich verwende eine Bibliothek (WriteableBitmapExtensions) in meinem Code, und ich habe eine andere Drittanbieter-Bibliothek, die auch WriteableBitmapExtensions verwendet. Nur die andere Bibliothek ist stark an eine bestimmte ältere Version gebunden und mein Code benötigt die Funktionalität in seiner neuesten Version.

Hier ist eine Darstellung der Abhängigkeiten:

Es gibt ähnliche Fragen & Lösungen, aber sie lösen es mit Montage zur Laufzeit über eine Konfigurationsdatei zu binden, aber ich glaube nicht, dies für eine Silverlight-Anwendung kompatibel ist.

Referencing 2 different versions of log4net in the same solution

Using different versions of the same assembly in the same folder

3rd party libraries refer to different versions of log4net.dll

How to deal with multiple versions of dependencies?

es ist also eine Möglichkeit, diese verschiedenen Versionen von Montag Abhängigkeiten in einem Silverlight-Kontext zu lösen? Wenn nicht, sehe ich meine Optionen sind:

1) Am wahrscheinlichsten kann ich den Hersteller der 3rd-Party-Bibliothek zu aktualisieren, um die neueste Version von WriteableBitmapExtensions zu verwenden, aber ich würde lieber nicht abhängig sein sie halten es auf dem neuesten Stand. Zumal das WriteableBitmapExtensions-Projekt noch immer aktualisiert wird und wir oft die Vorteile der neuen Funktionen nutzen.

2) Da WriteableBitmapExtensions open-source ist, nehme ich an, ich kann seine Quelle als eine neue Assembly "MyWriteableBitmapExtensions" neu kompilieren und diese in meinem Quellcode verwenden. Aber ich werde dieses Problem erneut auftreten, wenn zwei Bibliotheken von Drittanbietern auf verschiedene Versionen von WriteableBitmapExtensions verweisen.

Ich vermute, ich werde mit Option 2 gehen, aber ich würde gerne wissen, ob es eine bessere Möglichkeit gibt, dies zu tun (wie die Laufzeit Assembly in den anderen Fragen binden), bevor ich/Refactor. Vielen Dank!

Answer 1

Wie ich in meinem Kommentar gesagt habe, sollte Option 1 leicht verfügbar sein, weil "v1" eigentlich eine "Pre Beta" Version ist.

Wenn es eine Verzögerung beim Drittanbieter gibt, der einen Build mit einer Nicht-Beta-Version veröffentlicht, ist Ihre Option 2 Ihre nächste Option. Stellen Sie sicher, dass Sie eine vollständig neue Identität für Ihr Build von MyWriteableBitmapExtensions verwenden: Verwenden Sie speziell einen anderen AssemblyName, FileName, Strong Name Signature und alle GUIDs, die für die Identität verwendet werden, auch für COM.

Wenn Sie nicht die neue Funktionalität benötigen haben oder wenn die v2 war rückwärtskompatibel mit v1, Montag Bindung noch die bevorzugte Option wäre - ich nicht bestätigt haben, wenn dies mit Silverlight verfügbar ist, aber ich würde Seien Sie überrascht, wenn es nicht war, obwohl ich jetzt stimme, True Assembly Binding ist wahrscheinlich in Silverlight nicht verfügbar, da der gesamte System.Configuration-Namespace in Silverlight fehlt (mit Ausnahme von zwei Enumerationen in System.Configuration.Assemblies).

Dennoch eine weitere Option ist die neueste Quellcode so einzustellen, dass es tut produzieren etwas, das zu v1 rückwärtskompatibel ist, vielleicht die v2 Features zu brechen, wenn Sie zu haben - so die Merkmale v2 können noch verwendet werden, nur mit einer Neukompilierung, jetzt mit die ursprüngliche Identität (AssemblyName, FileName, Strong Name Signatur, etc.).Dann sollten Sie die eine Assembly für beide Szenarien erneut verwenden können.