Recently, a co-worker pinged me asking about the best way to handle transforms in a Sitecore 9+ PaaS environment. My response: "Transforms are the devil, and there are often zero reasons why you need them in a new Sitecore environment."
Sitecore, of course, gives us rules-based configurations out of the box. These give us a lot of control over applying different configurations for different roles and environments, but what about modifications to the web.config? In my experience, most changes to the web.config are "one-time" changes that you can make (and document) as soon as an environment is provisioned. This includes managing assembly binding redirects, which is often something that changes each time you add a new NuGet reference to your project. Most developers are already aware of the mechanism which can be used to externalize App Settings and Connection Strings. A similar process can be used for assembly binding redirects, although comparatively it is a little quirky.
First thing, we need to modify the web.config to know that its redirects are in a separate file. The below screenshot shows a before and after of the web.config with this modification.
For the most part, this is congruent with a normal config externalization. The key difference is that the original parent node (
The external file itself also look a little different than what might be expected:
Last but not least is documentation to ensure that it is known that these steps need to be taken when provisioning a new environment, both local and non-local. I like to include a blurb in the ReadMe for my source control repository:
I am definitely not a fan of transforms, and this is just one of the little things that makes them that much less required in a project. It is a pretty straight-forward and simple change, but can eliminate a fair amount of headache when having to manage redirects across multiple branches and environments, which are all dependent on the packages currently installed at the time.