JLI Spieleprogrammierung

[AFE-GmdG]

Ich hab auch mal wieder eine Frage zu einem Problem.

Ich muss für eine Plugintechnik mittels DotNetAssemblies einen Weg finden, einzelne Assemblies (Plugins) zu laden und vorallem wieder zu entladen.
Entladen kann man eine Assembly aber nur, wenn sie sich in einer eigenen ApplicationDomain befindet.
Ich suche nun einen Weg, wie ich eine Assembly zum Zwecke der Reflektion in eine Info-AppDomain laden kann, um zu ermitteln, ob es sich bei der Datei wirklich um ein Plugin handelt (Die Dll muss eine öffentliche Klasse besitzen, die von einer speziellen Schnittstele erbt)
Erschwerend kommt hinzu, dass nicht jede Dll auch eine Assembly ist, geschweige denn ein Plugin.

Der Sinnvollste Weg schien mir bis jetzt per

[Fallen]

Ohne sie zu laden wird das wohl nur über den globalen Assembly Cache gehen.

Es gibt ja eine ganze Menge msdn Artikel über StrongNames und deren Verwendung/Erstellung, das was am nächsten dem ähnelt was du suchst war dabei das hier: http://msdn2.microsoft.com/en-us/library/yx7xezcf.aspx

Zumindest habe ich nur wenig Vergleichbares gefunden.

Wegen dem Entladen der Assemblies bietet da die Assembly Klasse nichts brauchbares?

http://msdn2.microsoft.com/en-us/library/system.reflection.assembly.aspx

Die anzahl Referencen auf das Objekt auf 0 verringern sollte die Assembly dabei doch theoretisch entladen.
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[AFE-GmdG]

Eine einzelne Assembly kann man aus einer AppDomain nicht wieder entladen. Man kann aber, für den Fall, dass kein Verweis mehr auf irgend einen Typ in irgend einer Assembly innerhalb einer AppDomain die gesamte Domain mit AppDomain.Unload() entladen und damit auch die darin enthaltenen Assemblies.

Ich möchte quasi einmal eine AppDomain erstellen, in die ich alle Assemblies mit "ReflectionOnly" lade. Dort schaue ich nach, ob es sich dann um eine gültige PluginAssembly handelt, erstelle eine Liste der gültigen Plugins und entferne die AppDomain aus dem Speicher.
Danach erstelle ich für jedes zu ladene Plugin eine eigene AppDomain und lade die Assembly in diese.

Über die Pluginschnittstelle kann ich dann das Beenden des Plugins veranlassen, woraufhin ich die AppDomain bei bedarf entladen kann.

Einziger Hindernisgrund den diese Aktion im Moment verhindert, ist der StrongName, den ich für das Laden der Assembly benötige.
Ich konnte bisher - wenn ich den StrongName Hardcodiert in den Quellcode eingebe alles erreichen - nur ist es dann kein "Plugin" mehr - wenn ich zur Compilezeit die Namen aller "Plugins" kennen müsste...

Ohne AppDomain könnte ich die Plugins laden, indem ich die statische Assembly.LoadFrom()-Methode nutze. Nur kann ich diese Assemblies dann nicht wieder entladen und ich mülle mir die HauptAppDomain zu. (Man kann durchaus mehrere Versionen ein und derselben Assembly in eine AppDomain laden)
Ziel der ganzen Aktion ist es jedoch, einem Serverähnlichem Programm zur Laufzeit neue Funktionalitäten hinzuzufügen, ohne dass dieses Programm neu starten müsste. Werden die Teile nicht mehr benötigt, sollen sie automatisch entladen werden. Ich will also Plugins entwickeln und im Hauptprogramm testen / benutzen, ohne jedes mal dieses neu zu starten.

PS.: In einem ReflectionOnly-Kontext können Assemblies nicht ausfegührt werden, aber Typinformationen können gesammelt werden. Damit kann ich Plugins erkennen
_________________

[AFE-GmdG]

Falls es jemanden interessiert, ich habe das Problem gelöst:

Man muss sich zuerst eine Application Domain erstellen und darin eine Funktion aus der akteullen Domain aufrufen. Damit werden die notwendigen Assemblies der aktuellen Domain in die neue AppDomain geladen (z.B. mscore) und diese Funktion läuft dann in der neuen AppDomain. Diese ist im Übrigen dann eine eigene Sandbox, was ein sicherheitsrelevanter Aspekt ist. Das bedeutet jedoch auch, dass die Kommunikation zwischen einzelnen AppDomains nur über DotNetRemoting möglich ist...
Zurück zur Funktion in der neuen AppDomain: Sie ist dafür verantwortlich, die eigendlich zu ladene DLL einzubinden. Dabei testet sie nach einem (möglicherweise) erfolgreichen Laden der DLL selbst alle öffentlichen Klassen, ob sie von einem bestimmten Interface abgeleitet sind (per Reflection). Ist dies der Fall, kann man davon ausgehen, dass es sich um ein korrektes Plugin handelt. Anderen Falls beendet sich die Funktion mit einem negativen Rückgabewert und die HauptAppDomain entlädt die neue AppDomain und schmeisst damit die geladenen Assemblies damit wieder aus dem Speicher.
War alles OK, instanziiert man mit dem InterfaceTyp eine Instanz des abgeleiteten Types und arbeitet mit dem Interface ganz normal (so normal wie Remoting eben zulässt) weiter.

Wenn es Bedarf gibt, AppDomains, Plugins und DotNetRemoting genauer zu erklären, entweder per PM an mich oder ich muss mir mal die Mühe machen, ein bis zwei Tutorials zu schreiben.
_________________

[AFE-GmdG]

Da bereits mehrere Anfragen gekommen sind werde ich mich zw. Weihnachten und Silvester hinsetzen und ein Tutoril schreiben - eventuell auch mehrere nach Themen sortiert.

MFG AFE-GmdG
_________________

[Hazel]

Wäre toll... jetzt da XNA 1.0 ist wollte ich mich eh mal dran machen, ein neues Werkzeug zu lernen. ::)
_________________
*click* Dabuu!?
Twitter: http://twitter.com/Ollie_R