Below materia is from Andrew Whitechapel's blog, which is for Visual Studio, Office and other Nonsense.
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.
