Why is VS development not supported with multiple versions of Office?
First, the Office client apps are COM-based. Normal COM activation relies on the registry. COM registration is a "last one wins" model. That is, you can have multiple versions of a COM server, object, interface or type library on a machine at the same time. Also, all of these entities can be registered. However, multiple versions can (and usually do) use the same identifiers, so whichever version was registered last overwrites any previous one. Also, when it comes time to activate the object, only the last one registered will be activated. COM identity at runtime depends on an object's implementation of QueryInterface, but COM identity at the point of discovery depends on GUIDs. GUIDs are used because they provide a guaranteed (for all practical purposes) unique identifier (surprise).
As soon as you put multiple versions of a COM server/object/interface/typelib onto the same machine, you introduce scope for variability. That is, although COM activation will ensure that the GUID-identified object gets used at the point of activation, you've set up the environment such that the object that this GUID identifies can change unpredictably over time – even short periods of time. This is one of the many reasons why it is very difficult to successfully develop solutions on a machine with multiple versions of Office – and one of the reasons we do not support this. But wait, how can this be? Surely a COM interface never versions? That's true, but, first, Office interfaces are not pure COM interfaces – they're automation interfaces, which are allowed to version (while retaining the same GUID). Second, the objects that implement the interfaces are obviously allowed to version, as are the typelibs that describe them.
Consider the scenario. You've installed Excel 2003 on your dev box, including the relevant Office 2003 PIAs. You create an Excel 2003 add-in. The project references the Excel 2003 PIAs. At runtime (including F5 from VS), Excel 2003 is launched, and it loads your solution which is bound against the Excel 2003 PIAs, which are also used at runtime. All is good.
Now, you install Excel 2007, keeping Excel 2003 on the machine (and at this point you've gone off the map into unsupported territory). At the same time, you install the Excel 2007 PIAs. So, the COM registration for all the objects, interfaces and typelibs now points to the 2007 versions. Plus, the Office 2007 PIAs include fusion binding redirect policies so that references to the Office 2003 PIAs are redirected to use the 2007 PIAs at runtime. If you explicitly launch Excel 2007 (or if you double-click an XLS, XLT, XLSX etc file – which are all now registered against Excel 2007), it will load your add-in and the Excel 2007 PIAs. This is close to the supported scenario where a user upgrades from Excel 2003 to Excel 2007 and does not retain the old version. In the supported scenario, we expect the add-in (originally built against 2003) to continue to work with Excel 2007 and the Excel 2007 PIAs (barring any breaking changes that Office might introduce between one version and the next). So, the normal case should just work.
However, on this imaginary machine we've retained the old version. So, what happens if you run Excel 2003 explicitly from the Start menu or from %ProgramFiles%\Office11\Excel.exe directly. Or indeed, if you press F5 within VS, which (on an Excel 2003 project) will also attempt to run Excel 2003 explicitly? Excel 2003 will run, and it will load your add-in, but it will be using the Excel 2007 PIAs. If there are no breaking changes between the 2003 and 2007 OMs (and therefore the PIAs), this should probably work ok – but if there are breaking changes, you're hosed.
Also, by default, when you add a reference to a PIA, this goes through COM registration. So, regardless of which version of the PIA you select from the Add Reference dialog, you'll actually end up with a reference to the last version that was registered. This is standard COM behavior, by design.
Now, let's say that on our imaginary dev box with multiple versions of Excel, we now create a new Excel 2003 project. This will be created ok, but the PIA references will be references to the last registered Excel 2007 PIAs. Or alternatively, if we delete the Excel and Office PIA references, and use the Add Reference dialog to add a reference to the Excel 2003 and Office 2003 PIAs. Even if you explicitly select the Excel 11.0 Object Library, because of COM registration, you'll end up with a reference to the Excel 2007 (12.0) and Office 2007 PIAs. Either way, you'll get the last registered PIAs. So what happens if you go ahead and build this project and try to run it? As before, if you explicitly run Excel 2007, everything loads and works just fine. As before, if you try to run Excel 2003, it runs with the Excel 2007 PIAs.
So, if you really insist on having multiple versions of the PIAs on the box (and I can't think of a good reason, and we certainly don't support this scenario), then you can workaround the problem by simply adding a reference to the specific PIA you want by its path not by its COM registration. Note, if you do this, you should not use the path to the PIA in the GAC. Instead, you should copy the relevant PIAs to some known location and reference them there. So, let's say we go back to our Excel 2003 project, and change the PIA references in this way. We could explicitly set references to the (path to the) Excel 2003 and Office 2003 PIAs. This will build ok, and you'll end up with an assembly whose metadata specifies that it should use the 2003 PIAs. If you then deploy this to an end-user machine which only has 2003, you're good. However, if you try to run it on your dev box, it will again use the 2007 PIAs – because that's the version that was registered last. So, fixing the PIA references only ensures you build the correct assembly that will work on the end-user's machine which has the matching version of the host app. It does not help you on the dev box. If you have multiple versions on the dev box, all bets are off.
Also consider that a machine with multiple Office versions could have all kinds of bizarre permutations. What if you install 2003 then install 2007 then uninstall the 2007 PIAs but not the 2007 apps; or you re-install the 2003 PIAs after installing the 2007 apps, etc, etc. Or, you could register say Excel 2003, plus say the 2007 version of the main Office dll, plus Excel 2007 PIAs, plus the 2003 version of the main Office PIAs, and so on. You can see how this rapidly produces a meaningless dev environment – you'd never be sure which permutation of versions you're running against, and most permutations would simply not be valid in a real end-user environment. You might think you can be careful to ensure you don't end up with such silly registration permutations, but factor in that both Office 2003 and Office 2007 and their many sub-components will auto-repair themselves at arbitrary times, and that related patches may also be applied at arbitrary times (perhaps pushed down by corporate IT), and so on. You can begin to understand why we do not support this scenario.
Now consider doc-level customizations. This is even more interesting, because we host Excel and Word objects within the VS IDE as design surfaces, using OLE inplace activation. This, of course, relies on COM registration. So, on our imaginary multi-version dev box, if you try to create an Excel 2003 doc-level customization, we'll end up hosting Excel 2007, and the PIA references will again be set to 2007 versions. So, for one thing, all the intellisense and autocomplete support will be specific to the 2007 versions of the OMs. This will inevitably encourage you to use method parameters or whole features of Excel/Office that are not available in the 2003 version – because the design-time support considers this valid, and the solution will build correctly (against the 2007 PIAs).
If you go ahead anyway, and then try to run the solution, by default VS will launch Excel 2003 (because that was the target version you specified when you created the project), and it will load your customization, but with the Excel and Office 2007 PIAs. Now, your code will fail in arbitrary places because you're using features that are simply not present – or are present with different signatures or semantics – in the running version. Plus, of course, running an app with a later version of the PIAs is strictly not supported.
You can see that there are many good reasons why we do not support developing on a machine with multiple versions of Office. You can also make the case that this is not a sensible dev environment, it is extremely difficult to get consistent behavior, it is likely impossible to guarantee that the environment stays consistent for any length of time, and you're pretty much guaranteed to have a dev environment that cannot match any sensible end-user environment, which therefore invalidates any testing you might do.
Comments
- Anonymous
June 09, 2007
Andrew Whitechapel wrote a post in which he explains why is a no-no to have multiple versions of Office... - Anonymous
June 11, 2007
Why we have kb's which helps us to do the sameHow to run multiple versions of Office on one computerhttp://support.microsoft.com/kb/828956 - Anonymous
June 11, 2007
One difference is that the kb deals with running multiple versions of Office and not development. But I agree with you it's weird :) - Anonymous
June 13, 2007
What's weird? My post explains in great detail why, although you can run multiple versions of Office on the same machine, we don't support developing with multiple versions of Office. That was really the point of the post, after all. :-) - Anonymous
June 13, 2007
Can't we have a kb article which says that developing with multiple versions of office is not supported? - Anonymous
June 14, 2007
Notice the smiley at the end :) - Anonymous
June 15, 2007
I noticed - thanks, Peter. :-) - Anonymous
June 15, 2007
This of course is the advantage of using the old "shared add-in" project types – you can build one add-in - Anonymous
August 23, 2007
The comment has been removed - Anonymous
August 23, 2007
Further to my last post, installing only Excel 2003 on my computer isn't the answer. The reason for my question is that a version of my program which worked with Excel 2003 crashed 2007. This results from an Excel 2007 defect, for which Microsoft Tech Support suggested a workaround. I'm now trying to test my code with the workaround on both versions of Excel. - Anonymous
October 16, 2007
I'm annoyed with this scenario. While I do understand the reasoning behind why the two don't work alongside each other, it is a bit rediculus to end up burning two licenses of windows and two licenses of visual studio just so you can test your code on 2007 while still being able to support 2003 for your users. - Anonymous
February 15, 2008
<<and I can't think of a good reason>>For me this says everything about VSTO. It's beyond belief that its difficult for someone on the VSTO team to imagine the need to run multiple versions of Office on a machine.It's a choice to implement VSTO this way and IMHO a poor one. - Anonymous
February 22, 2008
There are many resources to learn about Visual Studio Tools for Office, and they are scattered through - Anonymous
April 09, 2008
Bill - thanks for your comment. Perhaps you could elaborate.I didn't say I couldn't imagine the need - I can imagine all kinds of scenarios - but that doesn't necessarily make them good reasons.I'm happy to be corrected if this is wrong - and I'm keen to understand any valid scenario that requires running multiple versions of the same application.The typical case I've experienced is where the customer has an add-in or other extension which only works with version N and another extension which only works with version N+1. However, I don't consider this a "good" reason - the better approach would be to upgrade the old extension so that it works with version N+1 - wouldn't you agree?Also, as I explained in my post, there are several good reasons why it is a bad idea to develop with multiple versions of Office on the same machine. Most of these are not specific to VSTO at all, they're basic COM limitations. - Anonymous
July 10, 2008
Andrew--Say we develop our solution on the machine that only has Office 2003 but our customers' desktops may have both Excel 2003 and 2007. We also managed to properly launch Excel 2003 with our add-in (VBA based, not VSTO-based).In this case, does our application still reference to 2007 PIA? Even so, I believe it shouldn't be a problem assuming 2007 OM should be a superset of 2003 OM? - Anonymous
July 10, 2008
Charles - I'm not clear on your situation. You say you have a VBA add-in, yet you ask about PIAs. VBA add-ins do not use PIAs. Only managed code solutions use PIAs.If you have a managed code solution running in Office 2003, yet the machine also has Office 2007 installed, then it is likely that the solution will run with the 2007 PIAs - simply because it is likely that the 2007 PIAs were registered last. However, it could be that you installed (or repaired) the 2003 PIAs last, in which case all managed Office solutions will be using the 2003 PIAs (which therefore means that any such solutions that target functionality that is only available in 2007 will be broken). - Anonymous
July 24, 2008
By default, Visual Studio automatically converts Office 2003 projects into Office 2007 projects when - Anonymous
August 05, 2008
I can understand timelines and need to cut on functionality in order to release products. But release new VSTO version so often along with office solutions you are leaving us developers behind. I can just imagine how many virtual dev boxes I need for the VSTO stuff in just a year or two!Please understand the success for VSTO has to be the ease to use and maintain!Regards,Ali - Anonymous
August 05, 2008
Ali - thanks for your comments. We feel it is important to release new versions of the product whenever there are significant new features in either Office or the .NET Framework. We certainly get lots of feedback from developers telling us they need to take advantage of these new features, and asking us to provide new versions of the Visual Studio tools to support this kind of development. I'm sure you agree that developers need to keep up to date with the latest evolution of any platform that they target. - Anonymous
September 25, 2008
BelowmateriaisfromAndrewWhitechapel'sblog,whichisforVisualStudio,OfficeandotherNonsen... - Anonymous
September 25, 2008
This of course is the advantage of using the old - Anonymous
November 13, 2008
The comment has been removed - Anonymous
November 14, 2008
sancreations - nothing has changed. Developing with multiple versions of Office on the same machine is still not supported, for all the reasons I gave in my post. There is no "fix" possible - the fundamental issue is the nature of COM registration, which will not change. Note: it is possible to develop with multiple Office versions on the same machine, with some restrictions, but it is not supported. - Anonymous
March 24, 2009
Andrew,let me provide some background before asking my questions.We are developing a PowerPoint add-in using VS2008. The original version supports Office 2003. Due to the many differences between PowerPoint 2007 and 2003, we need to do significant development and testing to make it work with Office 2007 and 2003 at the same time. Therefore, we have Office 2003 and 2007 on the dev machines. And by the way, some of our customers are also using multiple Office versions at the same time (literally), e.g., because they produce presentations for multiple customers with different Office versions.Now to my questions:(1) We are referencing the PIAs by path and they are also installed on the target machines. Does that still mean we'll not use the PIAs we explicitly distributed in case the client has a different Office version?(2) Is it not possible to create a single add-in that works with both 2007 and 2003 if we want/need to use some of the 2007-only or changed functionality (e.g., color schemes)? We think about using the 2007 PIA "with care" ;-)(3) What would be the suggested approach in our case, considering that we need to be able to debug both 2003 and 2007? - Anonymous
March 24, 2009
Thomas,(1) If you reference the PIAs by path, and if that same path is valid on the target machines, then that's the path that will get used at runtime, regardless of the Office version installed. An alternative is to avoid using the PIAs (see below).(2) It is possible to create a single add-in that works with both 2007 and 2003. See here for more details:http://blogs.msdn.com/andreww/archive/2007/06/15/can-you-build-one-add-in-for-multiple-versions-of-office.aspxhttp://blogs.msdn.com/andreww/archive/2008/06/03/add-ins-for-multiple-office-versions-without-pias.aspxhttp://blogs.msdn.com/andreww/archive/2008/06/24/add-ins-for-multiple-office-versions-without-pias-pt2-or-vtblgap.aspx(3) With the caveats I mentioned in this post and the others I've quoted above, you could build an add-in for multiple versions, and debug it on one machine - but you'd obviously need to be careful to allow for all the things that could go wrong (as mentioned in the blog posts). - Anonymous
April 24, 2009
Hi Andrew,Nice post, help a lot. Now, what I'm having here is this:1) Projects: Excel 2003 AddIn and a Setup project to configure security.2) DEV Machine: Office 2003, VS 2008 SP1. The add-in works fine when runs the project. Add-In installs correctly, and runs correctly after instaled.3) BUILD Machine: Office 2007, VS 2008 SP1, TFS. We open the projects, do not convert to uses 2007 PIAs (by changing options in VS2008). The project build. We can install in the dev machine, but the add-in do not works in Excel 2003.Is there any other configuration to make this work, or we have to build in the machine with Office 2003 ?!Tks. - Anonymous
April 24, 2009
Robson - I'm not sure I understand your problem. You say at (3) that you're opening the projects but NOT changing the PIA references? So the project you're building still references the 2003 PIAs, right? And you've got the 2003 PIAs on the build machine? And you're referencing them by path? If the answer to all of these is 'yes', then the fact that you have Office 2007 itself on the build machine should make no difference at all, and you're still building a pure 2003 project with entirely 2003 references.So, if it doesn't work, I have to assume that you're changing the PIA references...?