This is the first post in a series on Azure Data Factory Custom Activity Development.
Configuration Setttings for Custom Activities
A very common requirement is to set up some configuration settings for your custom activity. Unfortunately, as your custom activity will be a dll, this is not easy using standard DotNet app.config file approaches.
The Settings File
The Settings file was introduced back in DotNet 2.0, as an improvement over config files for configuration and customisation settings. In Visual Studio these are found in your solution under “Properties” and have the benefit of a simple UI for editing values.
Settings files support all the primitive data types (int, string etc.) and also items such as System.DateTime, System.TimeSpan and also allows using any types referenced within the project. For most purposes primitive types will probably suffice however.
There are two settings scope types, being User and Application, for User-specific or Application-wide settings. For our purposes the Application scoped settings are fine, although all settings will be visible from within your code. Application settings cannot be changed once the application has started, whereas User settings are writable, allowing the User to make changes to their own settings as needed. It is worth noting that you cannot have a more than one setting with the same name, regardless of scope.
Interestingly, these settings are then saved in the app.config file for the assembly, as below, and are readily discovered and accessible using the Properties.Settings namespace within your code.
<applicationSettings>
<Adatis.ADF.CustomActivities.Properties.Settings>
<setting name="documentDbDnsPrefix" serializeAs="String">
<value>documents.azure.com:443/</value>
</setting>
Making use of our Settings file settings is then a case of simply reading these values into static fields within our custom activity class for further use.
private string documentDbDnsPrefix = Properties.Settings.Default.DocumentDbDnsPrefix;
So a nice short one for the start of the series and hopefully of use to those of us developing ADF Custom Activities looking for a simple configuration settings solution.
Next up…
Join me for the next instalment in the series, Part 2: Encapsulating Common Functionality.
