Code Obsession

I recently posted about how to use a custom MSBuild file to run web.config transforms in your continuous integration process. This is the methods we have used on a couple of my previous teams. At Pluralsight , we use a different method. We do our 1-Click deploys through a custom web application that takes the output of our TeamCity builds as it's input. As we built our deploy tool, we chose to avoid calling shell processes. This meant finding an alternative to the MSBuild file for web.config transforms. What we came up with is the following. using System.IO; using Microsoft.Web.Publishing.Tasks; namespace SiteDeploy.SiteConfiguration { public interface IConfigFileGenerator { void TransformWebConfig(string environmentName, DirectoryInfo sourceDirectory, DirectoryInfo targetDirectory); } public class ConfigFileGenerator : IConfigFileGenerator { const string webConfigFileName = @"web.config"; public void TransformWebConfig(string environmentNam...

TL;DR It doesn't matter what process you follow, the people involved will cause the success or failure of a project. In the beginning, there was chaos. Developer were making software, but business couldn't really manage it. Then came waterfall. This was nice because it was easy to manage. And luckily, we now had computers to manage the schedules, because they were always slipping. When it was realized that developers are virtually incapable of estimating how long it takes to do anything longer than a few months (or more often days), clever managers came up with a solution: shorten the cycle! It was called the spiral method, and it is an iterative waterfall. Sure the schedules still slipped, but they didn't slip as much because the iterations were shorter. Thus was the Spiral method born. While the managers were trying to fix waterfall (because they loved it's predictability) other smart people were trying other ways to solve these problems and learning from ...

In my last post, I showed how web.config transforms can be used to manage the complexity of config files in an ASP.NET project. One thing that often comes up in mature environments is that certain parts of the web.config are need to know only. Examples include production database passwords, payment gateway authentication keys, etc. Of course, this isn't restricted to production environments, but is most common there. Fortunately, there is a solution to this built right into the ASP.NET engine: Encrypted Config Sections. Once the sensitive sections of the web.config transform files have been encrypted, the files can be added to source control and tracked just like any other file in the project without fear that the sensitive data will be mishandled in any way. In order to encrypt the files, access to the production web server is required. All the following steps must be performed in an elevated (run as administrator) command prompt or they will fail with no useful exception info...

One of the nice features that has been around for a while in .NET is web.config transforms. If you are unfamiliar, these config transforms allow you to create a base config file and then use transform files which only contain the differences between different deployment environments. Here is an example of a very simple web.config: <?xml version="1.0" encoding="utf-8"?> <configuration> <appSettings> <add key="WebTransform" value="Raw/Dev"/> ... </appSettings> </configuration> And here is the web.QA.config transform file that would update the key when deployed into the QA environment: <?xml version="1.0" encoding="utf-8"?> <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> <appSettings> <add key="WebTransform" value="QA" xdt:Locator="Match(key)" xdt:Transform="Replace" /> ...