Freigeben über

Add-ins for Office 14

  • Artikel

Following on from my previous post, it should be clear that we've designed the VSTO Office add-in support to be optimally useful across multiple different Office host applications and spanning multiple Office versions.

To be very clear, let me reiterate: we cannot support something we have not tested. We have not tested support for currently unsupported Office applications such as Access. And, we clearly cannot test future versions of Office. That said, my assertion that VSTO add-ins are a long-term strategic option can be backed up by the ease with which it could be extended to support future versions of Office. This is invaluable in prototyping and proof-of-concept scenarios. For example, how could I build a VSTO add-in with VS 2008 (released November 2007) for Office 14 (not yet released)?

The answer is that I could in theory create a VS 2008 Office 2007 add-in project and then modify it to work with Office 14. To explore this, let's suppose I want to create an add-in on a machine with only Office 14 installed. For example, a Word add-in.

1. Using VS 2008, I can create a Word 2007 add-in project. As soon as I create the project, I'll get project creation warnings, repeated at compile time, indicating that I have neither Word 2007 nor the Word/Office 2007 PIAs installed.

2. I'll ignore the warnings, and build the project. The project will build successfully, because from VS 2008, the VSTO add-in projects specify references to a private copy of the Office PIAs in %ProgramFiles%\Microsoft Visual Studio 9.0\Visual Studio Tools for Office\PIA\<Office11 | Office12>\ - for example, C:\Program Files\Microsoft Visual Studio 9.0\Visual Studio Tools for Office\PIA\Office12\Microsoft.Office.Interop.Word.dll.

3. However, the solution won't run – F5 will produce an error: "You cannot debug or run this project, because the required version of the Microsoft Office application is not installed."

4. If I just want to get the solution running, there are 2 changes I need to make: ensure that the Word PIAs can be located at runtime; and specify that VS should launch the Office 14 version of the target host application instead of the Office 12007 version.

5. To make the first change, I must set the Copy Local property of the existing references to the Word and Office 2007 PIAs to true. This ensures that fusion can find these PIAs at runtime – this is necessary on the Office 14 machine, because the Office 2007 PIAs are not in the GAC. Conversely, the Office 14 PIAs are in the GAC, but are of no use to me.

6. Note: you might be wondering, why can't I simply replace the references to the Word/Office 2007 PIAs with the Word/Office 14 PIAs? The answer lies in VSTO's use of MAF. The MAF model is the managed equivalent of the COM model. Using MAF, my add-in talks to client-side proxy objects, which talk through immutable MAF contracts to server-side adapter objects. By "client" and "server", I mean the automation client and server – that is, where the add-in is the client or consumer of the automation object model exposed by the Office "server" application. In this context, "server" means the object that provides the service – not "server" as in a remote server tier or physical server. The server-side adapters, in turn, talk to the Office OM. MAF server-side adapters always version in step with the server (the Office host application); and client-side proxies are always bound to a client (add-in) version. What this means in this context is that the Word 2007 add-in project uses the VSTO v3 runtime (because it's the latest one available at the moment), and this runtime includes server-side adapters that are specific to Word 2007 – and therefore dependent on the Word/Office 2007 PIAs. So, my add-in is not bound to a specific version of Office, but the adapter side of the MAF implementation in the VSTO runtime is. The idea is that as soon as we release a new version of the VSTO runtime that targets Office 14 (let’s call it VSTO “v4”), existing add-ins that previously used VSTO v3 can seamlessly carry on working using VSTO v4, without any need to rebuild.

7. To make the second change, I can change the Project settings | Debug, and specify Start external program. I set this to the path to the Office 14 application I'm targeting, eg: C:\Program Files\Microsoft Office\Office14\WINWORD.EXE.

8. With these changes in place, F5 just works, launching Word 14 and loading the Word 2007 add-in.

9. Note that instead of setting the Debug property to an external program (step 8 above), I could modify the .csproj file directly, to set the OfficeVersion and DebugInfoExeName attributes of the <ProjectProperties> element from 12.0 to 14.0. For example, change this:

<ProjectProperties HostName="Word" HostPackage="{D2B20FF5-A6E5-47E1-90E8-463C6860CB05}" OfficeVersion="12.0" VstxVersion="3.0" ApplicationType="Word" Language="cs" TemplatesPath="" DebugInfoExeName="#Software\Microsoft\Office\12.0\Word\InstallRoot\Path#WINWORD.EXE" AddItemTemplatesGuid="{147FB6A7-F239-4523-AE65-B6A4E49B361F}" />

… to this:

<ProjectProperties HostName="Word" HostPackage="{D2B20FF5-A6E5-47E1-90E8-463C6860CB05}" OfficeVersion="14.0" VstxVersion="3.0" ApplicationType="Word" Language="cs" TemplatesPath="" DebugInfoExeName="#Software\Microsoft\Office\14.0\Word\InstallRoot\Path#WINWORD.EXE" AddItemTemplatesGuid="{147FB6A7-F239-4523-AE65-B6A4E49B361F}" />

 

So, the agility of the VSTO add-in model allows me to prototype add-ins in Office applications that are not supported, and equally in Office versions that are not even released yet. This will obviously be useful to the "early adopter" customers who need to get a head-start on the competition by investigating products prior to final release. It's also very useful to us internally. People working on the various Office application teams can explore the behavior of extensibility in Office 14 well ahead of any released VS design-time or runtime support. This is vital for us to ensure that we build the Office platform to include features that will actually work as expected when real customers start to build real solutions on top of it.

Comments

  • Anonymous
    February 02, 2008
    PingBack from http://www.ditii.com/2008/02/02/microsoft-vsto-add-ins-for-office-14/
  • Anonymous
    February 19, 2008
    In my previous post , I looked at how the VSTO add-in model is flexible enough to be used in prototyping
  • Anonymous
    February 19, 2008
    In my previous post , I looked at how the VSTO add-in model is flexible enough to be used in prototyping
  • Anonymous
    April 22, 2008
    Bekanntlich sind Informationen direkt von der Quelle die besten, da nicht misinterpretiert. Andrew Whitechapel
  • Anonymous
    May 09, 2008
    People have been building native shared add-ins for Office (and related apps) since their introduction