This project has moved and is read-only. For the latest updates, please go here.

Possible bug in 1.6/1.7 NetOffice.OutlookApi.Tools.ComAddIn

Nov 13, 2013 at 1:49 PM
Possible bug in 1.6/1.7 NetOffice.OutlookApi.Tools.ComAddIn:
                // register addin in Word
                Registry.CurrentUser.CreateSubKey(_addinOfficeRegistryKey +  progId.Value);
                RegistryKey regKeyWord = null;
                
                if(location.Value == RegistrySaveLocation.LocalMachine)
                    regKeyWord = Registry.LocalMachine.OpenSubKey(_addinOfficeRegistryKey + progId.Value, true);
                else
                    regKeyWord = Registry.CurrentUser.OpenSubKey(_addinOfficeRegistryKey + progId.Value, true);

                regKeyWord.SetValue("LoadBehavior", addin.LoadBehavior);
                regKeyWord.SetValue("FriendlyName", addin.Name);
                regKeyWord.SetValue("Description", addin.Description);
                if(-1 != addin.CommandLineSafe)
                    regKeyWord.SetValue("CommandLineSafe", addin.CommandLineSafe);
RegistrySaveLocation.LocalMachine never calls a CreateSubKey, so regKeyWord is null.

Should perhaps look like this:
// register addin in Outlook
        string registryKey = _addinOfficeRegistryKey + progId.Value;
        RegistryKey regKeyWord = null;

        if (location.Value == RegistrySaveLocation.LocalMachine)
        {
          regKeyWord = Registry.LocalMachine.OpenSubKey(registryKey, true);
          if (regKeyWord == null)
            regKeyWord = Registry.LocalMachine.CreateSubKey(registryKey);
        }
        else
        {
          regKeyWord = Registry.CurrentUser.OpenSubKey(registryKey, true);
          if (regKeyWord == null)
            regKeyWord = Registry.CurrentUser.CreateSubKey(registryKey);
        }

        if (regKeyWord == null)
          throw new System.Exception(string.Format("Unable to Open or Create registry key.", registryKey));

        regKeyWord.SetValue("LoadBehavior", addin.LoadBehavior);
        regKeyWord.SetValue("FriendlyName", addin.Name);
        regKeyWord.SetValue("Description", addin.Description);
        if (-1 != addin.CommandLineSafe)
          regKeyWord.SetValue("CommandLineSafe", addin.CommandLineSafe);
Nov 13, 2013 at 3:50 PM
thanks for your bug repsonse. i want clearify the situation asap. its important for me to know how you get the source code. in other words: is this NO 1.6.0 or NO 1.6.1(no official release) or NO 1.7 preview? (NO 1.6.0 contains a well-kown bug (same as you say) but its fixed in NO 1.7 preview. available in the download section) Sorry for this. In NO 1.6, the tools are just a nice idea and not published to anyone else. This is different in the upcoming NO 1.7 release. The tools namespace is now a full qualified member in the NO main strategy. this means: full test service(to avoid quality issues) and dedicated examples. i hope to release NO 1.7 this mounth and i'm realy sorry for any convenience.

*Sebastian
Nov 13, 2013 at 5:53 PM
Sebastian

These are 1.6.0 and 1.7 preview from downloads page. I've recompiled the code in NetOffice 1.7.0 (Preview)\Source to get to the bottom of a registration error for LocalMachine installation. (I was reading https://netoffice.codeplex.com/discussions/459474)

Also, as a side, but related note, is it necessary to populate the Wow6432Node registry elements if this node exists on the client PC as well ? e.g. HKLM\SOFTWARE\Wow6432Node\Microsoft\Office\Outlook\Addins\My.Addin


Chris
Nov 15, 2013 at 7:02 PM
hm okay,

this is may a OpSystem problem. did you use a 64 Bit operating system? (looks like NO does something wrong on 64Bit windows)

Sebastian