views:

97

answers:

2

A few months back I put together a simple proof-of-concept piece of software for a small firm with an idea for a document editing tool. The company wanted this tool to be integrated into Microsoft Word, understandably, to maximize its accessibility to the average user.

I essentially wrote the underlying library with all of the core functionality as a C# project, and then used VSTO to get it running inside of Word. It felt like a bit of a duct tape solution, really; but then, I have (practically) zero experience developing tools for integration with MS Office, and it was only a proof of concept anyway.

Well, the firm was quite pleased with my work overall, and they're looking to move from "proof of concept" to the real deal. Fortunately, as I said, the core functionality is all there and will only need to be somewhat tweaked and enhanced. My main concern is figuring out how to put together an application that will integrate with MS Word in a clean and polished way, and which can be deployed easily in accordance with a regular user's expectations (i.e., simply running an install program and voila, it's there in Word).

I seem to remember reading somewhere that nobody uses VSTO for real professional projects. Is this true? False? What are the alternatives? And what are the tips and gotchas that I should be aware of before getting started on this issue of MS Word integration?

+2  A: 

I also remember reading that VSTO was not ideal for commercial software. Internal software is another matter and it has finally made inroads (at least in my organization).

I believe the biggest argument has to do with legacy versions of Office. VSTO only supports as far back as Office 2003. In addition, VSTO required dependencies have been painful to distribute in the past, although this lessens over time with new Windows releases.

For example, my latest project requires the following (assuming, but verifying .Net framework 3.5 is installed):

  1. VSTO Runtime 3.0
  2. VSTO Runtime 3.0 SP1
  3. Microsoft Office 2007 Primary Interop Assemblies
  4. Hotfix for Office (KB976477) - All users get the application-level add-in
Mike Regan
Did you really have to support versions of Office older than 2003? I haven't seen one in the wild in quite a bit.
Mathias
I haven't had to support anything older than Office 2003. Commercial software may have had to at one point, but with the release of Office 2010, the legacy argument weakens quite a bit.
Mike Regan
+5  A: 

One of the main issues with deployment of VSTO solutions has been the total deployment size. You have

  • your solution
  • the VSTO Runtime version of the project
  • the .NET Framework version of the project
  • the Primary Interops

This could very easily turn your simple and efficient solution into 40-50MB for someone to have to download. Corporate enviroments are somewhat easier to deploy in, but commercial grade software is tougher.

This is partially solved now in VSTO 2010 with a sort of "only the components you're actually using" Primary Interop deployment. This and other things to make deployment easier, such as One-Click, are certainly a reason to consider VSTO 2010. There are some good intros to this on Channel 9.

Commercial products using VSTO are not unheard of though - StoryboarderPro was written in VSTO and is popular in the eLearning industry.

Otaku
Can't agree more with the comment on the deployment size. I have deployed a few "real-world" VSTO Excel add-ins, and they work great, but the size of the installer is more or less the size of the 2003 and 2007 PIAs, and this is fairly unpleasant.Otaku, I haven't had a chance yet to play with VSTO 2010, doesn't it require .Net 4.0?
Mathias
@Mathias: VSTO 2010 is pretty flexible (compared to early versions). You can multi-target for different .NET runtimes, different VSTO runtimes, and different Primary Interops (Office versions).
Otaku