In the first article in this series we created a basic, static T4 template.The template allowed us to replace standard boilerplate code for reading an app setting
string setting = ConfigurationManager.AppSettings["someSetting"];
with strongly typed property references like this
var myIntSetting = AppSettings.Default.IntValue;
var myDoubleSetting = AppSettings.Default.DoubleValue;
Here’s a summary of the requirements from the first article (slightly reordered).
- All settings defined in the project’s config file should be exposed, by default, as a public property that can be read. I’m not interested in writing to them.
- Based upon the default value (in the config file) each setting should be strongly typed (int, double, bool, string).
- The configuration file cannot be cluttered with setting-generation stuff. This was the whole issue with the Settings designer in .NET.
- Sometimes the project containing the config file is different than the project where the settings are needed (ex. WCF service hosts) so it should be possible to reference a config file in another project.
- Some settings are used by the infrastructure (such as ASP.NET) so they should be excluded.
- Some settings may need to be of a specific type that would be difficult to specify in the value (ex. a long instead of an int).
In this article we’re going to convert the static template to a dynamic template and begin working on requirements 1-3. From last time here are the areas of the template that need to be made more dynamic.
- The namespace of the type
- The name of the type, including pretty formatting
- Each public property name and type