A Real Head-Scratcher Courtesy The CLR and Office Teams
February 7th, 2006
“Why the hell is this application insisting on loading an old version of the CLR?” I’m guessing that’s what you’re asking yourself if you’ve gotten here through your search engine of choice. Well, relax. I’m about to explain.
It is reasonably well-known that there are .config file settings that can force an application to load a specific CLR version. It is also possible to write unmanaged code using the hosting API’s like CorBindToRuntimeEx to bind to a specific version. I’m not talking about either of these scenarios.
There is a set of undocumented (as far as I know) registry keys that can override either of these vectors. They are located here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\AppPatch\v2.0.50727.00000
If you take a look at this key on your own machine, you’ll probably see a handful of applications listed.
Applications can specify a target version of the framework that will be loaded into the process, even if there is no .config file present, and even if you write some C++ to call CorBindToCurrentRuntime. Mscoree will simply report that the current runtime is 1.1.4322, even if the user has 2.0 installed on their machine. This is, I suppose, superfically similar to the strategy used in the Image File Execution Options built into NT.
I can see where this would be handy—presumably Microsoft has a handful of .NET 1.1 apps in the wild that showed bugs against 2.0, and it’s not exactly practical or foolproof to try to drop a .config file on those apps when installing the framework (naturally, somebody can just install the application after the framework, then be puzzled as to why it isn’t working).
Good solution, right? It’s a shame they fouled it up.
Notice that Word and Excel are both listed as special applications on my machine. I have these values on my laptop:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\ AppPatch\v2.0.50727.00000\excel.exe\{2CCAA9FE-6884-4AF2-99DD-5217B94115DF}] "Minimum File Version Number"="11.0.0.0"
"Maximum File Version Number"="11.0.9999.9999"
"Target Version"="v1.1.4322"
It appears as though the someone is trying to force a relatively older build of Excel/Word 2003 to load v1.1. Fair enough, the Excel build on my machine is up to 11.6 at this point. Unfortunately, those developers failed miserably in the attempt. Every single other application listed under AppPatch in my registry looks like this:
"Minimum File Version"="11.0.0.0"
"Maximum File Version"="11.0.9999.9999"
"Target Version"="v1.1.4322"
When the version filter isn’t specified (or actually in this case, miswritten as “Minimum/Maximum File Version Number” instead of “Minimum/Maximum File Version”), all versions of the executable will load the target version. So these keys effectively break 2.0 addins for all versions of Word and Excel.
There is an update available that fixes this issue, here. The KB article that accompanies it doesn’t really explain what the issue is, which is why I’ve summarized it here. Office update is not exactly an automatic affair like its Windows counterpart, so this bug makes it essentially impossible to write a fault-free Office addin that targets 2.0 and does not hack up the user’s registry upon installation. I can’t say I advocate doing that, but I would understand if you did. As for myself, I am most likely going to target 1.1 much longer than I had hoped would be necessary.
