Hiding XDT Transforms from Sitecore

Sitecore ships with a very useful web.config patching feature that allows everything within the element in the configuration file to be modified and extended. It is a best practice recommendation not to modify the web.config file directly but instead use customised configuration files located within the App_Config\Include folder to overlay the modifications that your solution requires.

Rather that regurgitate information on how to use the web.config patching mechanism I’ll suggest instead that you start with John West’s post All About web.config Include Files with the Sitecore ASP.NET CMS for a definitive way into this subject.

web.config transform files

Developers working with ASP.NET web applications outside of the Sitecore ecosystem are likely to be performing their web.config transformations using Microsoft’s XDT transform syntax. The popularity of the XDT engine is such that it has recently be issued as a NuGet package so that it can be shipped with third-party products. Whilst on the subject of XDT transforms it would be worth pointing out the Slow Cheetah Visual Studio extension for those new to the area. This package enables you to transform your web.config or any other XML file based on the build configuration and preview the outcome – simply invaluable.

Advertisement

Testing Strategies – Opinionated Advice

As developers we routinely work with code that is not our own, commonly in the form of third party APIs and application frameworks. This post discusses the scenario that almost every developer is likely to encounter at some stage in their career, namely what to do when you have to work with an API or framework dependency that makes unit testing seem impossible.

Faced with the prospect of developing code against a framework that doesn’t easily lend itself to unit testing you generally have a number of options.

The first and obvious choice for some is to abandon the idea of unit testing for part or all of the code that you have written. The reasoning here is, why the hell should I bother to test my code if the framework code lacks the same rigour. After all it’s not your fault, you can always blame the framework developers for painting you into this corner. This attitude is not exactly going to guarantee you a place amongst the great and good of Software Craftsmanship. The facts are that you, as a software professional, are responsible for verifying the code that you write. It is you who will ultimately have to support the code you write when it gets to production, giving you a great motivation to ensure that it functions correctly.