MergeConfig Concept and Howto


If you ever wondered why it is such a pain to have your application configuration easy and simple in one place together, this might be the right tool for you. MergeConfig helps you to work with the following requirements:

  • Commandline Arguments (short and long format)
  • Reading and writing Configuration-Values from an to the Registry
  • Reading AppSetting-Values from your application configuration file
  • Encrypting sensitive data like credentials when writing them to the registry

This is the reason for the name of this library, it merges the different configuration sources together and allows you to read them from a single point.


For example, if you might want to write a command line program, you might wish to implement 3 command line parameter:

  • A Directory
  • A UserID
  • A Password

Your program might look like this:Console Example

Of course you won’t ever like to implement such a stupid program, but this is just my example.

Whishlist for commandline options

  • Implement the required parameters should be easy
  • A helptext should be printed to stdout to explain the usage to the user if he whish
  • If mandatory parameters are missing, the program should complain
  • The order of the parameter should not be relevant
  • Sensitive data like credentials should not be persisted unencrypted anywhere

All this can be achieved by using MergeConfig right easily.


How to use MergeConfig

Implementing your own application with support of MergeConfig is very simple.

Reference the library: Add a reference to the assembly Mutter.Configuration.MergeConfig.dll to your project.

To support encryption, you need to import an X509Certificate with according private key into the user’s local certificate-store on the machine. The encryption is done using RSA. If you don’t need to encrypt parameters, you can skip this. For details about the generating and installing a certificate see X509 Certificate Installation.

Integration in your main program

Your main program finally might look like this:

The first call to Config.Instance initializes the internal structures of the configuration object, which is exposed in the Instance-property. LoadCmdlineArguments() finally applies the values from the command line call as well. This is all you need to do in the main program to load the configuration.
The property ErrorMessage is set to an informative string, if any mandatory arguments are missing. Otherwise, the property is null.
The property HelpText is set to an informative string
If the user needs some help about what parameters are available e.g. by passing the parameter -h, the main routine can simply print this string to stdout.

Implementing a configuration class

For the configuration, add a new class with properties for all required values that needs to be configurable. Implement it with the singleton-pattern so that your configuration-values are available from everywhere in your code.

The call to LoadAttributes() reads your properties to the internal structures. The call to LoadRegistryAndAppSettings() reads the values stored as appSettings in your app.config and the values from the Registry.

For loading parameters passed as Commandline Arguments, you have to call

in your Main(string[] args) routine finally. With this call, the MergeConfig is initialized and ready to use. But before you can do this, you need to declare your own Configuration Properties and annotate these appropriately.

CommandLine Annotation Attributes

With the CommandLineArgument attribute you declare a Property which values can be defined as command line argument. The constructor has 5 parameters, but only the first is mandatory.



Parameter Description
longOption Commandline-argument with 2 dashes (eg. –directory)
shortOption Optional, commandline-argument with 1 dash (eg. -d)
description Optional, help-text which can be displayed when the user needs help, you might implement something like this: 

Default: Empty-String
required The call to LoadCommandLineArguments() throws an Exception is the value is missing after processing all Arguments if you specify this value as true.
Default: false
flag Optional, marks the property as a Boolean, no argument needs to be passed to the parameter. If it is absent, the value is false, if present the value is true.
A property can only be marked as a flag if its type is Boolean.

You can find further examples in the sample Application.

Persistent Annotation Attribute

This attribute marks a property to be read from the appSettings and from the registry. When you call SaveSettings(), the current value is written to the HKCU-hive of the registry.

If you don’t apply this attribute to a property but only mark it as command line attribute, values in the registry and appSettings are ignored.


Encrypted and EncryptionCertificate Attribute

MergeConfig allows you to store configuration values encrypted in the registry or appSettings. For this to work you need to annotate the property with the Encrypted-attribute.

For the encryption, MergeConfig uses a user-certificate (X509Certificate) which is stored in the personal user cert store. You also have to tell how to retrieve this certificate. To provide this reference information, you have to annotate the whole class with the EncryptionCertificate-Attribute. In this Annotation you tell the configuration class where to find the according certificate.

For details about the generating and installing a certificate see X509 Certificate Installation.


The annotation needs one or two attributes.

Parameter Description
lookupType How to lookup the certificate 

  • DefaultCertificateSubject: Lookup the certificate using the Default Subject CN=MergeConfig-user@machine
  • Thumbprint: Lookup the certificate by specifying the thumbprint in the annotations constructor
  • Subject: Lookup the certificate by specifying the subject in the annotations constructor
  • ThumbprintProperty: Lookup the certificate by using the value as thumbprint find string in the property
  • SubjectProperty: Lookup the certificate by using the value as subject find string in the property
findParameter Search value to find the certificate according the lookup type. 

  • DefaultCertifateSubject: No find parameter is used
  • Thumbprint: Provide the thumbprint of the certificate in the annotation
  • Subject: Provide the subject of the certificate in the annotation
  • ThumbprintProperty: Provide the name of a config-Property in the annotation which contains the certificate’s thumbprint to find the certificate
  • SubjectProperty: Provide the name of a config-Property in the annotation which contains the certificate’s subject to find the certificate.

The most common scenario is, to use ThumbprintProperty in the annotation of the class and then put the thumbprint of your certificate into the app.config or registry.


The example requires a property defined in your config class with the name UserCertificateThumbprint.

The property is annotated as persisted so that its value is read from the application’s app.config.

For the credential-property itself, you only need to annotate the property with the Encrypted-attribute. Of course you might also use the Persistent-attribute as well, if you don’t want to provide the encrypted value on the command line only.


The idea behind this feature is, that you can start your program once specifying credentials on the command line. After the first shot, the credentials are stored and you don’t need to specify the password any more next time you start the program.

ConfigSerializer Attribute

You might want to store other data structures as simple types as well. For this reason, it is possible to implement a value converter which serializes an arbitrary data type into a string and vice versa. MergeConfig calls the Deserialize() method when a value has to be loaded from the source and Serialize() when the value has to be stored.


The converter needs to implement the IParameterConverter-interface.

You can find an example how to implement this interface in the sample application.

X509 Certificate Installation

Parameter encryption is done using a regular X509-certificate. You may use any certificate you already have available, you just need a certificate with its corresponding private key. The program references the certificate explicitly using it’s subject or thumbprint, therefore there will be no effort in certificate validation. Certificate attributes, validity period and all other metadata in the certificate are simply ignored. All you need is a public and a private key.

MergeConfig does not contain any code to generate such a certificate, there are plenty of other tools available to do this. e.g.

The simplest way to generate a X509-certificate suitable for MergeConfig is using OpenSSL. The following commands generate a simple self signed certificate from scratch.

Generate a private key

Generate a certificate signing request. The subject you enter here can be later be used to reference the certificate in your program if you don’t want to use the thumbprint.

Now the certificate can be generated by signing it with the private key. This results in a self signed certificate with a validity of 10 years.

Finally the generated certificate is packaged into a PFX-file so that it can be imported into the windows certificate store. The password you enter here is needed when you import the file with the certificate manager.

Import the generated file cert.pfx using the Windows certificate manager (certmgr.msc)

To reference the certificate from your application, you may use the thumbprint of the certificate. To get the thumprint using openssl use the following syntax:

Replace the colons with nothing or spaces and put the value in your app.config


Challenges of application configuration

There are several different ways to configure an application. In the early days of computer technology, all programs were started from command line. The configuration was taken from command line parameters and maybe from a configuration file in a settings directory, program folder or somewhere else. Microsoft Windows started to store configuration values in a database called Registry.

The .Net framework started to provide another configuration framework which is hierarchically organized. The configuration of every .Net application is based on the system wide machine.config which is read from the frameworks installation directory. When the app-domain is created these values are merged with the app.config or web.config (depending on the type of your application) and finally values may also be stored on a user basis.

You might come to the conclusion, that this concept is all you need, me too, but what about command line parameters? Ok, let’s just extend this .Net concept with a command line parser to copy the values from command line to the .Net configuration.

Fine, but I still would like to have my own configuration values separated from all the other stuff lying around in the .Net configuration world. In my opinion, the .Net configuration file is more part of the application deployment, a system engineer should not have to configure things like assembly bindings or compilation options. There is too much development stuff there, which should not be touched any more, when an application is finally tested. This is the reason I prefer to have configuration values, which might be defined by the application user or system administrator, separated from stuff which should be under control of the application’s developer.

Did you ever put your finger on your machine.config? I did, and I bricked my whole system until I remembered messing around with options I didn’t really understand.

Why using the Registry

For a long time, the registry was the state of the art way to store configuration values in windows applications. Due to the reason that some developer prefer to configure applications together instead of compiling them and use configuration for its real purpose, the windows-registry was highly misused for purposes which have nothing to do with configuration. This led in complex structures which are no longer maintainable by a system administrator. But in my opinion, the windows-registry is still a good place to put configuration values for new applications. This is the reason I would like to support this place for storing configuration values.

The .net configuration world also support user writable configuration files. But the way this works is so complex, that it is not possible for a system administrator to deal with these values directly. Only the access through the application itself seems reasonable.

I prefer to make things easier. Therefore MergeConfig uses the standard HKLM and HKCU registry hive to read configuration values from. If an application stores user configuration, values are stored in the HKCU-hive. The path is built from the applications manifest using the standard convention:

No strong-name, no hash-values, no GUID.

Microsoft Reporting Services 2012 Security Configuration

SSRS 2012 – Berechtigungen setzen nach einer Neuinstallation

Nach der Installation vom Microsoft Reporting Service SSRS in einer neuen Umgebung, funktioniert der Zugriff auf die Website nur, wenn der Internet Explorer mit Administrativen Berechtigungen (Elevated Privileges) gestartet wird.

IE Admin

Die URL https://ssrs01.mydomain.local/Reports linkt dabei auf die Hauptseite vom Reportmanager.

Report Manager

Ohne die korrekten Berechtigungseinstellungen, bekommt man allerdings folgende Fehlermeldung zu Gesicht.

Permission Error

Damit SSRS ohne Administrative Berechtigungen funktionieren und auch keine zusätzliche Loginbox erscheint, sind folgende Einstellungen vorzunehmen:

  1. SSRS so konfigurieren, dass über einen korrekten DNS-Namen zugegriffen wird
  2. Dem IE die Intranet-Domäne als Trusted-Site zuweisen, ansonsten funktioniert SSO nicht mit dem IE
  3. Eine AD-Gruppe für die Verwaltung vom Report-Server erstellen oder definieren
  4. In SSRS Site-Settings die AD-Gruppe eintragen
  5. In SSRS Folder-Settings die Gruppe berechtigen

IE Options

  • Wenn möglich, in der SSRS-Konfiguration dem Service ein Serverzertifikat zuweisen.
  • Die Einstellung auf der jeweiligen https-URL vornehmen.

Internet Options

Es kann sein, dass diese Einstellung nicht sofort wirksam ist, ein erneutes Login bzw. Reboot kann dabei nützlich sein.

SSRS Site Settings – Security

Im SSRS Report Manager oben im Menu auf Site Settings klicken. Anschliessend mit New Role Assignment eine AD-Gruppe als Systemadministrator hinzufügen. Unter Group or user name muss die Gruppe in der Schreibweise domäne\gruppenname eingegeben werden. Eine Browse-Funktion gibt es nicht!

SSRS Site Settings

SSRS Folder Settings

Das reicht allerdings noch nicht. Neben der funktionellen Sicherheitseinstellung, gibt es auch noch Berechtigungen auf Ordner-Ebene. Auch da muss die entsprechende Gruppe eingetragen werden.

Dazu geht man im Report manager unter Home auf Folder Settings und fügt mit „New Role Assignment“ die Admin-Gruppe ebenfalls hinzu.

Folder Security

Nun kann man auf den SSRS Report Manager ohne spezielle Vorkehrungen mit einer normalen IE-Session zugreifen, natürlich nur wenn man in der angegebenen AD-Gruppe ist.

SSRS SSL Konfiguration

Die SSRS Reporting-Services benötigen keinen IIS für die Webapplikation, sondern enthalten einen eigenen Webserver. Allerdings ist der parallele Betrieb vom IIS und SSRS auf demselben Hostnamen möglich, was mitunter zur verwirrenden Konstellation führt, dass URL’s auf demselben Protokoll+Hostnamen+Port dennoch von unterschiedlichen Services bedient werden.

Will man auf SSRS-Dienste mittels HTTPS zugreifen, muss ein Zertifikat mit dem jeweiligen Hostnamen als Common-Name im Certificate-Store vom Computer-Account installiert werden. So wie es aussieht, kennt der Configuration Manager das Konzept der Subject Alternative Names nicht. Es muss daher für jedes SSL-Binding ein Zertifikat mit dem entsprechenden Common-Name zur Verfügung stehen!

Oracle APEX Deployment

Wer im Enterprise-Umfeld mit Oracle APEX arbeitet kommt um das Thema Deployment nicht herum. Dafür gibt es grundsätzlich die Methode, via Export/Import eine Applikation inkl. sämtlicher Resourcen von einer Umgebung auf eine andere zu kopieren. Im Enterprise-Umfeld eine eher unbrauchbare Variante.
Als Alternative besteht die Möglichkeit, eine APEX-Anwendung via SQL zu deployen. Die exportierten Daten bestehen letztendlich lediglich aus SQL-Scripts. Dabei gibt es aber einiges zu beachten.

  1. Einfach die SQL-Files als APEX-Oracle-User ausführen funktioniert nicht. Man bekommt nicht einmal eine schlaue Fehlermeldung. Es muss zuvor der korrekte Security-Kontext und Application-Kontext hergestellt werden.
  2. Die sog. Supporting-Objects (Images, CSS-Files usw.) müssen zusätzlich installiert werden. Mit der Applikation können zwar installationsscripts generiert werden, beim Aufruf werden diese aber nicht ausgeführt. Bisher konnte ich nicht in Erfahrung bringen, wie man diese gleich mit ausführt, analog zur Installation via Webinterface.

Script mit Supporting Objects erstellen

Um ein Script mit Bildern, CSS-Files usw. zu erstellen geht man folgendermassen vor:

In der Applikation zu den Supporting Objects Navigieren

Link Install Scripts anklicken

Create anklicken

Unten auf Create Install Files klicken

Auswahl der einzufügendenen Bilder, CSS-Files usw. treffen und auf Create Script klicken.

Nun tauchen unter Supporting Objects die generierten Objektscripts auf.

Export der Applikation

Um eine APEX Applikation unternehmenstauglich zu exportieren und zu importieren, wird die Applikation als solches und zusätzlich das Scripts mit den Files exportiert. Beides kann anschliessend an einem SQL-Prompt in eine andere APEX-Installation deployed werden.

Im Application-Builder den Task Export aufrufen und auf den Tab Application wechseln. Da wir die Supporting-Objects separat exportieren müssen, macht es keinen Sinn, diese mit zu deployen. Diese Option funktioniert nur beim manuellen Import im Webinterface.

Im Application-Builder den Task Export aufrufen und auf den Reiter Files wechseln. Die gewünschte Applikation auswählen und Export Images anklicken.

Genau gleich wie die Bilder lassen sich auch CSS-Files in Installationsscripts exportieren.

Import der Applikation und Supporting Objects via SQL

Um eine Applikation mit allen Komponenten zu importieren kann man entweder das GUI verwenden oder man führt die Befehle in den SQL-Scripts via SqlPlus oder JDBC aus. Der Haken dabei ist, dass man die Scripts nicht einfach so ausführen darf, ansonsten wird nichts importiert.

Security Kontext herstellen

Die Installationsscripts enthalten einfach eine Reihe von PL/SQL-Aufrufe, die man prinzipiell mit jeder Datenbankverbindung ausführen kann. Damit das funktioniert, muss man zunächst den Security-Kontext herstellen. Dabei wird einfach die gewünschte WorkspaceID und ApplicationID gesetzt. An der gleichen Stelle hat man auch die Möglichkeit eine neue ApplicationID zu generieren, wenn man die gleiche Applikationen mehrfach im gleichen Listener betreiben möchte.

WORKSPACE: Name vom Workspace in den die Applikation importiert werden soll. Dieser muss zuvor angelegt sein.
APPALIAS: Alias der Applikation, wenn in der APEX-Instanz bereits eine Applikation mit demselben Alias existiert, wird diese ersetzt. Ansonsten wir eine neue AppID generiert.


Die entsprechenden PL/SQL-Funktionen, welche Apex selbst im exportierten Script verwendet sind wenig bis gar nicht dokumentiert. Daher kann man häufig nur mutmassen was genau passiert.

Das Deployment basiert auf der Mechanik, dass ein File primär als Base64-encodierte String-Literals im SQL-Script stehen. Dabei wird die Package-Variable wwv_flow_image_api.g_varchar2_table mit einem Array von Strings befüllt. In einem Nachfolgenden API-Aufruf (wwv_flow_image_api.new_image_repository_record, wwv_flow_css_api.new_css_repository_record) wird das entsprechende File zusammen mit weiteren Metadaten (Filename, Beschreibung, Mimetype) registiert.

Aus PowerShell auf Oracle zugreifen

Da die Windows PowerShell komplett auf .Net basiert, können grundsätzlich alle .Net-Klassen von PowerShell verwendet werden. Befindet sich der entsprechende Provider aber nicht in der Standard-Klassenbibliothek, muss das entsprechende Assembly noch nachgeladen werden.
Möchte man von PowerShell aus auf eine Oracle-Datenbank zugreifen, muss das Assembly Oracle.DataAccess geladen werden. Dabei ist zu beachten, dass es für 32-Bit und 64-Bit Prozesse unterschiedliche Assemblies gibt, lädt man das falsche, erhält man eine Exception beim Laden der jeweiligen DLL.

Die Zuweisung von Assembly.Load in eine Variable ist eigentlich nicht nötig, da die PowerShell aber nicht zugewiesene Rückgabewerte in die Outputpipeline schreibt, wird das Resultat von ToString() sonst auf die Console geschrieben.

Oracle Timestamps

Oracle unterscheided verschiedene Timestamp-Genauigkeiten

Der Unterschied liegt in der Genauigkeit:

  • Ohne Precision-Angabe wird ein TIMESTAMP mit 7 Nachkommastellen angelegt
  • Mit Precision=0 wird ein Timestamp ohne Nachkommastellen angelegt
  • Mit Precision=9 wird ein Timestamp mit 9 Nachkommastellen angelegt

Die Nachkommastellen beziehen sich dabei auf die Sekundenbruchteile, die mit abgespeichert werden.


  • TS1: 12.11.2012 10:11:12.123457
  • TS2: 13.11.2012 10:11:12
  • TS3: 14.11.2012 10:11:12.123456789

Windows PowerShell Scripts aus .Net heraus aufrufen

Mit der Lancierung der PowerShell hat Microsoft einen rechten Coup gelandet. PowerShell ist Microsofts Antwort auf die steten Vorwürfe, dass Windows nicht besonders Enterprise tauglich sei, da viele Operationen nicht oder nur sehr schlecht automatisierbar sind. Die Unix-Fraktion hingegen hat für die Systemadministration seit jeher auf Shell-Scripts gesetzt.

Die PowerShell ist eine recht gelungene Mischung aus objektorientierter Programmierung und einer Shell. Im Gegensatz zu den weit verbreiteten Unix-Shells wie Bash, Ksh usw. ist die PowerShell nicht textbasiert, sondern arbeitet direkt mit Objekten. Das bedeutet, dass die Datenstruktur z.B. bei Pipeline-Operationen erhalten bleibt, es ist also keine Text-Fummelei mit AWK oder ähnlichem notwendig.

Da die PowerShell vollständig auf .Net basiert, ist es nicht nur möglich einzelne sog. Commandlets mit .Net zu implementieren, sondern auch umgekehrt recht einfach von .Net her PowerShell Scripts auszuführen und mit dem Ergebnis weiterzuarbeiten. Dieser Blog liefert ein kleines Beispiel dazu.

Beispiel PowerShell Script aus .Net aufrufen

Als Datenstruktur dient diesem Beispiel eine Liste mit Personen und deren Berufe.

Die Liste wird mit Beispieldaten instanziert.

In diesem Beispiel werden die Daten einem Powershell Script übergeben, dieses formatiert damit den Output und modifiziert zusätzlich die Daten. Das Programm selbst listet zunächst die Beispieldaten vor der Scriptausführung und danach auf.

Das Powershell Script sieht folgendermassen aus:

Der instanzierte Runspace übergibt dem Script einerseits die Variable $Anzahl und andererseits wird eine Pipeline mit Objekten bestückt. Im Script steht die Variable ganz normal zur Verfügung und die Objekte in der Pipeline findet man in $Input.

Das PowerShell Script wird aus .Net heraus folgendermassen ausgeführt

Viel Spass

Unwillen von Adressbüchern

Eigentlich mag ich es, wenn ich mich um solch profane Dinge wie Verwaltung von Kontaktlisten  nicht zu intensiv kümmern muss, aber manchmal macht einem da die Umsetzung der Technik einen Strich durch die Rechnung.

Wo liegt der Master?

Hier scheiden sch die Personen in 2 Gruppen: Die einen folgen den allgemeinen Trends und überlassen die Kontrolle über ihre Daten irgend einem Dienstleister. Die andern versuchen ihre Daten selbst unter Kontrolle zu bringen, halten sich an Standards und versuchen diese möglichst breit anzuwenden.

Gehören sie zur ersten Kategorie? Dann können sie hier aufhören zu lesen. Der Rest dürfte Sie eher langweilen. Ihnen ist ja egal, wer alles Zugriff auf Ihre Kontakte hat, hauptsache alles ist schön bequem.

Wenn man wie ich zur zweiten Kategorie gehört, beginnt man sich irgendwann zu überlegen, wie man seine Kontakte verwaltet und diese dann möglichst einfach auf alle Geräte bringt, auf welchen man diese benötigt.

Kontakte sammeln sich mit der Zeit überall an, wo man kommuniziert.

  • E-Mailclient
  • Mobile Phone
  • Smartphone (das kommt dann hald mal dazu)
  • 2. Computer mit einem anderen Mailclient
  • CMS (ev. sogar mehrere, man hat ja ev. auch noch einen Arbeitgeber)
  • Mailclient bei Kunden
  • Cloud (man geht ja mit der Zeit)
  • Cloud-2 (ja wenn sich die Hersteller ja nur einigen könnten…)

Naheliegend wäre dabei ja, seine Kontakte primär einmal in seinem E-Mail Account zu sammeln und von da aus auf die anderen Geräte zu synchronisieren. Importieren ist ja kein Problem, aber exportieren?


Die Auswahl an Formaten scheint gross, man kann aber im Wesentlichen wählen zwischen “Unbrauchbar” und “Proprietär”. Wie wärs mit XML?

Zwischen mehreren Outlook Profilen kann man seine Daten noch via PST austauschen. Aber wie bringt man diese Kontakte nun ins Adressbuch von einem Mac? Pustekuchen.

Standards: vCard

Aber es geht doch: Outlook 2007 kann Contact-Items via Drag & Drop in vCard-Files exportieren. Unterstütz dabei aber nur vCard 2.0 mit ANSI-Encoding.

Importiert man diese vCards in ein Mac Adressbuch, stellt man fest, dass das Encoding falsch interpretiert wird. Der Mac erwartet UTF-8. Willkommen in der Encoding-Hölle.