Surgical Hotfixes with Binding Redirects
The Problem
Each hotfix contains updates and bug fixes for each and every assembly included in NetAdvantage for ASP.NET™. This is done for many reasons, but one of the original driving forces was to ensure that all assemblies had the same version number to reduce confusion over dependancies for our customers. Unfortunately, as a side effect of this, many times assemblies are updated during a hotfix for problems which were not affecting you. As with any code change, there is always a chance it will have an unforeseen adverse effect. Why take this risk if you don't have to?
The Solution
Suppose you have found a bug in WebPanel which is contained in Infragistics.WebUI.Misc, and receive a hotfix which corrects the issue. In your project you also have WebGrid, WebTab and WebMenu, but have not found any issues with these controls. Updating any assemblies other than Infragistics.WebUI.Misc means you must retest all other parts of your project, and also increases the possibility for introducing a regression issue. This risk can be mitigated by updating only the assembly which presented the original problem. Ok, so by now you're asking - HOW!? The answer is our friend the web.config file.
Web.config files are extremely powerful, and can be used to 'redirect' the assembly binding to the version of your choice. If you have ever looked at the web.config for the Infragistics samples, you'll notice we include binding redirects for all assemblies. By using a binding redirect you can coerce the runtime to use a later version of a given assembly without even having to recompile your application. Taking our example from above, we need to force the runtime to load updated versions of Infragistics.WebUI.Misc and Infragistics.WebUI.Shared, while retaining the original version of all other Infragistics assemblies. Here's a snippet of code that will accomplish this task. Note, the runtime section of the web.config is a sibling node of system.web
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Infragistics2.WebUI.Shared.v6.2" publicKeyToken="7dd5c3163f2cd0cb"/>
<bindingRedirect oldVersion="6.2.20062.34"
newVersion="6.2.20062.1038"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Infragistics2.WebUI.Misc.v6.2"
publicKeyToken="7dd5c3163f2cd0cb"/>
<bindingRedirect oldVersion="6.2.20062.34"
newVersion="6.2.20062.1038"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
<!--
Redirect the runtime so that it loads the 6.2.20062.1038 hotfix build for the specified assemblies, instead of the original 6.2.20062.34 release build.
-->
Now that you have told the runtime to load these updated assemblies, you have to be sure it can find them. If the assemblies are in the gac already, you are set. If they are not in the GAC, you can place them in the bin directory. Be cautioned that placing assemblies in the bin directory on your development machine may confuse Visual Studio, and is not recommended. On my development machine, I created a secondary folder called "hotfix" where I placed the updated assemblies. Later I installed those assemblies into the GAC by dragging them into the "c:\windows\assembly" folder.
Final Thoughts
In a perfect world, the bug fix to regression issue ratio would give us a divide by zero error. Ok, I know.. bad joke. But whether or not you appreciate my sense of humor, the point is the same. Whether you are proactively limiting your risk exposure or reactively working around a regression issue, binding redirects are your best friend!
If you try this out, add your comments here to let everyone know how it worked. Also, if you find that I missed a step, or you just want to add additional info based on your experience, please add your comments here for everyone to benefit from.