What can cause Outlook to change a COM-addin's LoadBehavior to 2 - other than unhandled exceptions?

Question

For some weeks now we have been fighting with an issue where at a small number of customers our Outlook addin gets unloaded and disabled for yet undetermined reasons. By \"d

Answer 1

maybe you are a lockback policy victim. add a bypass key to registry, then it works. modern office versions or vsto creates the key while installation. the effect is: install a modern office too and the affffdin now are also loaded in older office. please take a look

code snippet taken from NetOffice http://netoffice.codeplex.com

public static void RegisterFunction(Type type)
{
            try
            {
                // add codebase value
                Assembly thisAssembly = Assembly.GetAssembly(typeof(ExampleClassicAddin));
                RegistryKey key = Registry.ClassesRoot.CreateSubKey("CLSID\\{" + type.GUID.ToString().ToUpper() + "}\\InprocServer32\\1.0.0.0");
                key.SetValue("CodeBase", thisAssembly.CodeBase);
                key.Close();

                key = Registry.ClassesRoot.CreateSubKey("CLSID\\{" + type.GUID.ToString().ToUpper() + "}\\InprocServer32");
                key.SetValue("CodeBase", thisAssembly.CodeBase);
                key.Close();

                // add bypass key
                // http://support.microsoft.com/kb/948461
                key = Registry.ClassesRoot.CreateSubKey("Interface\\{000C0601-0000-0000-C000-000000000046}");
                string defaultValue = key.GetValue("") as string;
                if (null == defaultValue)
                    key.SetValue("", "Office .NET Framework Lockback Bypass Key");
                key.Close();

                // add addin key
                Registry.ClassesRoot.CreateSubKey(@"CLSID\{" + type.GUID.ToString().ToUpper() + @"}\Programmable");
                Registry.CurrentUser.CreateSubKey(_addinRegistryKey + _prodId);
                RegistryKey rk = Registry.CurrentUser.OpenSubKey(_addinRegistryKey + _prodId, true);
                rk.SetValue("LoadBehavior", Convert.ToInt32(3));
                rk.SetValue("FriendlyName", _addinName);
                rk.SetValue("Description", "NetOffice COMAddinExample with classic UI");
                rk.Close();
            }
            catch (Exception ex)
            {
                string details = string.Format("{1}{1}Details:{1}{1}{0}", ex.Message, Environment.NewLine);
                MessageBox.Show("An error occured." + details, "Register " + _addinName, MessageBoxButtons.OK, MessageBoxIcon.Error);
            }
}

Answer 2

Just to close this up: The problem did eventually turn out to be caused by a bug in the third-party licensing wrapper we were using. It has been confirmed by the vendor and was fixed in more recent releases.

Answer 3

My company has been putting up with what sounds like the same issue you are seeing for years. The plug-in we have is a VB6 COM add-in for Outlook 2003 and it’s deployed on several hundred machines that get cycled hundreds (if not thousands) of times a day. We go through the load and unload cycles a lot.

We get a fair bit of the general errors where the plug-in is loaded but not connected and we handle that in code. (Obviously not production quality)

Dim outlook As outlook.Application
Set outlook = CreateObject("Outlook.Application")
outlook.COMAddIns("MyFancyDancyPlugin").Connect = True

Rarely, but not so rare that it isn’t an annoyance, we see the plug-in reach a state where it is loaded and we can see it in “Tools>Options>Others>Advanced Options> Com Add-Ins”, but we just can’t connect to the thing. If you try to connect you don’t get an error it just switches back to disconnected. [The equivalent of switching back to a 2 in the registry key] The COM object as far as I can tell is never created. The item is not listed in the Disabled items.

We don’t actually have to redeploy to correct this error. Removing the object through the Com Add-Ins dialogue and then re-adding it there seems to correct the issue. This is still not an acceptable solution but it does get things back and running without a reinstall.

• Windows XP Professional, up-to-date patch level
• Outlook 2003 Professional, up-to-date patch level
• varying versions of McAfee Virus Scan (though disabling it has no effect - see above)
• Users are members of the local Administrators group

This seems to fit, we don't use McAfee but the virus scanner also doesn't interact with outlook or the com add-ins. We also don't use a copy protection app.

I'm sorry I can't be of more help, but I would love to root cause this.

Answer 4

I am also working on Outlook Add-In and I know one reason when the Add-In gets disabled. some time when Outlook shuts down abruptly or user forcefully shut down the Outlook, add-In gets disabled. I am not sure if this is the reason in your case but it could also give you some direction to think of. I some time use this method (closing the outlook using task manager while it is still loading) to simulate this behavior and actually I have developed a tool which scans all the machines provided to it and checks if the add-In is disabled on a machine and if yes it changes the registry value to enable it.

Answer 5

If you have the ability for your users to run a debug program to get more information about the problem when it happens, try using Add-in Spy from Microsoft.

http://msdn.microsoft.com/en-us/library/cc984533(v=office.12).aspx

I was having an add-in fail to load and discovered that it was happening because a dependency wasn't getting preloaded. This tool should be able to tell you what specific error is happening when the Outlook add-in fails to load.