System.Reflection.Assembly.Load(@"C:\assemblyfile.dll");
|
|
|
"aber irgendwie klappt das bei mir nicht" - geht's ein bisschen genauer? Was klappt denn nicht? Gibt es eine Fehlermeldung? ...?
– Golo Roden 28.01.2011
|
|
|
|
|
|
Ehrlich gesagt halte ich die Variante mit den AppDomains für theoretisch zwar ganz cool, praktisch aber für total überladen. Wo liegt der Vorteil von gesonderten AppDomains?
Im Wesentlichen darin, ein Plugin wieder entladen zu können. Dafür handele ich mir deutlich mehr Aufwand ein für die Kommunikation, als wenn alles in einer AppDomain läuft. Ein reines Nachladen und Instanziieren per Interface, wie von mfe_ vorgeschlagen, finde ich wesentlich praktikabler. – Golo Roden 30.01.2011
|
||
|
Wir haben ein solches Plugin-System in einer Service-Orientierten Architektur bei uns auf Arbeit. Der wesentliche Vorteil ist, das Fehler in einem Plugin sich nicht auf den Dienst und somit auf alle anderen Plugins auswirken. Dh. stürzt ein Plugin ab, stürzt nur dieses ab (z.b. AccessViolationException oder OutOfMemoryException) und eben nicht der Service. Zweiter Vorteil ist, das man den einzelnen AppDomains unterschiedliche ADS-User, Umgebungsvariablen und Pfade zum nachladen von DLLs zuweisen kann.
– Floyd 30.01.2011
|
||
|
Der zusätzliche Aufwand hält sich stark in Grenzen. Im vergleich zu einer Lösung ohne AppDomain ist nur bei der Instanzierung mehr Aufwand erforderlich.
– Floyd 30.01.2011
|
||
|
Hallo, bitte den Link von http://www.wie-koche-ich.com/index-blog-1-14-89-C%23-Plugins-mit-AppDo.html auf http://get-the-solution.net/index-1-14-89-C%23-Plugins-mit-AppDo.html ändern. Danke
– mfe_ 12.04.2011
|
||
|
Bin deinem Wunsch gefolgt, aber was störte dich daran? Bei mir gehen beide Links und zeigen auf das selbe.
– Floyd 12.04.2011
|
||
|
Weil die Domain eigentlich einer anderen Seite zugeordnet ist. Bis jetzt ist es noch möglich über die "falsche" Domain zu zugreifen, aber der "Bug" wird bestimmt früher oder sp#äter behoben ;)
– mfe_ 13.04.2011
|
|
|
|
Warum sollte das nicht gehen? Wenn ich die passenden Funktionen ins Interface schreibe.
– Floyd 30.01.2011
|
||
| 1 |
Also das erstellen des UserControls in eine eigene AppDomain wird funktionieren aber das Problem dabei ist, dass du das UserControl nicht in die Hauptdomain bekommen wirst. An der Stelle wird dein Programm versuchen per Remote mit der anderen AppDomain zu kommunizieren, das wird fehlschlagen, da du per Remote nicht auf private Eigenschaften zugreifen kannst, was bei WinForms z.B. das "parent"-Objekt wäre.
– Konstantin 30.01.2011
|
|
|
Das mag sein, solange du von UserControls redest. Bei WinForms sieht das schon wieder anders aus.
– Floyd 30.01.2011
|
||
|
Ja gut das stimmt schon, aber wenn man Plugins entwickelt, wird es sich vermutlich um UserControls handeln :-)
– Konstantin 30.01.2011
|
||
|
Jein, jeder Codec für einen Video- oder Audio-Player ist im Prinzip ein Plugin. Genauso wie die ActiveX-Controls oder NAPI-Plugins für Browser. All diese erweitern ein Programm um zusätzliche Funktionen (z.B. neue Video-Formate) und benötigen keinerlei UI. Und wenn doch dann als WinForms.
– Floyd 30.01.2011
|