To read previously blogposts on the subject please see:
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 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.
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.