In many cases, we need to have two different set of configuration settings (let say: one for development environment and another one for production environment). What we normally do is to change the setting one by one manually before deploying to production server and change them back again to development. This is very annoying especially when you have many settings.
Web.config transformation is an awesome technique to transform the original web.config into another one with slightly changed of settings.
You could find more detail about how to configure and use it here in common ASP.NET project.
The bad news is the technique is only built-in for web.config for ASP.NET Web Project, not others like Windows Form, Console App, etc.!
The good news is we can do some trick to make it works. The idea is to perform some modifications on its project file as illustrated in this post.
Since SDK 1.5 (if I remember correctly), VS Tools for Windows Azure enables us to select service configuration and build configuration.
Service Configuration is essentially configuration for Windows Azure services. You can have two or more different configurations, let say one for local (ServiceConfiguration.Local.cscfg) and another one for cloud environment (ServiceConfiguration.Cloud.cscfg).
Build configuration is either your web.config (for Web Role) and app.config (for Worker Role). Let say one for debug (Web.Debug.config) and another one for release (Web.Release.config).
For web.config, it certainly works well. Unfortunately, it doesn’t applicable for app.config (Worker Role project) . Although if you try to apply the technique above to your App.config inside your Worker Role, it still won’t work.
That is the reason why I am writing this article .
The idea is utilizing an Visual Studio add-on SlowCheetah – XML Transforms to help us perform xml transformation. This is an awesome tools (not only for Windows Azure project) that can help us add and preview applicable on config. Thanks to JianBo for recommending me this tool!
Let’s see how it will be done …
1. Download and install SlowCheetah – XML Transforms. You might need to restart your Visual Studio after the installation.
2. Prepare your Windows Azure Worker Role project. I named my Windows Azure project: WindowsAzureWorkerConfigDemo and my Worker Role: WorkerRole1.
3. Open the app.config file and add the following value:
<?xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings> <add key="setting1" value="original"/> </appSettings> <system.diagnostics> <trace> <listeners> <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=188.8.131.52,Culture=neutral,PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics"> <filter type="" /> </add> </listeners> </trace> </system.diagnostics> </configuration>
Remember to save the file after adding that value.
4. Right-click on app.config and select Add Transform. (This Add Transform menu will only appear if you’ve successfully install the SlowCheetah). If Visual Studio prompts you for Add Transform Project Import, click on Yes to proceed.
5. You will then see there are children file (app.Debug.config and app.Release.config) below your app.config.
6. Double-click on the app.Release.config and add the following snippet:
<?xml version="1.0" encoding="utf-8" ?> <!-- For more information on using transformations see the web.config examples at http://go.microsoft.com/fwlink/?LinkId=214134. --> <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> <appSettings> <add key="setting1" value="new value" xdt:Transform="SetAttributes" xdt:Locator="Match(key)" /> </appSettings> </configuration>
As you could see, I’ve change the value of setting1 into “new value”.
The “xdt:Transform=SetAttributes” indicates that the action that will be perform. In this case, it sets the attribute of the entry.
The “xdt:Locator=”Match(key)” indicates the condition when it will be perform. In this case, when the “key” is matched.
You can refer to this post to see what are the other possible values for xdt:Transform and xdt:Locator.
Remember to save the file after adding the settings.
7. Now, right-click on the app.Release.config and click on Preview Transform. (Again: it will be only appeared if SlowCheetah is properly installed).
8. Now, you can see the comparison between the original app.config and app.Release.config.
9. Right-click your Windows Azure project and click “Unload Project”. Right-click on it again and select Edit [your Windows Azure project].ccproj file.
10. Scroll down to the end of the file and add the following snippet before the closing tag of project.
<Import Project="$(CloudExtensionsDir)Microsoft.WindowsAzure.targets" /> <Target Name="CopyWorkerRoleConfigurations" BeforeTargets="AfterPackageComputeService"> <Copy SourceFiles="..WorkerRole1bin$(Configuration)WorkerRole1.dll.config" DestinationFolder="$(IntermediateOutputPath)WorkerRole1" OverwriteReadOnlyFiles="true" /> </Target> </Project>
What it does is basically performing a task each time before packaging the Windows Azure service. The task is to copy the WorkerRole1.dll.config file to the IntermediateOutputPath.
Save and close the file. Right-click and select Reload Project again on the Windows Azure project.
11. Alright, we should package it now and see if it really works. To do that, right-click on Windows Azure project and select Package. Choose Release for the build configuration. Click on Package to package the file.
When Release is selected, we expect the value of “setting1” would be “new value” as we set inside the app.Release.config.
As the service is successfully packaged, you can see two files as usual (one is ServiceConfiguration.Cloud.cscfg and another one is WindowsAzureWorkerConfigDemo.cspkg).
To verify the correct configuration is included, change the extension of the cspkg file into .zip and unzip it. Inside the directory, look for the biggest size file (start with WorkerRole1, since I name my Worker Role project “WorkerRole1”).
Change its extension to .zip and unzip it again. Navigate inside that directory and look for “approot” directory. You could see the WorkerRole1.dll.config file inside.
13. Open that file and check out if it’s the correct value, set in our “release” build.
Mine is correct, how about yours?