Chris
At 09:17 PM 11/9/2004, you wrote:
Hi Christoph,
danke f�r den Hinweis, leider habe ich aber immer noch keine L�sung... Hast Du evtl. ein Beispiel oder noch eine Idee? Ich habe noch einige Forschungen angestellt und wei� inzwischen, da� Assembly.LoadFile die zu ladende Assembly in die ausf�hrende AppDomain l�dt. Zur L�sung erzeugt man sich wohl eine neue Appdomain, setzt die Basispfade �ber das AppdomainSetup-Objekt auf den Plugin- und den Ausf�hrungsordner und erzeugt die Objekte der fremden Assembly in der neuen AppDomain. Leider wird daf�r intern wohl die Remoting-Infrastruktur hergenommen, und folgerichtig kommen dabei merkw�rdige "Klasse ist nicht als serialisierbar markiert"-Fehler. Bei meinen eigenen Klassen kann ich f�r [Serializable] sorgen, aber dar�berhinaus?
Gru�, Helge
Christoph Wille wrote:
Es gibt einen Weg den Assembly Locator Mechanismus zu �berschreiben.
Chris
At 08:07 AM 11/9/2004, you wrote:
ich habe ein Problem mit dem Laden von DLLs als Plugins, bzw. deren Abh�ngigkeiten. In einem definierten Unterordner meiner Anwendung liegen Plugin-DLLs nach einem bestimmten Namensschema, die ich zum Start per Assembly.LoadFile und, sofern erfolgreich, Activator.CreateInstance zum Einsatz bringe. Soweit, sogut, aber zwei von den Dingern haben externe Abh�ngigkeiten, und dort scheitert das Laden - der Plugin-Ordner wird nicht durchsucht. Lege ich die referenzierte Library aber in den Ausf�hrungsordner meines Ursprungsprogramms statt meines Plugins, funktioniert es (nat�rlich). Gibt es eine programmatische L�sung f�r dieses Problem (au�er GAC-registrieren...)?
_______________________________________________ CSharp.net Mailingliste, Postings senden an: [EMAIL PROTECTED] An-/Abmeldung und Suchfunktion unter: http://www.glengamoi.com/mailman/listinfo/csharp.net
