Environmental Config Transforms, Part 1

Configuration file transforms have been around for quite a while and most companies use them to generate different config files for each environment but Visual Studio does not really support the functionality most companies need.In this article I’m going to talk about why the existing Visual Studio implementation is flawed and how to fix it so that you can have true environmental transforms that are actually useful.

For purposes of this article we will assume a simple web application (although it applies to any application) that will be deployed to 2 different environments – test and production. We will also assume that developers debug the application on their local machine and therefore should not have to do any special tasks to debug the application locally. As such we’ll have a 3th, default, environment – debug.

Read More

Using T4 to Create an AppSettings Wrapper, Part 7

In this final article in the series we’re finishing up the deployment projects started last time. When we’re complete we’ll have a set up projects that can be used to build and deploy T4 templates where needed. The projects will be able to support any number of templates so maintenance will be simple even as more templates are added. In the previous article we moved the core template functionality into a library that we can expand upon. We also set up an item template project to store the root T4 template that someone would use. In this article we’re going to create the project to store the nested templates (we’ll discuss why later) along with the Visual Studio Extension (vsix) file that will be used to install everything.

Read More

Using T4 to Create an AppSettings Wrapper

Update 28 Aug 2016: Refer to this link for updated code supporting Visual Studio 2015.

This is the table of contents for the series on using T4 to create an AppSettings wrapper for use in any code.

  1. Creating a static T4 Template for AppSettings
  2. Creating a dynamic T4 Template for AppSettings
  3. Reading Settings from the Configuration File
  4. Separating Customizable Parts from Static Parts
  5. >Customizing the Template
  6. Creating a Deployment Package (Part 1)
  7. Creating a Deployment Package (Part 2)

Using T4 to Create an AppSettings Wrapper, Part 6

In this (almost) final post in the series on creating an AppSettings wrapper in T4 we’re going to package all the work we’ve done into an easily deployable and reusable package that we can extend to include other templates.  We’ll also make sure that adding the template to a project is as easy as Add New Item.

Here’s the list of things we’ll accomplish

  • Create a custom base class and move all the shared template functionality to it.
  • Create a VS extension (VSIX) to install the parts of our template.
  • Install the shared template components into a centralized directory so projects only need to include the core template.
Read More

Using T4 to Create an AppSettings Wrapper, Part 5

In the last article we broke out the template into 2 separate template files: main and nested. A developer adds the main template to their project but it includes the nested template where the actual work is done. In this article we’re going to update the included template to allow a developer to alter the generated code without having to touch the nested template.

In the original article we listed 6 requirements for the template. At this point we have met half of them. By adding customization we will meet the final three. They are:

  • Exclude some settings
  • Change the type of a setting
  • Use the configuration file of a different project
Read More

Using T4 to Create an AppSettings Wrapper, Part 4

In the previous article we finished the basic appsettings template that allowed us to generate a strongly typed class from the settings in a configuration file. We now want to expand the template to allow it to be customized depending upon the needs of the project, a later article. Before we get there though it is time to refactor the code to make it more reusable and easier to maintain. That is the focus of this article.

Read More

Using T4 to Create an AppSettings Wrapper, Part 3

In the previous article we expanded the template to dynamically set the type and namespace names based upon the project the template is used in.Now we are going to turn our focus to generating properties for each of the settings in the configuration file. For this we’ll be adding more code to the class block to open and read the settings from the project’s configuration file (which we’ll have to write code to retrieve). We’ll also have to decide how to convert string values to typed equivalents.

Read More

Using T4 to Create an AppSettings Wrapper, Part 2

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).

  1. 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.
  2. Based upon the default value (in the config file) each setting should be strongly typed (int, double, bool, string).
  3. The configuration file cannot be cluttered with setting-generation stuff. This was the whole issue with the Settings designer in .NET.
  4. 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.
  5. Some settings are used by the infrastructure (such as ASP.NET) so they should be excluded.
  6. 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.

  1. The namespace of the type
  2. The name of the type, including pretty formatting
  3. Each public property name and type
Read More

Using T4 to Create an AppSettings Wrapper, Part 1

AppSettings are settings stored in your configuration file under the <appSettings> element. Almost every application has them. Each setting consists of a name and value. To access such a setting in code you need only do this.

string setting = ConfigurationManager.AppSettings["someSetting"];

There are a couple of problems with this approach.

  • Quite a bit of boilerplate code to access a setting given what it is actually doing
  • The setting name is hard coded and must match the config file
  • The returned value is a string so if you need a different type then you’ll need to convert it

In .NET v2.0 Microsoft added the Settings class to work around these issues. It allows you to create a setting with a type and value and the designer will generate a type to back it where each property matches the setting. This seems great but never really took off. Not even Microsoft uses it in their own framework. Part of the problem is that the config entries it generates are overly complex storing things like type information, default values and other things. Needless to say appSettings continue to be popular anyway. Fortunately we can get the simplicity of appSettings with the power of the newer Settings class all via T4.

In this series of posts I’m going to walk through the process of generating such a template including the ability to add some more advanced functionality. A full discussion of T4 is beyond the scope of a blog so refer to the following links for more information.

Read More

Strongly Typed Application Settings Using T4

We all know that the Settings infrastructure added to .NET a while back is the “correct” way to create strongly typed application settings in configuration files. The problem with this approach though is that the entries generated in the config file aren’t pretty. You have only limited control over the naming, there are lots of extra information to wade through and non-devs can easily get confused. The Appsettings that has existed since v1 is a simpler approach that most people are comfortable with. But you lose a lot of functionality by using AppSettings. The Settings infrastructure brings into play a Settings class with strongly typed properties for the settings and default values for settings that are missing. But sometimes that is overkill or simplicity is just too important.

Read More