I've read extensively about the backwards-compatibility of .NET versions, and that there are but a few breaks between the versions. After our major migration of several hundred thousand lines of code over 26 projects from 1.1 to 2.0, I’d have to say for the most part that is true.
However, there is definitely some sort of issue with referencing assemblies compiled to the older versions. Particularly 3rd party components, many of which we don’t have the ability to re-compile with our solution.
All of our 3rd party components are strongly named and live in the GAC with the rest of our assemblies. Everything is versioned, and most are referenced by name in the web.configs.
At seemingly random intervals, *some* of the 3rd party components, all of which were compiled against 1.0 and 1.1, on one out of many sites that reside in a shared app pool, will throw the following exception:
System.IO.FileLoadException: The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
The ONLY thing that will make this error go away for this site is recycling the entire app pool. Touching the web.config for the site doesn’t work. Moving the site to another app pool, recycling it, and moving it back does not work. Only recycling the original app pool will do the trick.
Note that absolutely no change to any of the sites or assemblies referenced explicitly by the code and config files has been made to cause this issue, and it only tends to happen with one site (sometimes out of 100) in an app pool at a time.
Looking at the Fusion logs doesn’t show much. My postings to the MSDN newsgroups elicited a lot of the common issues and questions, all of which have been ruled out for weeks.
As we are able to replace each of these older component with 2.0 versions, loading those components no longer throw the exception. We have about 3 remaining components that there seem to be no 2.0 versions of available, but the majority have been replaced.
UPDATE & RESOLUTION TO THIS ISSUE (posted 5/21/2007)
After much deliberation, we found that due to ASP.NET 2.0’s new abililty to share assemblies across app domains, when we re-added the 3rd party components to the GAC in our usual rollout, even though they were identical to the existing versions on the servers, it caused their complied images to become invalid. However, since the version numbers are the same, ASP.NET does not JIT re-compile the assemblies. This causes the assembly manifest definition to become invalid. The errors were still very random, which didn't make much sense at all. Go figure! J
Slower initial compile times with 2.0
A side issue we found was the initial startup time of these 1.1 and 1.0 assemblies after a site update was incredibly long, sometimes 60 seconds each or more for the assemblies to be loaded the first time.
So, the only thing we can suggest for others in this situation is that 1.0 and 1.1 assemblies cannot be counted on to run quickly under the 2.0 framework, at least when referenced from 2.0 code.
About the Author
Stefan Barlow is a DevOps Practice Manager at Amazon AWS and was previously the CTO and Co-Founder of AmeriCommerce.
More Awesome Content
Get tips and resources for selling delivered directly to your inbox.