Installing .NET based COM Addin
Martin Böhm posted great HOWTO on microsoft.public.office.developer.com.add_ins newsgroup. I am publishing it here (with Martins permission :)), I added a screenshot and formatted the text:
I have read many threads, where people have problems installing their .NET Based COM Addin on other machines. Instead of answering multiple threads, I start a new one.
The three main problems are:
1. Addin is not loaded correctly (automatically unloaded)
2. Runtime Debugging: Addin
3. Storing Application Settings for the Addin
1. The Addin is not loaded correctly
The Addin works fine on a the development machine, but if the setup is installed on a non-development machine, the addin does not start. Before the addin is started for the first time the corresponding load behaviour registry key:
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftOfficeMS ProjectAddinsMyAddin.Connect]
is set to 3.
After the office program has been started for the first time, there is a short break while loading the application and the registry key is automatically set to 2.
The problem has to do with the sequence the classes that are contained within the .Net dll are registered for COM Interop.
I was able to reproduce this behaviour the following way:
- Try to use internal classes or functions instead of public ones whereever possible.
- If public functions have to be used, make sure that they do not use .NET classes as parameters (your Addin is like a COM AddIn to the office
application, therefore you can't use parameters that are not defined inside COM)
I know this might sound weird to you but make a small test. Create a new Addin with a public function that uses a custom class as parameter, and try
to install it on a different machine, then set this function to internal and try again.
2. Runtime-Debugging
Many people wonder why they can't debug their Addin - Instead a new instance of VS.NET is opened.
To use the runtime debugger take a look at your project properties. In the Configuration Properties section you have the Debugging options. In the section Start Action you can set the Debug Mode.
You might have to set debug mode to Program, apply your changes and then select the start application e.g. winproj.exe (yes, Microsoft was unable to add an event to the debug mode dropdown list which automatically enables/disables the other dropdown
lists. But don't worry, they had this feature in VS2002 and 2003, I'm sure they'll keep it in other versions too ;-))
Set a breakpoint in your Addin and press F5 to run.
3. Storing Application Settings for the Addin
As we have a .NET DLL application settings should be saved in the .config file of the calling application. If you have an addin for Word the
configuration file would be winword.exe.config, if you write an addin for Excel the configuration file would be excel.exe.config. As you know, there
are different versions of Office applications, the configuration file must be copied to the Office, Office10 or Office11 folders, depending on the version which is installed.
You see, if we decide to create an Addin for different Office applications supporting different versions we should think about where to save the
settings. I prefer to save it to the registry, no matter if it is recommended or not. It's much easier for the netinstall team to update a registry key on a client machine, than to exchange a complete file.
If you have any feedback get in touch with Martin:
Interested in mailing me? Here's my email (please read from right to left and use COM Addin as keyword in the subject line so your email is not considered as spam): ed[dot]socyl[at]nitram[hyphen]mheob
or post a comment (click on that "chain" grfx :))