I have been experiencing a problem since changing over to NetOffice with my COMAddin, but only for some users who were using the VSTO version of the addin. Developed using Visual Studio 2010 SP1, Visual Studio generated msi, and Wix bootstrapper to deal with 32 and 64 bit Office versions, it's an addin for PowerPoint.
The issue is when loading the addin in PowerPoint is "Location: mscoree.dll. Load behavior: Not loaded. A runtime error occurred during the loading of the COM Add-in." Registry setting for the Addin's LoadBehavor changes from 3 to 2.
I have researched for months and applied so many of the suggested changes from msdn, stackexchange and codeplex that I am now out of ideas and perplexed as to what else I need to do to get it working. Users uninstall the old version and deploy the new NetOffice version and then the addin never works again. Here's some details of the things I've implemented or changed to get it working but without success. The only way to solve is for the user to get a new computer, so assume it's an issue that is resolvable in the registry/file system/GAC/CLR/Shim/Fusion/etc.
Bootstrapper details
- Two Wix bootstrappers developed one a current user install and another for an all user install.
- Each boostrapper detects whether 32bit or 64bit Office is installed and calls either the embedded 32 or 64 bit msi installer.
- End user is given one bootstrapper or the other
=> No issues here from Wix install logs.
msi installer
- four msi installers built an included in the two bootstrappers, one for each office bitness and All User (UAC prompt)/Current install (no UAC prompt) option
- The Target Platform set specifically to x86 or x64, rather than AnyCPU to avoid issues of incompatible bitness with office bitness
- Registry entries seem to be deployed to the correct places for both the Current User and All User installs
- Files are deployed to the correct place for the Current User (C:\Users\xxx\AppData\Local\MyAppName\AppName.dll + NO DLLs
- Files are deployed to the correct place for the All Users (C:\Users\Public\Documents\MyAppName\AppName.dll + NO DLLs
- msi's are signed and timestamped
- MyApp DLLs are strong named and signed
=> Files and registry entries seem to be in correct locations for all of the four MSIs
Addin code:
- ComVisible flags set to true for the class and main project, and other classes as required, false for everything else
- The addin Inherits COMAddin Implements Office.IRibbonExtensibility, IDTExtensibility2
- OnConnection code is in a try/catch statement and debugs/exceptions written to text file
=> Code is working fine for most users, but some who had the old addin installed never have the first line of the code executed
Startup
- Netoffice and MyApp addin's DLLs and dependencies (resources and XML serializers) are being loaded correctly as reported by Fusion (Default)
- Some errors reported by Fusion for Native Issue, but apparently these should be ignored?? (http://stackoverflow.com/questions/9734919/what-is-this-fusion-log-saying - see Hans Passant response)
- if the DLLs are not found, even a probe file for POWERPNT.EXE.config to find the correct DLLs is in place and Fusion reports successes, but even when the DLLs are found the addin still doesn't load
- The first line of OnConnection code does not seem to execute on computers with issues
- LoadBehavor is changed from 3 to 2 and error " Load behavior: Not loaded. A runtime error occurred during the loading of the COM Add-in". Addin is not in disabled items - just not ticked to load anymore on startup.
Some things that may be outstanding for consideration or comment:
- Cached versions of old dlls causing - how to find/remove them to ensure there is not some conflict 9even though the probe file should point the CLR to the right location?
- Use of the GAC? But if all DLLs are loaded assume this is not required? GAC also breaks ability to run a the No Admin installer
- Shim issues - if the DLLs are being loaded and the first line of code is not executing, could it be something in between like Shim?
- Any other suggestions related to an addin working on VSTO and then changing to Netoffice that I need to take into account?
Any assistance or pointers appreciated.
Comments: ** Comment from web user: scottaj **
Some great questions ekirk0 - let me expand to see if it shines some light on the problem:
1. 32/64 bit office detection strategy: The 32 or 64bit msi installer is launched depending on the detection of existence of PowerPoint Path from the 32 or 64bit branch of the registry - HKLM\SOFTWARE\Microsoft\Office\X.0\PowerPoint\InstallRoot\Path (where X is 12, 14 or 15)
=> There is no obvious issues here that I can find as the 32 and 64 versions are installed for new users without an issue. However for existing users the installer installs correctly, the registry entries are ready, DLLs are loaded as shown by Fusion, but addin errors after DLLs are loaded and therefore changes LoadBehavior from 3 to 2. Have I missed anything here?
2. Differences in new vs upgrades: The issues seems to be on installing a new version of the Addin when an existing version exists. This is mostly from the old "All User" VSTO version of the addin to the new Current User or All User NetOffice version of the addin. The Current User msi install (no admin permission required) deploys files to c:\Users and registry entries to HKCU, while the All user (Admin UAC) deploys to the Program Files ([ProgramFiles64Folder] for 64bit, and [ProgramFilesFolder] for 32bit msi) and HKLM registry. The "Current user" msi won't uninstall the old Addin as it requires Admin permissions, but even if the user manually does it themselves, there is still an issue. How can I find if something is cached or force the addin to look for the new version of the file in a new location? Maybe the MyAddin.DLL.Manifest Addin registry setting to force PowerPoint to find the location of the new files?
3. This is an interesting article that I hadn't come across in months of research and does show a nice mechanism to add a HKLM registry into the HKCU on startup. However, as I am successfully deploying the current user key to this branch, I don't really see any advantage. Is there something else that the UserSetting registry does here that I've missed?
I did notice the orphaning issue of addin registry branches on uninstall if DeleteUninstall = False, but as I set DeleteUninstall = True I changed the uninstall of the old msi within Orca to occur before the install of the new version. The result is slightly slower to install, but guarantees the registry branch will remain in tact no matter whether the old version DeleteUninstall is set to True or False, as the uninstall is done first rather than last.
Thanks