VSTO 2005 SE

With Visual Studio.NET 2005 (VS.NET 2005) we can create standalone applications that automate and control Excel. We can also create so called managed COM add-ins, either based on the template ‘Shared Add-In’ or from scratch with VS.NET 2005.

The present main edition of Visual Studio Tools for the Office System (aka VSTO) can either be run as a standalone tool or as a ‘plug-in’ to the VS.NET 2005. This is important to know that it per se does not require that VS.NET 2005 to be installed, only the .NET Framework. If wanted, Office developer can develop .NET based solutions only with VSTO although it limits the target versions of the Office suite.

With VSTO 2005 (internal version 2.0) we can create document-level solutions (i e templates, files for specific tasks, smart documents and smarttags). It’s also possible to create application-level managed COM Add-ins with it but only for Outlook 2003 and later.  

In order to create any VSTO solutions we need to have the Professional Edition of Office 2003 or later installed on both the development machine and on the targeting machines. It also requires that the target machines have both the .NET Framework and the VSTO runtime installed. In my opinion VSTO is a development platform typical for enterprise solutions and where the requirements can be met via central controled IT-structures (especially the security aspects).  

In the end of the summer 2006 MSFT released the beta of VSTO 2005 SE (Second Edition) which I have explored together with Excel 2007. Today MSFT announced that the final release of it is now available for download.  It’s very important to understand that it does not replace the present version of VSTO 2005. It adds new functionality to VSTO 2005 to create application-level solutions (managed COM Add-ins) for all applications in the Office 2003 and 2007 suite with VSTO.

Before I downloaded the final release I read the following from the download page:

“Do not install VSTO 2005 SE on a computer that has more than one version of Microsoft Office installed.”

From a strictly enterprise point of view this is not remarkable in any way. After all, large worldwide enterprises usually run one version all over the world (at least in my experience). But for us small developers who are forced to work with several versions of Office (as well as different language versions too) it gets more difficult with VSTO with this kind of requirements.

If You already use VSTO and want to read more and download VSTO 2005 SE: VSTO 2005 SE

The above gives me the opportunity to put together a rather primitive but workable guideline when it comes to developing COM Add-ins for Excel:

# Use classic VB:  

• If the add-in target several versions in the range of 2000 – 2007 or all of them. 
• If You can’t afford to buy VS.NET 2005 or VSTO 2005 / 2005 SE and
• If the customers don’t explicit demand a managed COM Add-in solution.

# Use VS.NET 2005 or use VSTO 2005 + VSTO 2005 SE

• If the customers explicit demand a managed COM Add-in and
• If the add-in target one version of 2003 and 2007 or both.

As You can see I don’t make any differences between VS.NET 2005 and VSTO 2005/VSTO 2005 SE. Developing managed COM add-ins with VS.NET 2005 require that we ‘shim’ the solutions. VSTO already use a loader that doesn’t requires any ‘shimming’ but on the other hand it requires the VSTO runtime to exist on the target machines.

If we explicit target the areas of smart documents, smart tags and data bounded workbooks then VSTO is probably the best way to go.

The above guideline should not prevent us from learning and exploring both VS.NET and VSTO (which explain why this blog exist).

Finally, a comment on MSFT’s  “new” terminology. MSFT use the following terms:

• “Unmanaged COM Add-ins” and “COM Add-ins” are OK for me as they imply that they are developed with an older technology then .NET.
• “Managed COM Add-ins” is also OK for me as it implies that they are developed with a tool that requires .NET Framework.
• “Managed Add-ins” is used for VSTO 2005 SE solutions.  I totally disagree with the phrase because it imply that COM is not part of the communication between the host application(s) and the add-in(s). I prefer “Managed COM Add-ins”.
• “Add-ins” should only be used for add-ins created with the host applications.
   

Kind regards,
Dennis

Ps. I promise that in my next blogpost will take the ‘transition case’ further by showing the solution as a COM add-in developed with classic VB (that is VB 6.0).