This blogpost, together with some upcoming blogposts, will end the series “The Transition Case” by discussing and viewing the Visual Studio 2005 Tools for Microsoft Office System Second Edition (VSTO 2005 SE) based solution.
Since I have decided to set focus on VSTO & Excel during 2007 this blogpost is also a start for the series “Creating and Deploying Managed COM add-ins. However, it will not prevent me from continue to discuss .NET & Excel from a broader perspective. I will also later cover how to create and use classic commandbars in Excel 2003 with VSTO 2005 SE solution.
Before “diving into the world of VSTO” I would like to remind that my recommendation VSTO 2005 SE is still valid mainly due to the present deployment issues. However, I sincerely hope that when version 3.0 of VSTO is shipped these issues have also been solved in a developer friendly way.
VSTO 2005 SE was released in November 2006 and it provide us with the possibility to create application level add-ins, i e managed COM add-ins, for Excel 2003 and Excel 2007.
The following requirements must be met in order to create and distribute VSTO based add-ins:
- Visual Studio 2005 Professional or higher or
- Visual Studio 2005 Tools for Microsoft Office System (VSTO 2005) and
- Visual Studio 2005 Tools for Microsoft Office System Second Edition (VSTO 2005 SE) and
- .NET Framework 2.0 and later (also on the targeting computers)
- VSTO 2005 SE runtime (on the targeting computers)
- Excel 2003 (certain versions only) and Excel 2007 (all versions)
Microsoft strongly recommend to not install VSTO 2005 SE on any computer that have more than one version of Microsoft Office installed.
One important aspect is that we don’t need to shim the add-ins like we need to do with Shared Add-ins (developed with VB.NET) since VSTO use an add-in loader file.
The following (Swedish) screenshot shows the entry in the HKEY_CLASSES_ROOT section and under the InprocServer32 subkey:
Compared with managed/unmanaged COM add-ins the registry entries in the HKEY_CURRENT_USER is the same except that VSTO managed COM add-ins also got a Manifest entry (that points to the Manifest.DLL file for the Add-in) as the following (Swedish) screenshot shows:
# The Project
The project involved is the same as for the previously Transition case although it does not cover subclassing and reading/writing to the Windows registry.
The following screenshots shows the Solution Explorer for the project:
As we can see it contain a great number of Detected Dependencies.
In my opinion this is a welcome improvement as this two events are the ones we usually had used in unmanaged COM Add-ins. The ExcelLocale1033Proxy class is interesting as it provides two methods we can use to modify the locale ID for individual Excel objects, i e wrap for locale ID 1033 (English United States) and unwrap for another Locale ID, for instance Swedish. An even better approach is to use ExcelLocale1033Attribute which allow us to pass all the native Excel objects locale ID and in that way consider the local regional settings (which was also pointed out as a shortcoming in previously version by Bullen et al in their book “Professional Excel Development”).
In the next blogpost I will discuss more in detail the project itself.