Deserialisierung; Klasse der Laufzeitumgebung bekannt machen

[Hans-Peter Tschan]

Hallo,

eine Applikation lädt dynamisch über Assembly.LoadFile() ein Assembly und übergibt dem Assembly einen Pfad (string) wo das Assembly seine Daten speichern soll.

Im Assembly selbst ist ein Konfigurationsdialog implementiert, der im Assembly enthaltende Klassen serialisieren kann und auch wieder deserialisieren können sollte: Hier liegt das Problem. Beim deserialisieren wird eine Exception "Assembly xxx Version... kann nicht gefunden werden"

Das (angeblich) nicht vorhandene Assembly löst aber die Exception aus :-)

Höchstwahrscheinlich, liegt es am dynamischen Laden - denn, wenn das (De)serialisieren im Kontext ist getestet.

Kann mir jemand weiterhelfen?

Vielen Dank
Hans-Peter Tschan

[Hans-Peter Tschan]

Inzwischen bin ich ein klein wenig weiter: Wenn die DLL (Assembly) sich im selben Verzeichnis befindet wie das Hauptprogramm (.exe) und dort der Pfad von Assembly.LoadFile() entsprechend angepasst wird, dann funzt's...Dieselbe(!) DLL in einem anderen Verzeichnis ("Ladepfad" angepasst) und das deserialisieren klappt nicht..

[Andreas Kosch]

Hallo,

immer dann, wenn derartige Ladefehler kommen, würde ich den <i>Assembly Binding Log Viewer</i> (FUSLOGVW.EXE) auf die Lauer legen, um mir dann den konkreten Suchverlauf nach der Assembly anzeigen zu lassen.

Wenn die Assembly nicht im Programmverzeichnis und auch nicht im GAC abgelegt werden soll, ist es normalerweise üblich, dies über den <b>probing privatePath</b>-Eintrag in der App.config anzumelden, damit der Assembly Resolver die Datei auch finden kann

[Hans-Peter Tschan]

Hallo Andreas,

ein Ladefehler scheint es nicht zu sein; die Assembly wird ja geladen (das in der Assembly vorhandene Dialogfenster wird instanziiert und angezeigt), im Assembly Binding Log Viewer erscheint kein Eintrag...Auch das Serialisieren klappt - nur, das Deserialisieren schlägt fehl, wenn die Assembly nicht im selben Verzeichnis steht wie die .exe

Viele Grüße, Hans-Pete