Brad Smith

Okay, maybe this is a stunned question, but I want to make sure I'm crystal clear before I head too far down the wrong path. I did a search, and I understand all but one thing...

I want to make an add-in for both Outlook 2003 and Outlook 2007. I *do* understand that the best (only ) approach is to make a "stub" add-in for 2003 and another "stub" for 2007, and have them each call into common assemblies. No problem there.

On my development machine, I have Office 2007 installed. That means I don't have the Office 2003 PIAs (since you can't have both Outlooks installed at once). So if I make a new VSTO 2005SE project for an Outlook 2003 add-in, it obviously bitches that it can't find the Office 2003 PIAs.

My question is: is there a "trick" to allow me to build an Outlook 2003 add-in on my machine, like installing the Outlook 2003 PIAs directly Or do I need to set up a completely separate Dev machine with VS.NET & VSTO & Office 2003 just so I can build the 2003 add-in


Brad.


Re: Visual Studio Tools for Office Developing for both 2003 & 2007 with VSTO 2005 SE

Grant Carthew

Good question Brad, I am interested in the answer to this one.

I was planning on setting up a virtual machine to acheive this, but being able to build both would be nice.

Anyone

Grant.






Re: Visual Studio Tools for Office Developing for both 2003 & 2007 with VSTO 2005 SE

ScottStout

I'm working on the same issue. I have installed the office 2003 PIAs, and can't add reference. Hopefully developers don't have to keep using Office 2003 until all of their clients have moved on.

I assume you can't go the other way either: distribute Office 2007 PIAs to Office 2003 users and expect that the methods 2003 and 2007 had in common will somehow work.

Scott





Re: Visual Studio Tools for Office Developing for both 2003 & 2007 with VSTO 2005 SE

Brad Smith

I'm not worried about deployment. I'd have no intention of actually distributing any PIAs to anybody. The goal would be to either have the installer register one add-in or the other based on whatever Office version you had installed, or find some other way to have two add-ins that are somehow "selected" based on what Office is installed/running. I'll figure that out when I get there. :-)
I'm almost positive that not only are you not supposed to distribute the PIAs anyway, but deploying one version's PIAs on another version's install is a really bad thing (whether it would work or not, which I'm sure it won't).

My concern is basic development. On the one hand the release announcement for VSTO 2005 SE "recognizes" that us here in the real world have to support multiple versions of Office (heck, I'm just lucky that we only recently dropped Office 2000 and Office 2002 from our list for the next release); but on the other hand it appears they didn't *really* recognize much, since unless somebody pipes up with the magic trick, we need to do completely parallel development on two separate machines with two separate VS.NET & VSTO install to accomplish our real-world goal. We're okay because we have volume license keys for multiple VS.NET installs, but I have to wonder how smaller development shops handle this.

I remain hopeful an answer to the question is forthcoming, but hope is beginning to fade... :-(

Brad.




Re: Visual Studio Tools for Office Developing for both 2003 & 2007 with VSTO 2005 SE

Andrew Whitechapel - MSFT

Let me prefix my response with the caveat that VSTO development is not supported on a machine with multiple versions of Office installed. This is partly because there are known issues if you attempt to do this, partly because Office itself only partly supports the scenario, and partly because we have not exhaustively tested all the possible permutations.

The situation is not completely straightforward. Installing Office 2003 and Office 2007 SxS on the same machine is largely supported for Office end-users, although it is definitely not recommended:

http://support.microsoft.com/kb/928091/en-us

For Office _developers_, the problem is more acute, primarily because many development tools (including Visual Studio) will look to use standard COM/OLE automation behavior when working with Office applications. You only have to think about how VSTO hosts Excel and Word inside the VS IDE to realize that there's a lot of sophisticated OLE automation going on there. And, of course, COM is very much a "last registered wins" model. So, as soon as you try to deploy and use multiple versions of a COM component on the same machine, you'll run into conflicts. This is obviously the case with Office, because all the Office client applications are COM servers. The most acute problem is with Outlook - hence why multiple versions of Outlook are not supported SxS on the same machine, not even for regular end-users, let alone developers.

Now, as to building add-ins that run in multiple versions of Office, you have some choices. You can simply build to the lowest common denominator (typically, the earliest version you want to target), and your add-in should continue to function correctly in later versions (barring any breaking changes in the Office OM itself).

Also, as you suggest, you can factor out any version-specific functionality into separate assemblies which are used conditionally by your add-in's entrypoint assembly. For example, put all your Office 2003 CommandBar manipulation code into one dependent assembly, and all your Office 2007 ribbon customization code into another dependent assembly. So, as your post seems to indicate, designing the add-in shouldn't be a problem.

The difficulty is in the logistics of _developing_ the add-in, given the Office/COM imposed constraints.

Bearing in mind my caveat above, with a little experimentation you'll find that some things technically do work, up to a point. For instance, there's nothing to stop you installing multiple versions of the PIAs in the GAC. However, you also need to register them, and here you hit the "last registered wins" problem. Another example: you could add a reference in your project to the specific PIA version you want by navigating to the full (real) GAC path instead of using the .NET and COM tabs in the dialog, but what happens when you hit F5 Regardless of which PIA you build against, F5 will launch whichever Office app version was registered last. Plus of course, you don't want to corrupt your system - for example, by having one version of the Office app itself (and its sub-objects) registered, while having a different version of the PIAs registered.

Even if you manage to use these workarounds successfully, and you get some things to work with Excel, Word, PowerPoint, etc - you're still faced with the specific problem that Office simply does not allow multiple versions of _Outlook_ on the same machine. So, with all Office apps apart from Outlook, you can probably achieve a reasonably good development experience, with a bit of tweaking, but if you're targeting Outlook specifically, then your only recourse is to use multiple machines.

There is an upside to this constraint: don't forget that none of your target users will have multiple versions of Outlook installed. So, if you do your development in an environment which cannot match your users' environment, your obviously opening yourself up to unexpected behavior. Even for the other Office apps, which do support SxS install, such as Excel and Word - by far the most likely scenario is that the user only has multiple versions of _Office_ but not multiple versions of an individual Office app. For example, they might have say Outlook 2007 and Excel 2003.





Re: Visual Studio Tools for Office Developing for both 2003 & 2007 with VSTO 2005 SE

ScottStout

Thanks for the post. I still need a little more clarification. In my scenario, I am doing a least common denominator type add in for Excel that I want to have work in both Office 2003 and 2007. I just want to make a minor fix to the add-in and recompile. The problem is that I have Office 2007 on my machine. Is there any way for me to compile against the Office 2003 PIAs without having Office 2003 installed

Thanks again,

Scott




Re: Visual Studio Tools for Office Developing for both 2003 & 2007 with VSTO 2005 SE

Brad Smith

Thanks for the post. Fortunately for me I've been doing COM for a while (since back when it was called OLE), so I have a pretty good comprehension of what you're saying. I think as I understand it would be possible with some tweaking to *build* add-ins against multiple PIAs on one machine, but pretty much impossible to *run* them (especially if we're dealing with Outlook).
In my case, the add-in will be virtual identical in Outlook 2003 & 2007, except one would have a command bar interface and the other a ribbon. So with careful design the bulk of the testing would be in the common modules, but I'd still need a machine (or VM) to test the version-specific stuff.
I rather expected that the short answer was going to be "you can't get there from here", but I wanted to be crystal clear before I went too far down the wrong path. :-)

Brad.




Re: Visual Studio Tools for Office Developing for both 2003 & 2007 with VSTO 2005 SE

ScottStout

When you register the PIAs, what path do you give The 'real' GAC path

C:\WINDOWS\assembly\GAC\Microsoft.Office.Interop.Excel\11.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Excel.dll

If I can get this to work, my plan is to register Office 11 PIAs, build my add-in, register office 12 PIAs.






Re: Visual Studio Tools for Office Developing for both 2003 & 2007 with VSTO 2005 SE

ScottStout

I added reference directly to the GAC paths and it worked.

Here are the steps I took.

1. Install the 2003 PIAs.
2. Add reference to Office 11 Object Library from COM tab of the Add Reference dialog.
3. Enable GAC view as shown here: Disabled the Assembly Cache Viewer by adding registry key :
HKLM\Software\Microsoft\Fusion\DisableCacheViewer [DWORD] to 1.
this is discussed further here:
http://www.codeproject.com/dotnet/DemystifyGAC.asp df=100&forumid=15829&exp=0&select=940022
4. Added references straight to the Office 11 PIAs:

C:\WINDOWS\assembly\GAC\Microsoft.Office.Interop.Excel\11.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Excel.dll
did something similar for:
Microsoft.Vbe.Interop.dll
Microsoft.VBE.Interop.Forms.dll

5. Build.
6. Go to your Setup Project and exclude all four of these files.
7. Make sure you are using this prerequisite: http://support.microsoft.com/kb/908002
8. Install on a computer with office 2003 and run.

Note: I am not using any references to the VSTO assembiles. Therefore, my case my be simpler than most.





Re: Visual Studio Tools for Office Developing for both 2003 & 2007 with VSTO 2005 SE

Andrew Whitechapel - MSFT

Scott - yes, that's the kind of "tweaking" I indicated, and yes, you should probably be able to get most things working on your dev machine using these workarounds.

As Brad reiterates, the big blocker is Outlook. Plus, bear in mind what I said about emulating the target user's environment. Even if you code+build on a "hybrid" machine, you should ultimately be testing on real machines (or VPCs) that match your user's real machines.