Externalizing Assembly Redirects

> 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." 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.

---

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 ( ) is excluded from the configuration. Additionally, we are using a node, which points to an absolute file path reference in the site directory.

1 2 3

<assemblybinding xmlns="urn:schemas-microsoft-com:asm.v1"> ?<linkedConfiguration href="file://D:\home\site\wwwroot\App_Config\RuntimeSettings.config" /> assemblybinding>

The external file itself also look a little different than what might be expected:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

xml version="1.0"?> <configuration> ?<runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> ?<assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35"/> ?<bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0"/> dependentAssembly> <dependentAssembly> ?<assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35"/> ?<bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0"/> dependentAssembly> <dependentAssembly> ?<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35"/> ?<bindingRedirect oldVersion="1.0.0.0-5.2.3.0" newVersion="5.2.3.0"/> dependentAssembly> assemblyBinding> ?runTime> configuration>

In the external file, we have re-added the node and replicated the normal assembly binding config structure thereafter. This particular file can now be added and maintained in source control, so that you can ensure that all redirects move through the environments with their correlated changes. More details on the node can be found here. You can note the base web.config configuration was pulled from here. The tricky part was figuring out the proper file structure for the external file, as well as the file path needed to get to that external file.

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.

Happy Coding!