SharePoint Addins mit eigener config Datei

Michael Friedrichs | Senior Softwareentwickler | 04.03.2020

SharePoint Addin-Technologie

Bei einer .NET-Anwendung die mittels AddIn-Technologie diverse Dlls dynamisch lädt, ist es sehr wahrscheinlich, dass die einzelnen AddIns auch entsprechende Konfigurationsdaten benötigen. Da das Prinzip der AddIn-Technologie ja gerade die Loslösung des AddIns von der Anwendung ist können/dürfen diese Konfigurationsdaten nicht in der App.config abgelegt werden. Außerdem ist eine verwendete Section in der config im AddIn definiert und nicht in der Hauptanwendung. Damit kommt es bereits beim initialen Laden der App.config zu einer Exception, da die Anwendung die Sektion nicht deserialisieren kann – das in der Section definierte Assembly wird nicht gefunden, da es sich in einem Unterverzeichnis befindet.

Programmstruktur

Eine Anwendung mit einem separaten AddInn-Verzeichnis mit den AddInn-Dlls und entsprechenden Config-Dateien (hier im Beispiel mit nur einem einzigen AddIn – ‚AddInRoutinen‘) 

Durchführung

Gehen wir davon aus, dass das AddIn eine eigene Konfigurationsdatei hat. Darin ist eine Sektion für die eigentlichen Daten definiert. Im folgenden ist exemplarisch eine entsprechende Konfigurationsdatei und die Klassendefinition der Section dargestellt. Auf die entsprechenden Attribute zur Beschreibung der ConfigurationProperties und der zu benutzenden Basisklassen wird an dieser Stelle nicht näher eingegangen.

Konfigurationsdatei der AddIn-Dll mit Definition einer eigenen Section

Wobei die Klasse Routine1Settings wie folgt definiert ist

Dann kann in der AddIn-Routine die AddInnRoutinen.dll.config mit folgendem Codeschnipsel geladen und die Daten der Section ermittelt werden.

Das Ganze funktioniert auch noch solange das AddIn-Assembly und die AddIn.config im selben Verzeichnis wie die Exe der Anwendung liegt. Anders sieht es jedoch aus, wenn es einen separaten Unterordner für die AddIns gibt. Aber gerade dies macht ja Sinn um die AddIns vom eigentlichen Programm zu separieren damit die Anwendung nur in diesem Verzeichnis nach entsprechenden Interfaces sucht.

Das benötigte Assembly zum Deserialisieren der Section wird nur gefunden, wenn in der config der Anwendung (nicht in der AddInRoutinen.config) ein entsprechender Runtime-Verweis mit der Angabe eines PrivatePath vorhanden ist. Standardmäßig sucht das ausführende Programm nur im eigenen Programm-Ordner und im Assembly-Cache. Mit dieser PrivatePath-Angabe können kommasepariert mehrere Unterordner im Programmverzeichnis angegeben werden, die ebenfalls nach dem erforderlichen Assembly durchsucht werden sollen.

Benötigter Eintrag in der Konfigurationsdatei des ausführenden Programms

Eine kleine Ergänzung in der Konfiguration der Anwendung ermöglicht bereits die korrekte Funktionsweise mit separaten Konfigurationdateien (und Section). Das ‚Probing‘-Element wird leider nicht per Intellisence angeboten. Wichtig dabei ist auch der korrekte Namespace im ‚xmlns‘-Attribut.

___________________________________________________________________________________________________

Autor: Michael Friedrichs | Senior Softwareentwickler | 04.03.2020

___________________________________________________________________________________________________

Kategorie:          Softwareentwicklung

Schlagwörter: .NET | AddIns | Coding | Microsoft SharePoint