Why not to use Visual Studio 2003 (.NET Framework 1.1) for developing Office extensions
We insist on not using .NET Framework 1.1. Why? Because there is a high probability that an Office extension developed with this .NET Framework version will break down other Office extensions developed in higher .NET Framework versions.
Why does this happen? There are three reasons:
- .NET Framework 1.1 and 2.0 are incompatible in the general case (see Breaking Changes between .NET Framework 1.1 and 2.0). Hope you know that .NET Framework 3.0 and 3.5 are just extensions of .NET Framework 2.0.
- Only one .NET Framework version can be loaded into a Windows process.
- You cannot influence the order in which Office extensions are loaded.
Let’s see how this may end with a disaster on the target PC where several .NET based add-ins may be installed, including those based on the Shared Add-in template in Visual Studio, VSTO, Add-in Express or developed with other tools. Let’s talk about just two Office extensions created for the same Office applications. We will refer the extensions as extension #1 and extension #2, the first one is loaded first.
- If extension #1 is developed in VS 2003, this will get .NET Framework 1.1 to load into the Widows process of the host application. When extension #2 is being loaded, it will have to use .NET Framework 1.1, too. If extension #2 requires .NET Framework 3.0 or 3.5, it will crash [almost] immediately. If extension #2 uses .NET Framework 2.0, there’s a pretty good chance that it uses a feature listed in Breaking Changes between .NET Framework 1.1 and 2.0 and this will end with a crash, too. There’s a chance that they will work together, but in the general case, they will not.
- If extension #1 is developed on .NET Framework 2.0, 3.0, or 3.5, then extension #2 developed in VS 2003 will have to use the same .NET Framework version. The chance that they will live together is greater than in the first scenario, but will you rely on that chance?
The first scenario is quite a common thing; for example, see Error when loading VSTO add-in on our forum. Note that Daniel uses Assembly Binding Log Viewer (Fuslogvw.exe). Add-in Express for Office and .NET provides a log file of its own. In the log file, you can see what .NET Framework version is required by your add-in and what .NET Framework version is actually used.
We haven’t been reported about the second scenario yet. Still, both scenarios are a disaster; you cannot do anything to overcome them.
More specifically, you can try creating a config file similar to the one mentioned in the forum topic above. Such a config file loads the specified .NET Framework version when an Office extension tries to load any .NET Framework version. Hope you understand that this is not a solution at all. Say, it helps you in a given moment. Still are you in danger as the time moves on and the end user installs other Office extensions the load order of which is unknown and out of your control.
Another non-solution would be to turn all other Office extensions off. Though, this is definitely a non-solution, but it could be useful when debugging your Office extension. I’ll write more about turning Office extensions off one of these days.
You could think that .NET Framework 4.0 solves this problem because it allows loading several .NET Framework versions. But it isn’t so, .NET Framework 1.1 cannot be loaded in this way. Moreover, .NET Framework 1.1 will not be initialized if .NET Framework 4.0 is installed!
Well, enough of .NET Framework 1.1 and Visual Studio 2003: we will stop supporting VS 2003 in Add-in Express 2010. Whether this is good news for you or not, I’m really glad it will be this way. This is a right move as we will stop producing more problems for add-in developers.
Good luck!
3 Comments
Andrei, could you talk a bit more about the .NET 4.0 framework compatibility. From what you know about it, will 4.0 load seamlessly side-by-side with 2.0 inside the same Excel process? Also, are there any restrictions with using mixed-mode assemblies (C++/CLI), useLegacyV2RuntimeActivationPolicy=”true” startup attribute? Will the loading order affect it?
Lastly, does XLL loader approach solve these problems in a different way?
Thanks much!
Hi Yuri,
In fact, I still don’t have a clear picture of this feature of .NET Framework 4.0. When I complete the puzzle, I’ll tell you more about this. But one thing has caught my eye: as far as I understand this feature doesn’t relate to using mixed-mode assemblies. I expect them to work with no problems.
Andei, thanks for the answer. Other than the mixed mode assemblies, do you foresee any difficulties when both .NET CLR 2.0 & 4.0 are loaded at the same time?