"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.
Tags: .NET, Angry, Excel, Financial Industry
This entry was posted
on Tuesday, February 7th, 2006 at 6:20 pm and is filed under .NET, Microsoft Technology.
You can follow any responses to this entry through the feed 
.
You can leave a response, or trackback from your own site.
I couldn’t have figured this out without regmon from sysinternals - get it here: http://www.sysinternals.com/utilities/regmon.html
Thanks, Dan for the excelent blog entry, I will have a look at your other blog entries.
Has someone actually downloaded and installed the The KB908002 patch? Can they tell if the misspelled entries in the registry mentioned by Dan are fixed?
The question I am asking is that it seems that my computer already has the reg entries found in the MSI files, and that does not seem to fix my problem using a .NET assembly in an Excel 9 process. The only resolution I can see is to actually modify this entries when I deploy my assembly, that works for me.
Good article — it’s always nice to know what is the root cause of a problem, and not just that “This update fixes a problem that may prevent managed add-ins, [...] from working in Office 2003″
However, I don’t quite see how the patch mentioned (c.f., KB907417) solves the problem on platforms other than Office 2003 since it simply refuses to run if Off2K3 is not installed. The bug also affects Excel 2000, for which there is no such patch, right? And I’m not entirely sure what the VS2005 OTKLoadr-patch available on the KB908002 page can do to help Excel 2000 either.
Hence, is my only option to solve the problem for Excel 2000 to go in and patch the Windows Registry during installation of my add-in? That sounds a bit hacky, really, and I can think of quite a few situations during which such an approach would be likely to fail.
I think you’re correct, and I’ve not found a supported way to fix CLR 2.0 for Office 2000 and XP. (Maybe this has something to do with the ad campaign where they call the people still using those versions dinosaurs.)
The patch they supply for 2003 seems to do a few other things, so I’ve come to the conclusion that I don’t have all of the information and can’t just hack the registry for my addin. Presumably there’s some issue out there that they were trying to fix in the first place.
What that means for me is that I’m stuck targeting 1.1 until I can drop support for 2000/XP. For me, that is almost definitely a period of several years.
I also have to deploy 1.1. I’d be just as happy to help Microsoft out here by redistributing the most recent CLR, but unfortunately it’s not an option.
Hi there again Dan,
Presumably, since the reg keys were only intended to address certain short-comings of Excel v11 (2003) and affected all Excel platforms simply due to a deployment bug in .NET v2.0, we should be safe patching the reg keys if indeed an installer (a) detects that the reg keys are there, and (b) that they are still buggy, ie, haven’t been fixed by some recently applied patch.
It Should Just Work(tm)
But on the other hand, who knows…? It would be good if MS released an updated version of the KB907417 patch that would work for all Office platforms (they obviously don’t need to fix the OTKLoadr for Excel 2000 since it doesn’t exist, but at least they could take care of the screwed up reg keys). Maybe there is a new patch out there already, but I haven’t found any.
This morning, I posted my question to the MSDN newsgroups, so we’ll see if anyone out there knows the answer. If not then I guess I have to prod MS as well…
Hi there again Dan,
After a lot of searching and quite a few new gray hairs, I’ve finally found what I was looking for. Interestingly, I got absolutely no response on the MSDN Newsgroups, but eventually stumbled on some useful info on the MSDN Forums.
The KB908002 patch for VS2005 seems to give us everything that’s necesary to properly address the Excel/.NET 2.0 compatibility issue. Is contains two MSI and one EXE that must be run as part of your installer.
(However, note that you’ll probably want to distribute some kind of bootstrapper executable/batchscript, and not just a single file.)
More info in the following MSDN Forum posts:
1) http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=498768&SiteID=1
2) http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=498815&SiteID=1
3) http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=185159&SiteID=1
The replies to post (1) misses the point a little bit (versions other than Excel 2003 are NOT fixed). Answers to (2) discuss and solve the issue, but does not take non-VS2005 installers into consideration. Finally, post (3) is very comprehensive, and tells us pretty much all there is to say, I think.
Thanks very much for the info. I’m so far along in my development cycle that I doubt I’ll switch from 1.1 at this point, but this should be very helpful in the future.