COM Shim CLR Loader Bug

re: COM Shim CLR Loader Bug

Tony Gravagno — Tue, 27 Nov 2007 04:13:03 GMT

Andrew, I'll have a look at my code which was generated by the v2.3 wizard. Maybe the issue documented here is causing some of my grief. I'm one of the many people who try to create a managed automation add-in for Excel - we get all the way to deployment to a test box and then can't get the code work. I've blogged my experience for anyone who cares to read - it includes a complete walk through for anyone who wants to use managed code behind Excel formulas via a shim. Might you be able to provide some of your well respected wisdom to assist?

remove.munge.pleaseNebula-RnD.com/blog

(Part 1 introduces concepts and has a lot of links. Parts 2-4 are intermediate notes of frustration with more reference links. Part 5 is the summary and tutorial.)

Thanks for any tips. As you'll note from my many references to you on my blog, I sincerely appreciate your public postings on this topic.

re: COM Shim CLR Loader Bug

Tony Gravagno — Sat, 29 Dec 2007 03:47:16 GMT

I've incorporated the fix according to this article. I know the shim code is being invoked on a deployment system, but I still can't get the shim to call my managed Excel UDF. The problem is that the proper registry keys are not being generated, either via the COM Shim Wizard or from the Setup Project. Complete details are in my own blog - get there from the unmunged link associated with this comment.

re: COM Shim CLR Loader Bug

Steve D. — Tue, 18 Nov 2008 13:57:42 GMT

We experienced a problem with our COM Shim created by the Wizard - the call to CorBindToRuntimeEx was failing with error 0x80131700. We found that specifying the version as the 1st parameter to the call resolved the issue.

re: COM Shim CLR Loader Bug

andreww — Tue, 18 Nov 2008 21:50:54 GMT

Steve - specifying the CLR version to load in CorBindToRuntimeEx is generally a BAD thing to do. The generated shim code specifies null for this parameter, which by default causes the latest version of the CLR to get loaded. Up to CLR 2.0 (and .NET Fx 3.5), the CLR has a very high level of backwards compatibility. This means that loading the latest CLR is almost always the right thing to do (that's why it's the default). Loading an earlier CLR will almost certainly break any add-ins, smart tags, or other managed components that have a dependency on a later CLR.

I strongly advise you to debug your solution environment to find out why CorBindToRuntimeEx was failing in the first place. The most likely reason is that some other version of the CLR has already been loaded in the process. Typically this would be done by some component calling CorBindToRuntimeEx with a specific CLR version (ie, exactly the approach you've discovered), or via an Exe config.

re: COM Shim CLR Loader Bug

Mehul — Tue, 02 Dec 2008 13:23:08 GMT

Does this CLR loading problem, would cause any issue on deployment machine, or it is only development machine specific issue

re: COM Shim CLR Loader Bug

andreww — Tue, 02 Dec 2008 21:57:22 GMT

Mehul - as I explained, the problem was in the code that was generated by the wizard, which will run on both the dev machine and the end-user's machine.

Note that this problem has been fixed in the latest version of the wizard, described here: http://msdn.microsoft.com/en-us/library/bb508939.aspx