Erweiterungssystem realisieren

Hi.

Ich bin gerade dabei einen kleinen Webserver zu entwickeln. Nun möchte ich ein Erweiterungssystem realisieren welches die an den Client zu senden Daten vor dem verschicken nich verändern kann.

Wie ist dies zu realisieren?

Wenn möglich hätte ich es gerne, dass die Erweiterungen exe-Dateien sind (eigene GUI haben).

Ich habe mir es schon mit einem named pipe ausgedacht, aber da kann ja jeder der die Daten hat drauf zugreifen. Besser würde es mir gefallen, wenn der Server in einem bestimmten Verzeichnis sucht und jede enthaltene Datei aufruft.

Hallo burnersk,

das was du suchst nennt sich PLUGIN

ein Plugin ist normalerweise eine Dll datei und ja auch eine dll Datei kann eine Gui enthalten

such einfach mal hier im Forum nach Plugin

der rest wäre reine Implementation

mfg

Hi.

Ich habe mir mal Wie kann ich Plugins realisieren??? geschnappt. Blicke aber nicht ganz durch.

Folgendes ist für die Hauptanwendung (Server) gedacht:

/**
 * PlugIn Interface.
 *
 * @author	Sören Kornetzki <S.Kornetzki@dev5-media.de>
 * @copyright	© 2007-2008 dev5-media Gruppe, IT Dienstleistungen, Sören Kornetzki
 * @package	de.dev5-media.plugintest
 * @since	22.01.2008 13:05
 * @version	1.0
 * Erstellt mit SharpDevelop.
 */

using System;
using System.Collections;

namespace pluginTest.plugin
{
	/// <summary>
	/// Interface für PlugIns
	/// </summary>
	public interface IPlugIn
	{
		/// <summary>
		/// EventListener "readData".
		/// 
		/// Manipulationsmöglichkeit für Daten die an den Clienten geschickt werden sollen.
		/// </summary>
		/// <param name="sData">Original Daten des Servers</param>
		/// <returns>Vom PlugIn manipulierte Daten</returns>
		string readData(string sData);
		
		/// <summary>
		/// EventListener "readParameters".
		/// 
		/// Manipulationsmöglichkeit für GET/POST Parameter bevor der Server diese verarbeitet.
		/// </summary>
		/// <param name="alParameters">Original Daten des Servers</param>
		/// <returns>Vom PlugIn manipulierte Daten</returns>
		ArrayList readParameters(ArrayList alParameters);
	}
}

Wie muss ich dann das Plugin aufbauen? Jedes registrierte Plugin soll die Daten bekommen (linear). Also das erste Plugin bekommt die original Daten das zweite PlugIn die manipulierten Daten von Plugin 1

Hallo burnersk,

Im Prinzip brauchst du einen Plugin-Host, der aus einem Verzeichnis alle Plugins lädt.
Dann musst du sie nur noch in die gewünschte Reihenfolge bringen, innerhalb einer Liste z.B. oder mit einer Rule-Engine, oder sonstwie.
Wenn nun ein Request ankommt, kannst du dann ganz einfach über die Liste iterieren.
Die Schwierigkeit ist eigentlich nur die AppDomain-Geschichte (falls gewünscht und nötig) und die Plugin-Schnittstelle / -Interface.
Das Plugin-System steht und fällt mit einem gut durchdachten Interface!

Ich bin mal so dreist und verweise auf Generic Manipulator Tool .
Falls du Code möchtest von meiner Plugin-Architektur (im Thread vorgestellt), kannst du dich mal bei mir melden.

Mfg NeuroCoder

Hi.

Ich blicke leider nicht durch...
Ich hänge mal ein Testprojekt an. Vielleicht erklärt sich jemand bereit dieses Projekt zu bearbeiten. So kann ich es am Besten herleiten. hoff

"pluginTest.EventListener.sendDataClass.sendData" (bzw. readData) ist nur der Ausführpunkt.
Es soll noch weitere so genannte EventListener geben. Wenn möglich bitte den PlugIn-Host in "pluginTest.PlugInHost".

Hallo burnersk,

entschuldige wenn ich das jetzt einfach so sage, aber dein Projekt enthält ja nur ein Hauptprogramm.
Ich glaube nicht, dass sich jemand bereit erklärt und dir da ein vollständiges Plugin-System einbaut 😉.

Allerdings habe ich dir mal eine vereinfachte Version des Plugin-Systems aus besagtem Generic Manipulator in den Anhang gepackt.

Generell funktioniert die Sache dort so:
Der PluginManager überwacht ein Verzeichnis oder bekommt einen "Lade-Plugins"-Auftrag.
Für jede DLL im Plugin-Verzeichnis erstellt er ein ManagedPluginLibrary-Objekt. Dieses erstellt eine AppDomain für die Plugins in der DLL (in einer DLL können mehrere Plugins enthalten sein).
In die AppDomain wird jetzt das DomainBridge-Objekt geladen (das befindet sich noch in der Assembly vom Plugin-Host). Dieser Umweg ist notwendig, da jede DLL immer in die aktuelle AppDomain geladen wird.
Die DomainBridge lädt nun die Plugin-DLL und erstellt von allen Plugins darin eine Instanz. Die Instanzen werden dann bis nach oben in den PluginManager durchgereicht.
Weil die DomainBridge in einer separaten AppDomain läuft (diese ist ja von ManagedPluginLibrary erstellt worden), wird die Plugin-DLL in die separate AppDomain geladen und die Plugins bleiben isoliert von der Haupt-Domain.

Das alles ist nötig, da man nur ganze AppDomains entladen kann, nicht einzelne DLLs. Also braucht jede DLL eine eigene AppDomain um entladen werden zu können.

Dieser Thread lässt mal wieder den Gedanken eines Plugin-Guides / - Tutorials aufkommen... und erinnert mich daran, dass ich noch den Source vom GM komplett öffnen wollte...

Mfg NeuroCoder

Ich verweise dann auch aml dreist auf CodeProject: Plug-ins in C#

Allerdings habe ich dir mal eine vereinfachte Version des Plugin-Systems aus besagtem Generic Manipulator in den Anhang gepackt.

Danke, dass hat geholfen.