Outlook 2003 Add-in won't load, but is in working order

Question

I have created an Outlook add-in for 2003, 2007 & 2010. The add-in works fine in 2007 and 2010, but is not loading correctly in 2003 on any machines, other than my own dev machine. There are no code issues, as there are no errors shown in the load behaviour, and it is not a disabled item. The add-in is also not shown in the list of COM Add-Ins. This add-in has worked under 2003 previously.

Here's the strange part. I have a copy of the add-in from an earlier point in time, so does not contain some of the features of the full version. This add-in loads correctly in 2003. So as part of my testing, on a VM, I installed the earlier version (I'll call it test) and the current version which doesn't work (I'll call it full). In the registry under HKCU > Software > Classes > CLSID > [[guid]] > InprocServer32, for the test version I changed the 'Manifest Location' and 'Manifest Name' keys to be the values of the full version. I then ran Outlook, and the full version ran perfectly.

I can't see how the full add-in does not work under it's own registry settings, but works fine under test's, and only on Outlook 2003.

Here's the basic info:

My dev setup is:

• Windows 7 64-bit
• Outlook 2003 installed
• Running VS2008 for the Add-in project, but also use VS2010 for a satellite assembly.
• Set Security project is included and amended to allow multiple assemblies to have CASPol set.

The following pre-reqs are included in the setup project:

• .Net 2.0
• .Net 3.5SP1
• Office 2003 PIA (also 2007 & 2010 PIAs for 2007 & 2010 respectively)
• VSTOSE runtime
• Windows Installer 3.1

Any hints would be greatly appreciated, as I've spend nearly 4 days on this issue!

TIA.

---

Update 1:

As per @JoaoAngelo comments I checked the registry settings, and they are as follows:

HKCU > Software > Classes > CLSID > {add-in CLSID} > InprocServer32

 - (default) - '%CommonProgramFiles%\Microsoft Shared\VSTO\8.0\AddinLoader.dll'
 - ManifestLocation - path to the containing folder
 - ManifestName - the .dll.manifest file name
 - ThreadingModel - 'Both'

HKCU > Software > Microsoft > Office > Outlook > Addins > MyAddin

 - (default) - not set
 - CommandLineSafe - '1'
 - Description - a string
 - FriendlyName - add-in ID
 - LoadBehavior - '3' (this never gets set to 2, which would indicate an issue)
 - Manifest - path to the .dll.manifest of the add-in assembly
 - Path - path to the containing folder

I also added the following under the latter, as per the Deployment page, but to no avail:

 - ManifestLocation 
 - ManifestName

Update 2:

As per 0xA3 comments; Under HKCR > MyAddin I have a CLSID key with a single string value:

(default) - {add-in CLSID}

The CLSID is the same as seen in HKCU > Software > Classes > CLSID and throughout the registry.

Answer 1

I finally managed to find the issue, it was registry related.

I originally planned to have separate add-ins for each version of Outlook, and as such my namespaces and naming conventions etc were:

• [Company].AddIns.Outlook2003
• [Company].AddIns.Outlook2007
• [Company].AddIns.Outlook2010

However, I managed to create the add-in to target all 3, so I renamed [Company].AddIns.Outlook2003 to be [Company].AddIns.Client.

I'd changed the registry settings for HKCU > Software > Microsoft > Office > Outlook > Addins > MyAddin, to reference the change described, but for some reason I didn't update it under HKCU > Software > Classes.

As soon as I changed the latter settings in VS, it worked!

For reference the changes were made in VS under the Setup Project, under View > Registry.

A bit annoying that this issue didn't appear under 2007/2010, as it may have been easier to track down.