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
Troubleshooting
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.
‘Avoid …’
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.
‘LoadBehavior’
By default the loadbehavior is set to 3 (Connect | Bootload) and therefore it should load when the host (Excel) is launched.
‘Blacklisted’
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.
‘Deployment issues’
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:
C:WINDOWSMicrosoft.NETFrameworkv2.0.50727
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.
# Finally
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.
Kind regards,
Dennis
Hi Dennis,
VIIII does not exist. IX is better. Excel could have helped you as you probably know with the formula “Roman” ;-)
Cheers.
Surely you mean part IX??
Thanks!
I’m more confused then ever, especially when it comes to .NET ;)
And before anyone ‘gracefully’ points out to me: Yes, I’m aware of the ROMAN-function in XL.
Kind regards,
Dennis
Dennis,
This was superb, as usual. But my-oh-my this is a lot to digest, eh? One can tell that you’ve done a ton of experimenting here.
You know, just when I was getting the hang of Automation enough to start thinking about Managed COM Add-ins, your series here shows how challenging this really is. At it’s core, there would seem to be two central issues/problems to address:
(1) One is that Marshal.ReleaseComObject() is basically global in scope — you can release you’re own COM instance (this is good), but you can also just keep calling it, or call Marshal.FinalReleaseComObject() and release all COM objects handled by all un-shimmed COM add-ins (this is bad, lol). I guess the shim, then is the solution to this mess, and you’ve made it clear that when using a shim simply setting the variable = Nothing is the appropriate solution in this case. (Nice and simple!)
(2) The other issue you brought up which is interesting is that without the shim, the mscorree.dll is the “identity” for all Managed COM Add-ins. So I guess if any fail then ALL of them would find themselves disabled? Related to this, I wonder where the ‘Disabled items…’ list is within Excel 2007? I can’t seem to find it…
Nice job Dennis, clearly there’s a lot to be aware of when making Managed COM Add-ins. I’m going to have to print your stuff out and read it a few times…
Mike
Mike,
Thanks for Your kind comments :)
(1) That’s right and don’t forget that we have also has an unmanaged COM DLL that increments/decrements the internal reference counter of the COM objects.
(2)>>list is within Excel 2007? I can’t seem to find it…
Which probably mean that when Excel 2007 hit the market the updated VSTO 3.0 will include a similar add-in template as now is available for Outlook in VSTO 2.0. It will rely on the manifest based VSTOLoader.dll which load add-ins in separate AppDomains and will then also solve the ‘mscorre.dll -hell’.
What is important and notable is that as long as Excel require a COM interface to communicate via there will always be a need for a’loader’, which actually put an extra ‘layer’ between Excel and the ‘managed’ add-ins no matter how we view it.
Kind regards,
Dennis