Office Interop API Extensions Now Available!
As announced in Andrew Whitechapel's post, version 1.0 of the VSTO Power Tools have been released! One of those tools is the Office Interop API Extensions, a set of libraries which extend the Office object model to simplify development on the Office platform. This past week I've blogged about the capabilities of these extensions and now you have the chance to try them out yourselves! Please let us know what works, what doesn't, what could be improved, and what you would like to see in the future.
The VSTO Power Tools v1.0.0.0 is a collection of three packages found here. The Office Interop API Extensions is packaged as VSTO_PTExtLibs.exe. Please note that, despite the prerequisites listed on the MSDN download page, the Office Interop API Extensions can be used with both Office 2007 and Office 2003, though .NET 3.5 is required in both cases. Also, these extensions do not have a dependency on VSTO; they can be used within any application which automates Office.
Comments
Anonymous
February 21, 2008
PingBack from http://www.biosensorab.org/2008/02/21/office-interop-api-extensions-now-available/Anonymous
February 21, 2008
Philip, this is great - thank you very much for the update. I've installed it all, but am a little overwhelmed. I'd like to get started creating a little app that uses Linq to Dasl to query my local Outlook data. Could you recommend a walkthrough for this? Something like that would be really helpful.Anonymous
February 21, 2008
You're right, the posts have dealt with very specific pieces of the extensions. Now that they're officially released, I should put together a start-to-finish walkthrough. I'll put that at the top of my list of things to do.Anonymous
February 21, 2008
That would be great - thank you. It'd be great to see a walkthrough of something to help us get started doing something, e.g. selecting all your Outlook Calendar entries that are members of a particular Category.Anonymous
February 22, 2008
I'll do something along those lines, but I might not be able to get to it until early next week. In the meantime, have you looked at the User Guide? It should be installed in the "<Program Files>Microsoft VSTO Power Tools 1.0Office Interop Extensions". It may give you a better idea of how to get started.Anonymous
February 25, 2008
Now that the Office Interop API Extensions have been released , I thought I would post a complete walkthroughAnonymous
February 25, 2008
Now that the Office Interop API Extensions have been released , I thought I would post a complete walkthroughAnonymous
June 16, 2008
How can I distribute Office Interop API Extensions with my application? Can I use ClickOnce or classical setup project? Installation of VSTO_PTExtLibs.exe on the user's computer is impossible beacause installation of Visual Studio is required.Anonymous
June 30, 2008
Hi Daliboris, If installing the Office Extensions via the original Power Tools installer is not feasible, then you have two options: include the extension assemblies used by your application with your own installer and deploy them to the GAC, or include the assemblies alongside your application. The former may be better from a versioning perspective, as you can use binding redirects to force all applications to use any new versions of the extension assemblies. However, the latter may be simpler from an installation perspective as there is no GAC'ing involved. You are the most qualified to make that choice for your application. -PhilAnonymous
April 14, 2010
Why exactly does VSTO_PTExtLibs.exe have a depedancy on Visual Studio? What kind of lunacy is this, do you really expect organisations to install VS on end users' machines? Was this just an oversight or were the extensions just intended as a developers' plaything to use and then throw away??!Anonymous
April 15, 2010
VSTO_PTExtLibs.exe has a dependency on Visual Studio because it is the vehicle for distributing the extensions to developers (who presumably have Visual Studio installed on their local machines). VSTO_PTExtLibs.exe is not intended to be the vehicle for distributing the extensions to end-users. Instead, the extension assemblies used by your application should be distributed along with your application. Please see the User Guide (installed with the extension assemblies) for more details. One reason for this approach was to minimize the number of assemblies that need to be installed on end-users' machines; the extension library has individual assemblies for each Office application and for both 2003 and 2007 versions. If you use the extensions only with Word 2007, for example, you really need only redistribute one assembly. -PhilAnonymous
April 15, 2010
Phil, Thanks for the prompt and concise reply. Perhaps I misunderstood the users guide but even after rereading it, I can't see that it explicitly states you can't use the installer on client machines without Visual Studio. The problem I have is that I'm developing an Excel document level customisation which will be published to a network share, and do not want the end user to have to run any setup.exe (they can't due to no admin rights) - they need to simply open the workbook and it will run. This is because we do not want to significantly alter the user experience from our current model of Excel VBA applications which have no requirement to explicitly install code on the client machine. We had hoped to use the extension libraries by rolling them out automatically along with .NET 3.5 and the VSTO runtime. Are you saying in order to do this I have to package the Excel.Extensions.dll in it's own installer? ThanksAnonymous
April 15, 2010
You are correct in that the User Guide does not explicitly state that you cannot use VSTO_PTExtLibs.exe to redistribute the extension assemblies, but as you found, the installer has a dependency check which prevents it from being used for that purpose. You have two basic options for distributing the extension assembly: either a custom installer that places it in the GAC or another common location, or side-by-side the referencing assembly. The best choice depends on its intended usage. If you plan to deploy many individual applications which use the same extension, installing to the GAC via a custom installer may be better in terms of serviceability (and disk space, whatever that's worth these days). However, the simplest and least impactful approach is probably to place the extension assembly in the same folder as the application assembly (for each application in which it is used). If that doesn't work for your scenario, feel free to contact me directly (Phillip (dot) Hoff (at) microsoft (dot) com) and we can discuss it further. -Phil