M
Mat P:son
NB!
This is a cross-post. Yes, I admit I'm evil. The original post was submitted
to dotnet.framework.clr, but it's probably not the best place for it.
Yes, I will listen for replies on both messages, and yes, I will make an
effort to keep both treads up-to-date, to make sure the people kind enough to
answer are not wasting their energy.
Anyway, here's the original question:
============================================
Hi there,
This question is touching quite a few different areas (.NET 2.0, CLR,
Deployment, and indeed Excel) but I post it here as a first attempt to see if
someone's got a few pieces of info for me...
Anyhow, here's the story: Among other things, I'm involved in putting
together an XLA add-in for Excel (supporting Office platforms 2000/XP/2003 on
Windows 2000/XP). The add-in uses VBA as glue code, and the core
functionality is provided by stand-alone DLL:s. Now we're planning to
integrate some .NET 2.0 assemlies into the product, and this currently gives
us some headache with the CLR.
It seems as if Excel refuses to load CLR for .NET 2.0, and instead reverts
back to v1.1. In fact, it turns out that the reason for this behaviour is the
presence of some registry settings that control this "fall-back behaviour",
please see the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
.NETFramework\policy\AppPatch\v2.0.50727.00000
These keys inhibit the use of v2.0 for the applications specified, and for
example v1.1 will used instead. Unfortunately, we need .NET 2.0.
Microsoft obviously added Excel to the "v1.1-Only List" for a good reason.
However, there is now a patch available that is supposed to address the
problem, and there's a redist file for VS2005 as well (c.f., KB907417 and
KB908002, respectively -- as far as I know, these patches are supposed to fix
the OTKLoadr).
However, the KB907417 patch will only fix the problem on Excel 2003, while
the 2.0-inhibition affects *all* Office platforms. FYI: This is due to the
fact that MS botched it when they added the reg keys in the first place,
please visit the following link for an interesting discussion about the
issue:
http://mcfunley.com/cs/blogs/dan/archive/2006/02/07/947.aspx
From one point of view, the flawed reg keys were only supposed to force
Excel 2003 to fall back to .NET 1.1, so Excel 2000 shouldn't be part of the
problem. Hence, it would be an easy thing for me to go in and hack the
registry. But since I do not know exactly what the MS patch does (apart from
hacking the registry and fixing the OTKLoadr, presumably) I'm not so sure it
would be a wise thing to do, and I can think of quite a few reasons when such
a scheme would fail. I can make things work fine on my developer machine but
that's obviously not the same thing as making it work on all supported
platforms, always, and for different languages.
Does anyone have additional information on this issue? Is there actually
other patches out there that I've completely missed? Has Microsoft confirmed
that we can simply hack the registry (without additional action required)?
Cheers,
/Mat
This is a cross-post. Yes, I admit I'm evil. The original post was submitted
to dotnet.framework.clr, but it's probably not the best place for it.
Yes, I will listen for replies on both messages, and yes, I will make an
effort to keep both treads up-to-date, to make sure the people kind enough to
answer are not wasting their energy.
Anyway, here's the original question:
============================================
Hi there,
This question is touching quite a few different areas (.NET 2.0, CLR,
Deployment, and indeed Excel) but I post it here as a first attempt to see if
someone's got a few pieces of info for me...
Anyhow, here's the story: Among other things, I'm involved in putting
together an XLA add-in for Excel (supporting Office platforms 2000/XP/2003 on
Windows 2000/XP). The add-in uses VBA as glue code, and the core
functionality is provided by stand-alone DLL:s. Now we're planning to
integrate some .NET 2.0 assemlies into the product, and this currently gives
us some headache with the CLR.
It seems as if Excel refuses to load CLR for .NET 2.0, and instead reverts
back to v1.1. In fact, it turns out that the reason for this behaviour is the
presence of some registry settings that control this "fall-back behaviour",
please see the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
.NETFramework\policy\AppPatch\v2.0.50727.00000
These keys inhibit the use of v2.0 for the applications specified, and for
example v1.1 will used instead. Unfortunately, we need .NET 2.0.
Microsoft obviously added Excel to the "v1.1-Only List" for a good reason.
However, there is now a patch available that is supposed to address the
problem, and there's a redist file for VS2005 as well (c.f., KB907417 and
KB908002, respectively -- as far as I know, these patches are supposed to fix
the OTKLoadr).
However, the KB907417 patch will only fix the problem on Excel 2003, while
the 2.0-inhibition affects *all* Office platforms. FYI: This is due to the
fact that MS botched it when they added the reg keys in the first place,
please visit the following link for an interesting discussion about the
issue:
http://mcfunley.com/cs/blogs/dan/archive/2006/02/07/947.aspx
From one point of view, the flawed reg keys were only supposed to force
Excel 2003 to fall back to .NET 1.1, so Excel 2000 shouldn't be part of the
problem. Hence, it would be an easy thing for me to go in and hack the
registry. But since I do not know exactly what the MS patch does (apart from
hacking the registry and fixing the OTKLoadr, presumably) I'm not so sure it
would be a wise thing to do, and I can think of quite a few reasons when such
a scheme would fail. I can make things work fine on my developer machine but
that's obviously not the same thing as making it work on all supported
platforms, always, and for different languages.
Does anyone have additional information on this issue? Is there actually
other patches out there that I've completely missed? Has Microsoft confirmed
that we can simply hack the registry (without additional action required)?
Cheers,
/Mat