Transforming web.config in TFS builds

XDT transforms (mostly known as web.config transformations) are most useful to perform transformations on your web.config at deploy time (for more details about web.config transformations you can take a peek at http://msdn.microsoft.com/en-us/library/dd465326.aspx). Say that you’re publishing a web application in the project configuration “Release”. If you have a “web.Release.config” file in your application, that file contains the transformation to be applied over the web.config. However, if you are using TFS builds to create the deployable outputs, you might find yourself in unexplored territory, because your XDT’s will not be ran as when you explicitly publish from within Visual Studio.
Microsoft might have inadvertedly shed some light on this subject, as they have recently made available a prerelease of an API to perform these XDT transformations which is available through NuGet here:  https://nuget.org/packages/Microsoft.Web.Xdt.
Knowing this, I’ve decided to explore this new API and put it to good use. I've created a CodeActivity to use this API and integrate the XDT transformations in my build process. Another alternative (I was previously using) is to rely on an external tool to do the transformations for you and invoke that tool from within your build process (see the Config Transformation Tool here: http://ctt.codeplex.com ).

So here’s a code activity to do just that: run XDT on your web.config depending on the project configuration being built:

Premature optimization

First of all, happy New Year!
Now, on the first post of the year, I would like to quote the great Donald Knuth: "We should forget about small efficiencies, say, about 97% of the time: Premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified."

I've been defending this for a long time, but I keep stumbling upon developers that disregard this rule of thumb. When faced with performance issues most tend to use an empirical approach: read the source code and attempt to make informed guesses on what may be the critical code. Most forget about code profilers that can accurately identify the critical code. I believe this is not only their fault, but also a fault of the education system, that failed to instruct and emphasize on the relevance of such tools.

Here's another quote (from Continuous Delivery): "Don't guess; measure". My experience tells me, that, most of the times, our informed guesses are not the main culprit of our performance issues. So, the best approach is to clearly identify the culprits and deal with them. What's the point in spending time solving an issue when there's another issued that on itself may represent a 50% improvement? We rarely have the time to perfect our code until we deem it as good and fast as we'ld like, so in such situations a programmer should be pragmatic (which I believe to be one of the most relevant qualities in programmers. By the way, if you haven't read The Pragmatic Programmer yet, it's time to start thinking about it).

Happy coding in 2013!