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

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.

Web Config Before and After

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:

Documentation

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!

SEARCH ARTICLES

CATEGORIES

Sitecore 144
Commerce 100
Web Development 100
Sitecore Commerce 83
Sitecore Experience Commerce 9 64
Sitecore Experience Commerce 59
Content Management 55
eCommerce 48
B2B eCommerce 42
Sitecore Experience Platform 39
Sitecore Platinum Partner 39
Architecture 34
Insite 29
User Experience 26
Strategy 22
B2C eCommerce 21
B2B Commerce Blogs 21
commerceconnect 21
CloudCraze 20
SaaS (Software as a Service) 20
Cloud 17
Commerce Server 17
Salesforce B2B Commerce Cloud 16
Mobile 13
Search 13
Plugins 12
Analytics 12
Application Development 12
Digital Transformation 11
Sitecore Symposium 11
SPEAK 10
Helix 10
DMS 8
Social 8
Business Process 7
Authentication 7
5 Reasons 7
BI and Big Data 6
Data Visualization 6
Sitecore Presentation 6
Coveo 6
NET Development 5
Microsoft Azure 5
Automation 5
Front-End Development 4
SaaS (Software as a Service) 4
Digital Strategy 4
Brightcove 4
Press Release 4
Avalara Tax 3
Sitecore Experience Accelerator (SXA) 3
Sitecore Layouts 3
Video 3
SPE 3
Multi-site 3
Multi-lingual 3
Accessibility 3
Habitat 3
Vault 3
Identity 2
Managed Services 2
CDN 2
SMB 2
Cryptocurrency 2
Sitecore Forms 2
Sitecore Experience Commerce 9 Promotions 2
Uncategorized 2
EXM 2
Conversational Commerce 2
Sitecore SaaS 2
Security 2
Unit Testing 2
Headless Architecture 2
Sitecore Experience Awards 2
Google 1
Content Delivery Network 1
Configure Price Quote 1
CPQ 1
Blockchain 1
Coupons 1
Sitecore Rss 1
Artificial Intelligence 1
Machine Learning 1
Okta 1
RFP Process 1
NoSQL 1
Flex Accelerator for Sitecore 1
Reviews 1
SEO 1
Page Labels 1