Thursday, July 5, 2012

Transforms for *.config Files, Part 2: New Config Profiles

Part 1 of this series focused on how to use the default transform profiles and having those profiles applied when you BUILD you application instead of the default time when you PUBLISH your application.  Part 2 of this series will discuss adding NEW configuration profiles.

Remember, the default configuration profiles created when you build your project are “Debug and Release” and can be seen on the menu bar:
image

And the transform files can be seen under Web.config in the Solution Explorer:
image

If we are working with a team and we have multiple deployment (publish) environments (QA – PROD), then we may use the Debug for the QA environment and the Release for the PROD environment.  But I submit that you probably want to re-name your transforms to match the environment they belong to (rename Debug to QA and Release to PROD, etc.)  But for this blog, I want to make a new configuration for my local machine which I will call: JDRLocal (Not just Local because other developers on the team may want to create their OWN configurations that are different than mine – for instance, I am going to point the database to MY local database server).

Create the new Configuration
The last option on the drop-down is “Configuration Manager …”, Select this option and the Configuration Manager will be displayed. On the “Active solution configuration”, there is a drop down that shows you the solution configuration that you already have and an option for New and Edit.  Select the New option:
image

A “New Solution Configuration” dialog box appears.  Type in the name of your new configuration, you can get a head start on the configuration options by selecting an existing configuration settings.  By default, the “Create new project configurations” is set.  Now press “OK” to create the new configuration:
image

Now our new solution configuration was created.  But it’s important to understand that not only was a solution configuration created, but for each project in our solution, a new configuration with the same name was created.  In this example, we only see 1 project, but if we have 6 projects, they would be listed on this screen and each project would have the new configuration “JDRLocal” created for it.  Now close this window.
image

Where is the Transform?
So now, if we look at the drop-down on the menu bar, we can see our new configuration:
image

But the main reason for creating this configuration was so that we could make a transform file for it.  But if you look in the Solution Explorer, you will see that there is still just the Debug and Release Web.*.config files.  How do we get our new transform: Web.JDRLocal.config?

Now that we created the new configuration, there is an option on the Web.config context menu.  RtClick on Web.config and you will see an option to “Add Config Transforms”.  Select this option:
image

Magically, you will see the new transform (Web.JDRLocal.config) appear:
image

You can now modify this transform file to modify your Web.BASE.Config and create a new Web.Config based on your setting for JDRLocal.  When you select this configuration and select “Build” or “Run”, based on the changes from Part 1 of this series, the transforms will be applied and the newly created Web.config will be in effect when you run the program.

How to UNDO a Configuration!
Let’s say you want to remove one of these configurations.  That should be easy, right?  I mean creating the configuration was easy enough, why should the delete be any harder?  Well, it is slightly harder.  If you recall, I mentioned earlier in the Create portion of this posting that not only does the create routine make a solution configuration, but it also makes a project configuration for each project in your solution.  This is important to understand.  Because, while creating a solution configuration automatically creates project configurations, deleting a solution configuration does not automatically remove the project configurations.

To delete the solution configuration, from the configuration drop-down on the menu, select “Configuration Manager …” again and choose “Edit”:
image

In the “Edit Solution Configurations” dialog box, select the configuration you wish to delete and click the “Remove” button.  The configuration is removed from the list, now select “Close”.
image

At this point, you would think that the configuration has been removed completely.  If you look at the drop-down on the Configuration Manager screen, you will see that the configuration has been removed. 
image

However, if you look at the configuration drop-down for each of the Projects in your solution, you will find that the configuration still exists for each project!
image

For each of the projects in your solution, you must select “Edit” from the drop-down list.  You will get an “Edit Project Configurations” dialog box very similar to the “Edit Solution Configurations” dialog box.  You must select the configuration from the list and click “Remove” for each of your project in order to completely remove the configuration from your solution and all project in the solution.

In Part 3 of this blog series, we will discuss how we can apply transforms to other configuration files – not just Web.config.

Transforms for ANY .config file: 5 Part Series
Part 1: Transforms on Build
This first part does an overview of the default behavior of transforms. It then shows how you can plug into the MSBuild process and apply your transforms at Build time rather than the default publish time.

Part 2: New Config Profiles
The second part of the series shows how to create a new solution configuration and the nuances of what happens behind the scenes (in case you want to delete a configuration). It also discusses having a local development configuration specific to an individual developer.

Part 3: Other Config Files
The third part discusses how to add a configuration for another element of the application (using log4net as an example). This post shows how this process differs from the handling of Web.config.

Part 4: Making the transforms look nice
This fourth part is just a quickie to show how you can manually make your other configuration files sit under their respective parent files.

Part 5: SlowCheetah & Advanced
This fifth and final post is where I try to bring together all of the elements from the previous posts together and introduce a Visual Studio extension that allows much of the previous posts to be accomplished easily and automatically.

No comments:

Post a Comment