Referenz VB.NET-Schnittstelle in verschiedenen Assembly ohne neu zu kompilieren?

Question

Ich wurde gebeten, mit einem Produkt zu helfen, das in VB.NET geschriebene DLLs enthält. Die ausführbaren Dateien der Kunden verweisen auf diese DLLs. Abstrahieren die Situation:

HINTERGRUND:

Version 1 von Produkt LocationProduct enthält Location1.dll, die Schnittstelle ICounty im Namensraum Country.Province enthält. Kunden kompilierten ihre ausführbaren Dateien mit Verweisen auf Location1.dll.

Namespace Country.Province 

    Public Interface ICounty 
     Property District As String 
    End Interface 

End Namespace 

Version 2 von LocationProduct enthält Location2.dll zusätzlich zu Location1.dll. Die Schnittstelle ICounty wurde von Location1.dll zu Location2.dll mit der Schnittstelle und seinem Namespace unverändert verschoben. Neue Kunden verwendeten Version 2 von LocationProduct und kompilierten ihre ausführbaren Dateien mit Verweisen auf Location1.dll und Location2.dll.

PROBLEM:

Ein Kunde, dessen ausführbare Datei referenziert Version 1 von LocationProduct versuchte Version 2. Der Kunde erhielt eine Ausnahme zu aktualisieren, „Typ konnte nicht geladen werden‚Country.Province.ICounty‘aus Assembly‚Location1 .. . "

Wenn die Schnittstelle ICounty von Location2.dll zu Location1.dll zurück verschoben wird, erhalten ausführbare Dateien, die mit Version 2 kompiliert werden, eine ähnliche Ausnahme: "Der Typ 'Country.Province.ICounty' konnte nicht von Assembly 'Location2 ..." geladen werden. .

Gibt es eine Möglichkeit, LocationProduct zu ändern, sodass kein Kunde neu kompilieren muss?

Answer 1

Sie müssen zuerst verstehen, was hier vor sich geht.

Wenn Ihr Kunde die ausführbare Datei mit Version 1 kompiliert, bedeutet dies, dass er erwartet, dass sich die Schnittstelle in Location1.dll befindet.

Wenn Sie dies ändern, haben Sie eine Kompatibilitätsverletzung und müssen daher neu kompilieren. Fertig, das ist es, um meinen Freund herum..

Allerdings haben Sie möglicherweise eine Option: Verwenden Sie die ObsoleteAttribute (see MSDN link), dies wird eine Warnung in der IDE Ihres Kunden erstellen und sie werden sehen, dass sie diese Schnittstelle nicht mehr verwenden sollen. Aber sie müssen noch neu kompilieren.

Das gesagt wird, gibt es die ultimative Frage: Warum in aller Welt möchten Sie das tun?

Sie haben eine Bibliothek, die für Ihre Kunden freigegeben wird, Sie bewegen nicht Dinge herum. Wenn Sie ein öffentliches Framework entwerfen, sollten Sie nur Dinge hinzufügen, nicht ändern oder entfernen, da Ihr Kunde jedes Mal neu kompilieren muss, wenn Sie ein Kompatibilitätsproblem einführen.

Hier ist ein Link zu MSDN Framework Design Guidelines, der erläutert, wie Sie eine Bibliothek (oder ein Framework) entwerfen sollten.