Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part V

To read previously blogposts on the subject please see:

Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part I

Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part II  

Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part III  

Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part IV 

Prerequisites
In order to run VSTO created managed COM add-ins there are certain requirements, in terms of prequisites components, that need to be met. The basic components are the following:

• .NET Framework
• VSTO Runtime
• Office 2003 and / or 2007 PIA
• For Office 2003 SP-1 and later

It can be discussed whether all the prerequisites components, when missing on the targeting computers, should be part of the VSTO solution’s MSI (Microsoft Installer) file or not.  The installation process starts to check if the target computer contains the prerequisites or not. If not, then the missing components are first installed and then as a final stage of the process the VSTO solution is installed.

Installing all the required components involves several installation steps and if anything goes wrong then it can be difficult to track down the error(s) and also to rollback the installation process, i e to restore the computer to its previously state.  The alternative approaches we have to choose among are:

• Install all the required components as standalone installations and separated from the installation of the VSTO managed COM add-in.
• Install some of the components, VSTO and PIA, together with the VSTO solution and install .NET Framework as a standalone.
• Install all the required components together with the VSTO solution.

The less we know about the client and their targeting computers enviroment the more important it is to know what are already installed and not. Microsoft has a good tool that gives us a documentation over the present status, Microsoft PSS VSTO 2005 Client TroubleShooter (not yet available for Office 2007). The outcome of using this tool will guide us to some extend which alternative to choose from the above list.

What if we don’t know anything or very little about the targeting enviroment? If we have good knowledge and are skilled in creating “bullet proof” MSI-packages then we can include all prerequisites components and roll it out. If not, then it may be better to ask the client to first install the necessary components and then install the VSTO solution. It may not be the optimal situation but at least it gives a workable solution.

No matter of approache we use it’s very important that the same version of .NET Framework and VSTO Runtime are installed. (One good approach is to create a folder with a name like “Prequisites 2.0” and store the relevant components in it.)

When viewing the default list of prerequisites the items VSTO, PIA and SP are not among the available items. How can we add the wanted prerequisites components to the list,  i e how to create and add our own customized bootstrappers? 

When taking part of the two articles from Microsoft on VSTO deployment (see below) these sources assume that this kind of preparation has already been taken care of… 

This can be done manually but it requires knowledge about XML and also how to work with the Windows Registry. However, I recently discovered an excellent tool that create and add bootstrappers in a very user friendly way (which I also highly recommend):

• An introduction to the Bootstrapper Manifest Generator
• Download Bootstrapper Manifest Generator

It also handle own created prerequisites component in a similar way.

The following picture is from my developing machine and shows the added customized bootstrappers:

 

I prefer to have the components under “own control” and therefore chooses the above location for them (see picture).

The articles from Microsoft:

• Deploying VSTO 2005 Solutions Using Windows Installer (Part 1 of 2)
• Deploying VSTO 2005 Office Solutions Using Windows Installer (Part 2 of 2)

In addition to the prerequisites basic components above we may also consider to include the fix – KB908002 – also for VSTO solutions. It’s still necessary for managed COM Add-ins targeting Office 2007.

In the next post I will discuss security and after that the final deployment process.

Kind regards,
Dennis

Advertisement

Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part IV

To read previously blogposts on the subject please see:

Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part I

Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part II  

Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part III  

Introduction
This article and the coming articles on the subject sets explicit focus on the deployment process. 

In general for less advanced COM add-ins created with classic VB deployment is not an issue. If there are any problems the online community has usually a good knowledge about it. 

For COM add-ins created with VB.NET (Shared Add-in template) the situation may be different as there may be deployment issues related to .NET Framework, PIA/IA, and the targeting Office version(s). Compared with classic VB the VB.NET deployments issues may be more complex and difficult to solve but within the online community there exist a general experience and a common good knowledge about .NET based deployment.

When it comes to VSTO created managed COM add-ins the situation is total different situation then with the above cases. Microsoft has a high development pace for VSTO and for every new version most major known problems are solved but at the same time new problems are created.

We need to be aware of two important aspects:

• The VSTO technology is still a “newborn” baby and still suffers of “teething problems.”
• In order to run VSTO solutions it requires a runtime version of VSTO to be installed on the targeting computers. It means that an additional layer is placed between Excel and the tools.

The following picture views the number of layers that exist in order to use VSTO solutions with Excel:

If the COM add-in(s) are loaded when Excel starts then both the .NET CLR and the VSTO Runtime need to be started before Excel can load the COM add-in(s). If they already are running, especially the CLR, then launching Excel will be much faster compared with the opposite scenario.

The picture also shows the levels where there may occur errors. It means that the complexity is high when it comes to tracking down errors. In addition, Microsoft has recently released new versions/updates:

• The first version of Office 2007,
• Some fixes for Office 2003,
• The first version of Windows Vista,
• SP-1 for the Visual.NET suite and,
• Version 3.0 of the .NET Framework.

Which increase the complexity of error tracking as new versions/updates as well as the number of new versions are potential sources for errors. 

So when we compile the above list with the present possible configurations the list gets very long.  In other words, the complexity increase heavily as the number of  possible sources of errors increases.

The more advanced technology that is involved the more “sensitive” it tends to be. VSTO is no exception. The real difficult scenarios to deal with are:

• The Office installation is corrupted (including the PIAs).
• The .NET Framework installation(s) are corrupted.
• The VSTO Runtime installation is corrupted.
• Installations of Service Packs and monthly fixes of Windows go wrong.

Since we don’t have access to relevant diagnostic tools that provide us with relevant system information the above issues are part of the “Black Box”-syndrome. 

In my opinion it’s a must that MSFT as soon as possible makes diagnostic tools available that actually can help us out.

Large corporates with dictating standards and configurations are better off than other corporates. Since VSTO explicit target this group of corporates developers, we who are not associated with this group of corporates will face a more challenging situations with smaller customers.

When all the above pieces are put together we end up in a situation where:

• Deploying VSTO solutions can be less complex or quickly turn into “nightmares”.

In order to get friendly solutions the two areas that should be in focus are prerequisites and security

Prerequisites
Prerequisites are components that need to be installed on the targeting computers and must work properly in order to get VSTO’s managed COM add-ins working. The above picture is the skeleton to discuss the prerequisites.

Security
Code Access Security (CAS) is the .NET CLR mechanism for maintaining security based on the identity of code. In order to get VSTO created managed COM add-ins to work the assemblies must have full permissions, i e granted full trust. When a VSTO project is created on the developing computer it gets automatically full permissions. However, when deploying the VSTO project on the targeting computers we need to make sure that it gets full permissions.

In the next article I will discuss strategies when it comes to prerequisites and in the final article I discuss CAS and VSTO.

Finally, I believe that Microsoft will, during 2007, make improvements that eliminate most of the issues we face today and also make it possible to use ClickOnce with VSTO.

Kind regards,
Dennis

Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part III

To read previously blogposts on the subject please see:

Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part I

Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part II 

Here in the third blogpost on the subject focus will be on the procedures that make up the utility. In order to take part of the code itself please see the following article at my English site: Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part III

The most notable aspect of the code is that in order to access the Excel Object model we need to go via the ThisAddin class:

• If inside the ThisAddin class we can access it with the statement:
  Me.Application 
• Code outside the class but inside the project we can access it with the statement:
  Globals.ThisAddin.Application

This is the major different between VSTO solutions and VB.NET (Shared Add-in) solutions (except for the differences in the connection class).

If You download the VBA-solution for the Transition Case and compare it with the code here (that is at my English site) You will see that the differences are not many and/or not that much or…?  

What do You think?

Kind regards,
Dennis 

Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part II

I decided (again) to add all code and picture into an article at my English site which is available here:  Creating & Deploying Managed COM Add-ins with VSTO 2005 SE – Part II

After that the connection class has been created (Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part I) the next step is to implement the IRibbonExtensibility. This can be manually done but MSFT have made available a simple Ribbon wizard. Choose the Ribbon Support from the component list and a class module as well as a XML file is added to the project. Both these files include skeleton code which gives us a platform to start from. In my opinion this is an excellent approach and I hope that MSFT in the next version of VSTO (version 3.0) will develop it further so it becomes a real interactive wizard where the output will be based on various input from the developers. 

The most interesting part is that an overriding method, RequestService, is added to the class module. In return this method allow us to work with the external libraries of IRibbonExtensibility, ICustomTaskpaneConsumer and FormRegionStartup. At present only these libraries are supported but in the future we can expect to work with additional libraries. Andrew Whitechapel has recently published a good blogpost on the subject – Low-level support for ICustomTaskpaneConsumer, IRibbonextensibility and FormRegionStartup. In my opinion this is an excellent approach as it gives us an easy access to external libraries and therefore a flexibility situation when working with VSTO based projects.

Working with RibbonX may or may not be difficult but there exist some good resources online that may be of interest to consult:

• pschmid.net forum
• Ken Puls’ Sandbox project
• Jensen Harris – An Office user Interface Blog
• Avenius Gunter – Access 2007
• MSDN – Ribbon Extensibility Overview

When it comes to Ribbon customization I prefer to keep things very simple. Compared with classic CommandBars (CBs) the structure is totaling different. Although MSFT probably will add some additional properties and methods to the Ribbon in coming Office versions it can, per design, never be as flexible as the CBs. In general I believe we all need to think deep on how we view and approach the Ribbon UI. After all, it’s designed for the group of end-users and not for the group of developers.

As for customized images the preferable file format is PNG and I can only agree on that recommendation.

In my next blogpost I will set focus on the part of the project that actually does the end-user’s wanted work.

Kind regards,
Dennis