I have recently upgraded an Outlook add-in project from vs 2003 to vs 2005. Since upgrading I have had problems with deployment. It appears that the 2005 deployment package doesn't carry out all the registry entries and therefore the add-in isn't loading when deployed.
Am I missing something here or do I need to manually add all the registery entries in vs 2005 deployment (unlike 2003) Seems crazy! The add-in works fine when running it on the development machine.
To further complicate things...If I manually register the addin using regasm then registration is successfull on the development machine but fails on any deployment machine sighting that the file isn't found (even if I explicitly state the path to the file). Sigh...
Thanks.
Add-in deployment vs 2003 to 2005 problem
Flack
You don't specify, but since you say you've upgraded the add-in project from VS 2003 to VS 2005, this can only be a "shared" add-in project, not a VSTO add-in (because VSTO add-ins were not available in VS 2003).
There are two sets of registry entries required for such an Office add-in:
- the set that Office looks at first, under [HKCU|HKLM]\Software\Microsoft\Office\<app>\Addins\
- the standard COM registration keys, under HKCR.
When you create a shared add-in project, you are also given a standard setup project. The setup project includes the Office reg keys, but it does not include the COM reg keys. Here's an example of the Office keys for an Outlook add-in - and you can see these in the setup project via the registry editor:
[HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\MyAddin1.Connect]
"FriendlyName"="No Name provided."
"Description"="No Description provided."
"LoadBehavior"=dword:00000003
On a development machine, when you build the project it also performs standard COM registration on the add-in by invoking RegAsm (this lays down the COM reg keys). This is set by default in the project settings, where you will see that the assembly is set to be COM-visible and the build includes Register for COM Interop.
For example, building a shared add-in project will lay down COM keys similar to these:
[HKEY_CLASSES_ROOT\MyAddin1.Connect]
@="MyAddin1.Connect"
[HKEY_CLASSES_ROOT\MyAddin1.Connect\CLSID]
@="{9C0E6BC9-D381-46BE-9FE7-F39AF96D2803}"
[HKEY_CLASSES_ROOT\CLSID\{9C0E6BC9-D381-46BE-9FE7-F39AF96D2803}]
@="MyAddin1.Connect"
[HKEY_CLASSES_ROOT\CLSID\{9C0E6BC9-D381-46BE-9FE7-F39AF96D2803}\Implemented Categories]
[HKEY_CLASSES_ROOT\CLSID\{9C0E6BC9-D381-46BE-9FE7-F39AF96D2803}\Implemented Categories\{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29}]
[HKEY_CLASSES_ROOT\CLSID\{9C0E6BC9-D381-46BE-9FE7-F39AF96D2803}\InprocServer32]
@="mscoree.dll"
"ThreadingModel"="Both"
"Class"="MyAddin1.Connect"
"Assembly"="MyAddin1, Version=1.0.2595.24961, Culture=neutral, PublicKeyToken=null"
"RuntimeVersion"="v2.0.50727"
"CodeBase"="file:///C:/Users/<username>/Documents/Visual Studio 2005/Projects/MyAddin1/MyAddin1/bin/Debug/MyAddin1.dll"
[HKEY_CLASSES_ROOT\CLSID\{9C0E6BC9-D381-46BE-9FE7-F39AF96D2803}\InprocServer32\1.0.2595.24961]
"Class"="MyAddin1.Connect"
"Assembly"="MyAddin1, Version=1.0.2595.24961, Culture=neutral, PublicKeyToken=null"
"RuntimeVersion"="v2.0.50727"
"CodeBase"="file:///C:/Users/<username>/Documents/Visual Studio 2005/Projects/MyAddin1/MyAddin1/bin/Debug/MyAddin1.dll"
[HKEY_CLASSES_ROOT\CLSID\{9C0E6BC9-D381-46BE-9FE7-F39AF96D2803}\ProgId]
@="MyAddin1.Connect"
So, in order to correctly deploy this add-in to another machine, you need to make sure that both the Office reg keys and the COM reg keys are laid down. The simplest way to do this is to include the COM keys in the setup project. Alternatively, you can set the add-in DLL to self-register.