Creating and deploying Managed COM add-ins with VB.NET 2005 – Part IX
You can find the earlier post on the subject at the following links:
Part I – Introduction
Part II – Connection
Part III – Notes Tool – Workbooks
Part IV – Notes Tool – Worksheets
Part V – Notes Tool – Main functions
Part VI – COM Shim Wizard
Part VII – Strong Name & Digital codesign
Part VIII – Deployment
This is by no mean an easy area and the available utilities place a high demand on the developers who need to use them. Therefore make sure You know at least how the tools work and what can be achieved with them.
As for troubleshooting code it’s a too large area to be covered here but in general the ‘standardways’ for tracking down code issues should be applied togehter with the tools .NET offers.
A good start is to avoid most articles that MSFT has written on the subject as it may be very confusing. Read the COM Shim articles mentioned here and You’ll be fine.
Since we use a standard COM DLL as a ‘loader’ and as a ‘bridge’ there is no need to ‘release’ the objects by using Marshal.ReleaseCOMObject or Marshal.FinalReleaseComObject. Set the variable objects to ‘nothing’ and move along.
By default the loadbehavior is set to 3 (Connect | Bootload) and therefore it should load when the host (Excel) is launched.
When debugging managed COM add-ins they may not be available as expected in Excel (due to the fact that they may cause Excel to crash and therefore get ‘blacklisted’ by Excel). If this is the case then choose the command Help | About Microsoft Office Excel | Disabled items… in Excel and restore the add-in and then change the code accordingly.
It exist several reasons why a deployment don’t work as expected on one or more targeting machines. Here I cover some important aspects to regard when trying to troubleshooting the issue(s).
# In general it’s recommended to make sure that the latest updates of Windows, Excel, the related PIAs and .NET Framework are available on the targeting machines. It also include any fixes to the .NET Framework like KB908002.
# Are the permissions correctly set on the target machines?
By default the .NET environment give us one code group named ‘All Code’ that is associated with the ‘FullTrust’ permission set. However, it does not necessary mean that it’s the case in the environment Your solution will be implemented in, especially if the .NET Framework is already in use.
Permissions sets are maintained at the machine and user levels through the tool, Caspol.exe (Code Access Security Policy), but it’s beyond this post to dig into it any deeper. However, there are two aspects that may be of importance here a) view the ‘FullTrust’ assemblies list and b) add an assembly to the group of ‘Fulltrust’.
The Caspol utility can be found in a folder like the following:
To view the present list the following command is used from a command Window: caspol -listfulltrust
as the following picture shows:
To add the ‘shimmed’ managed COM add-in’s file to the list the following command should be used:
caspol addFullTrust c:DevNotesNotesTool.dll
For an overall view of the security You can execute the mscorcfg.msc which is located in C:ProgramMicrosoft Visual Studio 8SDKv2.0Bin and it provide a graphical interface:
# Manually installation
If You suspect that the installation package doesn’t work as expected then one approach is to install the solution manually.
The following steps show how to ‘install’ the standard COM DLL:
1. Copy the files into a folder on a target machine.
2. Register the generated standard COM DLL with the regsvr32.exe.
The following steps show how to ‘install’ the ‘shimmed’ managed COM add-in without the standard COM DLL:
1. Copy the file into a folder on the target machine
2. Register the ‘shimmed’ managed COM add-in with the regasm.exe. For more information about the utility please see Assembly Registration Tool.
Any error message during the installation with the installation package and which also appear during a manually installation can also be an indicator that the present installation of .NET Framework is not working properly.
# Permission Calculator tool
For more complex solution then Notes Tool the utility, PermCalc.exe, can estimate the permissions that would be required for the application to run on targeting machines. It’s located in the C:Program FilesMicrosoft Visual Studio 8SDKv2.0Bin folder and in some cases under the Administrator’s folder in Document and Settings. For more information please see PermCalc
# Reinstall .NET Framework
Imagine that we have made all necessary steps correctly and the solution has been successfully deployed on all machines except for one where we receive an obscured errormessage upon installation. With this scenario there are no other alternatives (as far as I can understand) then to simple reinstall the .NET Framework.
# Access the tools
In order to use the Framework Configuration Tool and the Permission Calculator tool (together with some other tools) the .NET Framework SDK needs to be installed. For more information please see SDK.
Since it can be a rather complex situation with error trapping I would like to see that MSFT can provide us with a tool, similar to Microsoft PSS VSTO 2005 Client Troubleshooter, which can both document and track down general issues.
In my final post in the series of managed COM add-ins I will close the case with some conclusions and guidelines.