ZS PluginSystem

[JoZ1]

ZS PluginLibrary is – zoals de naam al suggereert – een .NET bibliotheek die een infrastructuur biedt voor het schrijven en ondersteunen van plugins. Developers kunnen ZS PluginLibrary op een eenvoudige manier implementeren, waarna andere ontwikkelaars eenvoudig plugins kunnen schrijven voor uw applicatie.

ZS PluginLibrary is hier te downloaden. Bijgevoegd is een uitgebreide documentatie (EN), waarin alle toegankelijke functies, klassen en objecten staan vermeld, en een voorbeeldproject in C# en Visual Basic .NET.

Een aantal screenshots (klik voor vergroting):



Deze bibliotheek vereist .NET Framework 2.0 of hoger. Het mag gratis gebruikt worden - met vermelding van de auteur - voor niet-commerciële doeleinden.
Voor commerciële doeleinden moet men eerst contact opnemen met de auteur.

Dus... testers zijn welkom

 

[Bloodshed]

Ik kreeg eerst wat foutmeldingen toen ik een hoger framework gebruikte, maar kan zijn dat ik het gewoon even snel wou testen en iets over het hoofd heb gezien. Moet ik later nog eens wat beter testen.
Eventuele opmerkingen komen later.

Maar voor zover werkt het prima.

 

[JoZ1]

@Bloodshed: Thanks! Ben benieuwd naar die foutmeldingen.

 

[JoZ1]

Bump

 

[Bloodshed]

Ai! Vergeten nadat ik dingen had overgezet naar windows 8 etc... zal nog eens iets testen want ik heb m'n test projects folder getrashed, sorry!

 

[JoZ1]

Haha, maakt niet uit. Ben al blij dat er iemand met verstand van zaken is die reageert

 

[Bloodshed]

Ik kreeg dit keer geen foutmeldingen over de framework versie die ik gebruikte, dus weet niet precies wat het vorige keer was.

Een paar opmerkingen:

- Alleen te gebruiken met windows forms. (Host parameter)

- Kan verwarring ontstaan tussen de IPlugin interface en de Plugin struct. Weet alleen niet waarom het een struct is, ik kan me het voorstellen dat er een IPlugin variable in de struct zelf zit en de Plugin als wrapper werkt maar dan kun je het net zo goed een class maken want dan verlies je toch het voordeel van de struct.

- Als ik als directory bij pluginsystem zoiets als 'C:/Folder??' invoer krijg ik geen feedback dat het pad ongeldig is of iets dergelijks, intern zal hij waarschijnlijk de fout opvangen maar misschien handig dat de developer bij dit soort dingen een exception krijgt zodat hij dit zelf kan opvangen i.p.v. geen melding te krijgen.

- misschien een property op de IPlugin toevoegen zoals website of iets dergelijks om de kijken voor nieuwe plugin versies


Verder niet veel op aan te merken, meer dingen kom je waarschijnlijk pas achter als je het echt ergens in gaan gebruiken.
Misschien kun je nog een interface maken zodat een gebruiker zelf een plugin manager kan maken met eigen ontwerp.

Het meeste zoals exception handling en het laden van plugins etc is allemaal in de .dll gedaan dus eenvoudig te gebruiken.


//naming OCD (persoonlijk )

.NET namespace stijl aanhouden ipv ZS_PluginSystem

ZS.PluginSystem;

of

ZS.System;

of

Zuijderwijk.System;
Zuijderwijk.System.IPlugin;
Zuijderwijk.System.PluginService;
Zuijderwijk.System.Windows.AboutDialog;
Zuijderwijk.System.Windows.PluginManager;

 

[Maximvdw]

Hallo,

Namespace ga ik mee akkoord.
Het is altijd ordelijk om het wat te ordenen.
Wel zorgen dat je niet alles in apparte namespaces zet.. anders blijf je bezig met importen.

Persoonlijk zet ik een interface public, en een class die de interface gebruikt in een internal class.
Maar dat hangt af van moment tot moment. Eigenlijk is de manier waarop je het doet, volgens de regels van de kunst, dus
daar is niets op aan te merken

Offtopic: Ik vraag me dit steeds af.. dat randje onder je witte header (die grijze lijn) hoe heb je die precies gedaan ?
zelf gebruikte ik meestal tablelayout. maar dit ziet er beter uit

gr,
Maxim

 

[Bloodshed]

Je kunt gewoon het panel met border achter de form rand verbergen links, boven, en rechts.

Of een wit panel in de top docken, dan een 2e panel ook in de top docken (onder panel1) en deze met rand een hoogte van 1 geven


Edit:
Als het niet 100% duidelijk was

Zuijderwijk.System;
Zuijderwijk.System.IPlugin;
Zuijderwijk.System.PluginService;
Zuijderwijk.System.Windows.AboutDialog;
Zuijderwijk.System.Windows.PluginManager;

zouden 2 namespaces zijn:

Zuijderwijk.System;
Zuijderwijk.System.Windows;

 

[JoZ1]

- Alleen te gebruiken met windows forms. (Host parameter)

Hmm, dat klopt. Hoe kan ik dat oplossen?

- Kan verwarring ontstaan tussen de IPlugin interface en de Plugin struct. Weet alleen niet waarom het een struct is, ik kan me het voorstellen dat er een IPlugin variable in de struct zelf zit en de Plugin als wrapper werkt maar dan kun je het net zo goed een class maken want dan verlies je toch het voordeel van de struct.

De Plugin-structure verwijst naar de al in de host geladen plugins. Is misschien beter als ik daar een class van maak inderdaad.

- Als ik als directory bij pluginsystem zoiets als 'C:/Folder??' invoer krijg ik geen feedback dat het pad ongeldig is of iets dergelijks, intern zal hij waarschijnlijk de fout opvangen maar misschien handig dat de developer bij dit soort dingen een exception krijgt zodat hij dit zelf kan opvangen i.p.v. geen melding te krijgen.

Het pad moet inderdaad wel toegankelijk zijn voor het programma (wat is de foutmelding?).
Standaard zou ik hier als waarde Application.StartupPath & "\Plugins\" gebruiken. En is het slimmer als ik exceptions niet meer intern afhandel?

- misschien een property op de IPlugin toevoegen zoals website of iets dergelijks om de kijken voor nieuwe plugin versies.

Gutes Idee!

Verder niet veel op aan te merken, meer dingen kom je waarschijnlijk pas achter als je het echt ergens in gaan gebruiken.
Misschien kun je nog een interface maken zodat een gebruiker zelf een plugin manager kan maken met eigen ontwerp.

Alles wat de gebruiker nodig heeft om een pluginmanager te maken, kan eigenlijk al met de Plugin-struct en de Plugins-property van de PluginSystem class.

.NET namespace stijl aanhouden ipv ZS_PluginSystem

ZS.PluginSystem;

of

ZS.System;

of

Zuijderwijk.System;
Zuijderwijk.System.IPlugin;
Zuijderwijk.System.PluginService;
Zuijderwijk.System.Windows.AboutDialog;
Zuijderwijk.System.Windows.PluginManager;

Ja! Dat is inderdaad een stuk eenvoudiger dan mijn huidge naamgeving. Ga ik toepassen!

Offtopic: Ik vraag me dit steeds af.. dat randje onder je witte header (die grijze lijn) hoe heb je die precies gedaan ?
zelf gebruikte ik meestal tablelayout. maar dit ziet er beter uit

Ik heb het op deze manier gedaan:

Je kunt gewoon het panel met border achter de form rand verbergen links, boven, en rechts.

Bedankt voor jullie antwoorden! Ik laat het weten als er een update is.

- JoZ1

 

[JoZ1]

De naamgeving (namespaces) hou ik bij nader inzien gewoon zoals het was. De objecten die in ZS.PluginSystem.Windows zouden verdwijnen, zijn an sich helemaal niet beschikbaar voor de gebruiker (staan ook niet beschreven in de documentatie). Ik ga nu de mogelijkheid inbouwen om de plugin te starten bij het opstarten van de host (nu is het alleen mogelijk de plugin te starten via de menubalk of door de gebruiker codematig).

 

[Bloodshed]

De namespaces zijn vooral ook voor jezelf en als je na een paar maanden weer eens naar je code kijkt.

- Host Parameter (Form)

Je zou misschien een IHost interface kunnen maken. Een form,window of class kan deze dan implementeren, met de desbetreffende properties en methods om het werkend te maken.




- Plugins list

Hier zitten de properties zoals Name/Description/Author niet in, wat je misschien zou kunnen maken is een PluginInfo struct/class waar deze dingen allemaal in zitten.

    public interface IPlugin
    {
        PluginInfo Info { get; }

        //other properties and methods here
    }

    public struct PluginInfo
    {
        private readonly string _name;
        private readonly string _description;
        private readonly string _author;
        private readonly string _version;
        private readonly string _websiteUrl;

        public PluginInfo(string name, string description, string author, string version, string websiteUrl)
        {
            _name = name;
            _description = description;
            _author = author;
            _version = version;
            _websiteUrl = websiteUrl;
        }

        public string Name
        {
            get { return _name; }
        }
        public string Description
        {
            get { return _description; }
        }
        public string Author
        {
            get { return _author; }
        }
        public string Version
        {
            get { return _version; }
        }
        public string WebsiteUrl
        {
            get { return _websiteUrl; }
        }
    }

- plugin directory

Ik kreeg just geen foutmelding maar uiteraard kon er ook niets worden geladen. Dat ik geen exception of iets dergelijks kreeg was juist het probleem. Als iemand per ongelijk een illegal char er tussen zet kan hij zich uren rotzoeken waarom er iets niet werkte



Alles is uiteraard aan jezelf want er zijn 100 verschillende methode om iets te doen, ik ben er altijd voor alles netjes in classes te stoppen, geen/weinig code in the Form/Window/Page code behind file, geen static methods overal instoppen maar instances in constructor doorgeven, events gebruiken, etc etc

 

[JoZ1]

Hier versie 2.0.

- Host Parameter (Form)

Je zou misschien een IHost interface kunnen maken. Een form,window of class kan deze dan implementeren, met de desbetreffende properties en methods om het werkend te maken.

Zit wat in... Daar kan ik inderdaad eens naar kijken, thanks.

- Plugins list
Hier zitten de properties zoals Name/Description/Author niet in, wat je misschien zou kunnen maken is een PluginInfo struct/class waar deze dingen allemaal in zitten.

Dat is nu ingebouwd. De plugin-class heeft nu toegang tot alle properties van IPlugin.

- plugin directory

Ik kreeg just geen foutmelding maar uiteraard kon er ook niets worden geladen. Dat ik geen exception of iets dergelijks kreeg was juist het probleem. Als iemand per ongelijk een illegal char er tussen zet kan hij zich uren rotzoeken waarom er iets niet werkte

Als zo'n directory niet bestaat, wordt die automatisch aangemaakt. Wat was precies de directory die je invoerde?

Alles is uiteraard aan jezelf want er zijn 100 verschillende methode om iets te doen, ik ben er altijd voor alles netjes in classes te stoppen, geen/weinig code in the Form/Window/Page code behind file, geen static methods overal instoppen maar instances in constructor doorgeven, events gebruiken, etc etc

Haha, precies. Ik probeer dat ook zo veel mogelijk te doen.


Verder heb ik twee aparte methods gemaakt voor starten (één zodat de plugin mee kan starten met de host, en de ander voor het openen via het menu).

 

[Bloodshed]

Als zo'n directory niet bestaat, wordt die automatisch aangemaakt. Wat was precies de directory die je invoerde?

Maar als er characters in de string staan die niet in een map morgen voorkomen (bv: ?, *, :, \ ) dan kun je hem ook niet aanmaken, of je moet al deze characters eruit vissen. Of maak je dan een map aan met een standaard naam? (heb dit niet nagekeken)

Het is maar een kleinigheidje maar ik kwam het tegen


EDIT:
wat ook grappig is als je op het formclosing event registreert van de host, en dan in het event het sluiten annuleert, lekkere plugin

        public void Start()
        {
            Host.Host.FormClosing += HostFormClosing;
        }

        private void HostFormClosing(object sender, FormClosingEventArgs e)
        {
            e.Cancel = true;
        }

 

[JoZ1]

Maar als er characters in de string staan die niet in een map morgen voorkomen (bv: ?, *, :, \ ) dan kun je hem ook niet aanmaken, of je moet al deze characters eruit vissen. Of maak je dan een map aan met een standaard naam? (heb dit niet nagekeken)

Inderdaad, dit ga ik aanpassen. Er gebeurt namelijk helemaal niks (het wordt intern afgevangen zonder foutmelding).

EDIT:
wat ook grappig is als je op het formclosing event registreert van de host, en dan in het event het sluiten annuleert, lekkere plugin

        public void Start()
        {
            Host.Host.FormClosing += HostFormClosing;
        }

        private void HostFormClosing(object sender, FormClosingEventArgs e)
        {
            e.Cancel = true;
        }

Ja, daar had ik ook al aan gedacht. Maar in principe kan ook iemand malware downloaden via een plugin.
Dus het is de verantwoordelijkheid van de eindgebruiker om te beslissen welke plugins veilig zijn en welke niet.