Version einer DLL

08/10/2009 - 10:59 von Jürgen Ewen | Report spam
Hallo zusammen,

ich habe hier ein Problem an dem ich mir zur Zeit die Zàhne ausbeisse und
keine Lösung finde. Vielleicht weiß ja hier einer Rat. Folgender
Hintergrund:

Es gibt eine Rahmenanwendung (Class Library) in der Usercontrols,
Steuerelemente gekapselt sind, gemeinsam genutzte Klassen hinterlegt sind.
Diese besteht aus diversen Projekten, thematisch getrennt und somit
verschiedene DLL's. Unter anderem einen Dialogmanager der für alle
einheitlich Dialoge, z.B. Fehlermeldungen, Validierungsmeldungen etc.
ausgibt. Dies ist eine statische Klasse und hàngt sich auch als globaler
Errorhandler ein, sobald von der Hauptanwendung angesprochen.

In dieser Rahmenanwendung habe ich auch einen Pluginloader integriert.
Zustàndig zum Verwalten und laden von Plugins, die sich dann in eine
Hauptanwendung nachladen lassen.

So, ein Plugin welches erstellt wird, nutzt auch Klassen aus dieser
Rahmenanwendung. Die Referenzen darauf sind aber wie folgt eingestellt:

Copy Local: false
Specific Version: false

Die DLL's der Rahmenanwendung werden also nicht in das bin Verzeichnis
kopiert und die Version soll egal sein. Man geht also davon aus, dass die
Hauptanwendung, die dieses Plugin làdt, die DLL's mitinstalliert hat. Ich
will ja auch nicht immer das Plugin neu kompilieren, wenn sich die
Hauptanwendung àndert!!

Funktioniert auch super! Bis auf eine Klasse, nàmlich der Dialogmanager.

Propblem: Die Rahmenanwendung hat jetzt Version 2.1.4, damit ist auch das
Plugin kompiliert worden, aber mit Einstellungen wie oben gezeigt! Jetzt
wird die Rahmenanwendung weiterentwickelt, erhàlt eine höhere
Versionsnummer. Die Hauptanwendung wird neu kompiliert und bindet diese
Rahmenanwendung ein. DLL's stehen nach Installation komplett zur Verfügung!

Kein Problem, das Plugin làsst sich laden, bei allen verwendeten Klassen der
Rahmenanwendung kommt keine Fehlermeldung! Aber sobald der Dialogmanager
angesprochen wird, kommt die Fehlermmeldung dass die XXX.DLL, Version 2.1.4
nicht gefunden wird!

Was soll das? Wo wird diese blöde Versionsnummer im Plugin noch eingetragen!
Was soll die Einstellung Specific Version = false, wenn es offensichtlich
ignoriert wird! Am DialogManager hat sich nichts geàndert! Nur die
Versionsnummer! Aber er làdt jetzt nicht einfach die DLL die im
bin-Verzeichnis vorliegt, sondern die Plugin.dll will genau die, die beim
Erstellen der Library referenziert war!

Ist die Version gleich, kein Problem, das Plugin nutzt die DialogManager
Assembly die von der Hauptanwendung bereits geladen und initialisiert wurde!

Eine Idee?

Danke.

Gruß Jürgen
 

Lesen sie die antworten

#1 Günter Prossliner
08/10/2009 - 12:32 | Warnen spam
Hallo Jürgen!

Kein Problem, das Plugin làsst sich laden, bei allen verwendeten
Klassen der Rahmenanwendung kommt keine Fehlermeldung! Aber sobald
der Dialogmanager angesprochen wird, kommt die Fehlermmeldung dass
die XXX.DLL, Version 2.1.4 nicht gefunden wird!



Die .NET Runtime versucht eine Referenz erst zu laden sobald diese auf
wirklich benötigt wird. Aus diesem Grund kannst Du das Plug-In Assembly auch
laden und dort Code ausführen. Der Fehler tritt erst auf wenn das Plug-In
das Assembly der "Rahmenanwendung" zugegriffen wird. Und dort ist eben das
z.B. Assembly "Rahmenanwendung, Version=1.1" und nicht "Rahmenanwendung,
Version=1.0" geladen.

Was soll das? Wo wird diese blöde Versionsnummer im Plugin noch
eingetragen!



Eintragen gar nicht. Das ist einfach die Referenz.

Was soll die Einstellung Specific Version = false, wenn
es offensichtlich ignoriert wird!



"Specific Version" ist nur ein VS Setting, was im Endeffekt bedeutet, dass
der *Compiler* auch eine andere (z.b. eine neuere Version des Assemblies)
akzeptiert. Für die Laufzeit hat das keinen Einfluss.

Am DialogManager hat sich nichts geàndert! Nur die Versionsnummer!



Wo sich was geàndert hat ist irrelevant. Selbst wenn Du nur die
Versionsnummer, und gar nichts am Code ànderst ist es aus Sicht von .NET ein
anderes Assembly (falls Strong-Name, dazu aber spàter).


Lösungen:

Am besten: Ändere die Versionsnummer nur dann wenn Du neue Major-Releases
und z.b. durch inkompatible Änderungen ohnehin eine Neukompilierung der
Add-Ins erfolderlich wàre. Für "informative Zwecke" wie z.b. die Anzeige der
Versionsnummer im Explorer bzw. Setup und Update Routinen kannst Du die
"AssemblyFileVersion" verwenden.

vgl.:

[Suzanne Cook's .NET CLR Notes : When to Change File/Assembly Versions]
http://blogs.msdn.com/suzcook/archi...57148.aspx

[How to use Assembly Version and Assembly File Version]
http://support.microsoft.com/kb/556041


Weiters wàre es möglich keine strong-names zu verwenden, denn dann wird ist
die Versionsnummer vom Loader ignoriert.


Generell solltest Du das "Interface-Assembly" - also jenes welches von den
Plug-Ins referenziert werden muss - so "schlank" wie möglich halten und
maximale Kompatiblitàt zu gewàhrleisten. Dort sollten also nur jene Typen
definiert sein welche auch tatsàchlich von den Plug-Ins benötigt werden. Das
heisst *nicht*, dass dort nur Interfaces drinnen sein müssen. Abstrakte
Klassen sind hinsichtlich Kompatibilitàt sehr oft besser als Interfaces
(welche ja unverànderbar sind, wàrend abstrakte Klassen z.b. um virtuelle
Members erweitert werden können), wobei das eine andere Geschichte ist (vgl.
{1}).

Wenn Du also z.b. eine Änderung im Code der "Rahmenanwendung" machst (z.b.
neues Menü, Layout, neue Funktionen, ...) sollte das eine erneute
Kompilieren der "Plug-In Interface" Dll *nicht* erforderlich machen.

Ein Negativbeispiel ist hier z.B. der "DOTNET Reflector" (ein *super*
Tool!). Dort muss (bzw. musst - eventuell wurde das geàndert) von Plug-Ins
direkt auf die Reflector.exe referenziert werden d.h. dass ein Plug-Ins idR
nur mit einer Version funktioniert.


{1}
[.NET Type Design Guidelines—Choosing Between Class and Interface at C#
Online.NET (CSharp-Online.NET)]
http://en.csharp-online.net/.NET_Ty..._Interface



OK?
mfg GP

Ähnliche fragen