Hi!

Wies schon im Titel steht will ich meine Anwendung Plugin (z.B. wie bei Office) und Updatefähig machen. Mit Updatefähig meine ich dass man das Update irgendwie extern ausführt, es soll also nicht die .exe ausgetauscht werden. Kennt da jemand vielleicht ein Tutorial dazu

Das mit den Updates ist ihmo am besten lösbar, wenn du deinen Code zum Großteil in Klassenbibliotheken implementierst, dann kannst du diese einfach austauschen, wenn du etwas an ihnen geändert hast. In manchen Fällen musst aber, z.B., wenn du neue Funktionen einbaust, die vom Hauptprog aufgerufen werden sollen, die .exe austauschen, so, wie ich das sehe. Tipps zu einem Prototypischen Plugin-System findest du Hier.

Grüße, Paul

Gut, danke, das mit dem Update hab ich glaub ich kapiert. Aber noch zwei Fragen dazu:
1. Kann ich meine erstellten Forms einfach in die entsprechenden Libarys Kopieren, den Verweis hinzufügen, nen paar Codeänderungen machen und gut? Und was für eine Libary soll ich dafür nehmen? Windwos Forms Control Libary?

2. Wie kann ich dafür sorgen dass nur ich die dll verwenden kann? Oder muss ich das überhaupt? Wäre glaub ich ziemlich blöd wenn jeder einfach meine dlls verwenden kann oder?


Und zu den Plugins: So ganz verstanden hab ich das nicht. Soweit ich das interpretieren kann muss ich aus der dll für das Plugin ein Assembly erzeugen, und dann noch irgendwas mit machen. Könntest du mir vielleicht erklären was hinter dem Code steckt?

Naja,

ich würde dafür einfach eine ganz Normale Klassenbibliothek (Class Library) verwenden. Im Grunde müsstest du die Forms kopieren können, gib aber drauf acht, dass du u.U. noch den Namensraum anpasst. Dann kannst du die Dll referenzieren und das Formular nutzen. Wenn
du jetzt das Formular änderst, kannst du, sofern du von deinem Hauptformular immer noch die selben Methoden mit den selben Parametern und denselben Rückgabetypen aufrufst, einfach die Neue dll in den Ordner der .exe kopieren und das neue Form nutzen. Müsste zumindest so gehen
Ich weiss nicht, worum es in deinem Programm geht, aber ich vermute mal nicht, dass du das ganze unbedingt so geheim halten musst, dass die Leute deine dlls nicht verweden. In den meisten Fällen werden diese eh auf deine Bedürfnisse zugeschnitten sein und den anderen Leuten vermutlich nichts bringen. Wenn du sicher gehen willst, dann gibt es Möglichkeiten, deinen Code zu schützen (z.B. Obfuscatoren).

Das mit den Plugins läuft so:
1) Du schreibst dir ein Interface, dass die Methoden der Plugins deklariert, also wenn du zum Beispiel ein Fenster anzeigen lassen willst, kannst du im Interface eine Methode Show() deklarieren. Plugins verwenden dann dieses Interface und müssen eben diese Show()-Methode implementieren. Die Plugins werden in dlls gespeichert. Um während der Laufzeit diese dlls einzubinden, musst du ein Objekt der Klasse Assemby erzeugen (Namensraum ist System.Reflection) und mit Assembly.LoadFile("meinplugin.dll"); die dll laden. Angenommen, das Objekt heisst meinedll, dann kannst du mit meinedll.GetTypes() die Typen (Klassen) bekommen, die in der dll enthalten sind. Ich hab das dann so gemacht, dass ich versucht habe, die enthaltenen Typen zu meinem Interface zu casten und wenn das ging, dann war das halt ein gültiges Plugin. Wie du an de Dateinamen kommst und wie genau du deine Plugins aufbaust ist natürlich dir überlassen.

Hoffe, ich konnte dir weiterhelfen. Wenn du noch fragen hast, kannste mich auch gerne per pm anschreiben

Hi

Was spricht dagegen, die Exe oder DLL auszutauschen?
Alles anderes ist Aufwand, der nie vom Nutzen gedeckt wird.
Schau dir dafür mal ClickOnce an. Das biete auch Update-Funktionalitäten, auf Wunsch vollautomatisch.

Bzgl. Plug-in
Hier musst du dir überlegen, welche Objekte in Plug-In zur Verfügung gestellt werden sollen, um das Plug-In auch nutzen zu können.
Hier für musst du dir eine saubere Schnittstelle überlegen.
Denk dann aber auch daran, dass diese Schnittstelle von anderen genutzt wird. Soll heißen, dass du nicht einfach Methoden entfernen oder Parameterlisten ändern kannst. Einmal veröffentlicht müssen diese immer weiter unterstützt werden.

Also das mit den Updates per dll macht bei mir sinn, da ich zwei Hauptfenster habe, die durch eine globale Klasse miteinander verbunden sind. Wenn ich also ein Update durchführen will, brauche ich nicht immer die ganze Anwendung auszutauschen, sondern eben Teile davon. Wenn ich aber nur eine .exe hab, dann muss ich die ja bei jedem Update austauschen, und das macht bei kostenpflichtigen Anwendungen wohl eher wenig sinn, wenn ich mit ein bisschen mehr aufwand auch so Updaten kann.

Das mit den Plugins werd ich demnächst mal ausprobieren, wenns nicht geklappt hat hört ihr nochmal was von mit

Also ein Problem hab ich noch. Ich habe die Plugins in einen Plugin Ordner verschoben. Jetzt habe ich Probiert, ein Plugin zu ersetzen. Allerdings scheint dies nicht zu funktionieren, ich bekomme immer eine IOException, auch wenn die dll nicht geladen wurde. Gibt es vielleicht noch andere Updatemöglichkeiten ausßer die von System.IO?

Wo hat der Namespace System.IO Updatemöglichkeiten?
Was sagt denn die IOException aus? gibt's eine InnerException?
Bist du dir sicher, dass die DLL nicht geladen ist?
Wie versuchst du denn das PlugIn zu ersetzen?

Ich ersetze die dll mit File.Replace, das ist ja im entferntem Sinne ein update
Ja, ich bin sicher dass die dll nicht geladen wurde, weil ich in einem Form meine dlls importieren kann, und in einem anderen werden sie verwendet. Und ich habe die dlls erst in dem Form dass die dlls verwenden soll geladen. Die Message der Exception war "Die Datei kann nicht ersetzt werden da sie bereits von einem anderen Programm geöffnet ist" oder so. Gibt es vielleicht einfache Updatemöglichkeiten, die mir einfach eine dll durch eine andere ersetzen können?

dann ist die DLL wohl doch geladen. Oder ein anderes Programm greift darauf zu
Entweder in deiner Anwendung mal die geladenen Assemblies ausgeben und/oder mit Filemon überprüfen, wer diese Datei verwendet.

Also grundsätzlich sollte es folgender Aufbau sein:

• UI
• Library
• Extension

Grundsätzlich sollte die Library soweit alle Möglichkeiten bieten, damit sie nicht mehr verändert werden muss und die Extensions darauf aufsetzen können. Ist eine Änderung notwendig, dann wäre das ohnehin ein Anwendungs-Update.

Was die Extensions/Plugins betrifft. Diese würde ich in einer eigenen Application Domain laden (über einen Remote Proxy). Dies hat den Vorteil, dass das Plugin auch wieder entladen werden kann und somit einem Update nichts mehr im Wege steht.

Wie funktioniert das genau? Bis jetzt habe ich die Plugins immer ein eiene ArrayList geladen, und ich hab mal gegooglelt, und weiß was eine Applicaton Domain ist, aber ich hab keine Ahnung wie ich das verwirklichen soll.

Schau mal hier:
http://www.devsource.com/article2/0,1759,1790388,00.asp

Also mittlerweile hab ich das schon ziemlich gut drin, aber ich hab noch ein paar Probleme mit dem AppDomain:
1. Ich will in mein AppDomain ein Assembly laden, ohne dabei gleich eine Instanz von irgendeiner Klasse erzeugen zu müssen. Ich habs mit AppDomain.ExecuteAssembly() versucht, aber ohne erfolg. Kann es sein, dass ExecuteAssembly() dafür da ist, ein Assembly wie eine *.exe laufen zu lassen?
2. Was mich noch an der AppDomain.CreateInstanceAndUnwrap() stört, ist dass ich dabei die Instanz gleich erzeugen muss, aber ich würde lieber die Typen aus dem Assembly wie mit Assembly.GetTypes() auslesen, um später etwas erzeugen zu können.
Und 3. möchte ich noch System.Windows.Forms einbinden. Ich habs mit

Code csharp:

1	AppDomain.CreateInstanceAndUnwrap("System.Windows.Forms")

versucht, allerdings ohne Erfolg. Wie kann ich das bewerkstelligen?