Dynamische Konfiguration von DLLs

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 gerade die Loslösung des AddIns von der Anwendung beinhaltet, dürfen diese Konfigurationsdaten nicht in der App.config abgelegt werden. Zudem wird die verwendete Section in der Konfiguration im AddIn definiert und nicht in der Hauptanwendung. Dies führt 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 AddIn-Verzeichnis, das die AddIn-DLLs und die entsprechenden Konfigurationsdateien enthält (hier im Beispiel mit nur einem einzigen AddIn – „AddInRoutinen“).

‍

‍

Durchführung

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

‍

Konfigurationsdatei der AddIn-DLL mit Definition einer eigenen Section

‍

1<configuration>
2  <configSections>
3    <section name="routine1Settings"
4             type="AddInRoutinen.Routine1Settings, AddInRoutinen, 
5                   Version=1.0.0.0, Culture=neutral, PublicKeyToken=..." />
6  </configSections>
7
8  <routine1Settings>
9    <serviceParams name="dummy1" setting="test" />
10  </routine1Settings>
11
12  ...
13</configuration>

‍

Die Klasse Routine1Settings ist wie folgt definiert:

‍

1namespace AddInRoutinen
2{
3    public class Routine1Settings : ConfigurationSection
4    {
5        [ConfigurationProperty("serviceParams")]
6        public ServiceParams BeispielServiceParams
7        {
8            get { return (ServiceParams)this["serviceParams"]; }
9            set { this["serviceParams"] = value; }
10        }
11    }
12
13    public class ServiceParams : ConfigurationElement
14    {
15        [ConfigurationProperty("setting", DefaultValue = 1, IsRequired = false)]
16        public int Setting
17        {
18            get { return (int)this["setting"]; }
19            set { this["setting"] = value; }
20        }
21
22        [ConfigurationProperty("name", IsRequired = true)]
23        public string Name
24        {
25            get { return (string)this["name"]; }
26            set { this["name"] = value; }
27        }
28    }
29}

‍

In der AddIn-Routine kann die Datei AddInRoutinen.dll.config mit dem folgenden Codeschnipsel geladen und die Daten der Section ermittelt werden.

‍

1ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
2fileMap.ExeConfigFilename = "AddInRoutinen.dll.config";
3
4Configuration config = ConfigurationManager
5    .OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);
6
7Routine1Settings settings = config.GetSection("routine1Settings") as Routine1Settings;

‍

Das Ganze funktioniert auch, solange das AddIn-Assembly und die AddIn.config im selben Verzeichnis wie die Exe der Anwendung liegen. Anders verhält es sich jedoch, wenn ein separater Unterordner für die AddIns existiert. Dies ist besonders sinnvoll, um die AddIns vom eigentlichen Programm zu separieren, sodass die Anwendung nur in diesem Verzeichnis nach den entsprechenden Interfaces sucht.

Das benötigte Assembly zur Deserialisierung der Section wird nur gefunden, wenn in der Konfigurationsdatei 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 Programmordner und im Assembly-Cache. Mit der PrivatePath-Angabe können mehrere Unterordner im Programmverzeichnis durch Kommas getrennt angegeben werden, die ebenfalls nach dem erforderlichen Assembly durchsucht werden sollen.

‍

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

‍

1<configuration>
2  ...
3  <runtime>
4    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
5      <probing privatePath="AddIns" />
6    </assemblyBinding>
7  </runtime>
8  ...
9</configuration>

‍

Eine kleine Ergänzung in der Konfiguration der Anwendung ermöglicht die korrekte Funktionsweise mit separaten Konfigurationsdateien (und Section). Das „Probing“-Element wird leider nicht von IntelliSense vorgeschlagen. Wichtig ist hierbei auch der korrekte Namespace im xmlns-Attribut.

‍