I am having some difficulties with installing an Excel addin at my client. I have created an installer for the addin using the instructions at http://www.clear-lines.com/blog/post/create-excel-2007-vsto-add-in-msi-installation.aspx, and it has been successful for the majority of users. The installer was run as an admin and this seemed to work ok. However for a small proportion of users the installation was unsuccessful - the registry entries are created but the addin does not load when Excel starts and does not appear in the addins list. Trying to add it manually from the installation folder gives an error that the addin is not valid.
To complicate matters slightly, the client uses both Vista and XP (although all installations of Excel are 2007). None of the XP machines have installed the addin successfully, whereas most (but not all) of the Vista machines have been successful.
Has anybody had any experience of this, or might be able to point out where I am going wrong?
Many thanks in advance,
Rob
There were changes to various user profile paths between XP and VISTA. If you've hardwired any paths like \Users\username\Application Data, etc, you may not be installing things quite right under XP, where the path would typically be \Documents and settings\username\Application Data.
Finally, if an addin isn't loading, about the only causes are
1) the reg entries pointing to it (or to the MANIFEST in the case of VSTO) either aren't there or aren't right.
2) the addin has some prerequisite or dependency that you've missed, and since it's not there, the addin loader is just failing to load the addin.
For 1), just check the reg entries for all the right values, then add a msgbox or some logging in your addin to verify that it is, indeed, at least being initially loaded by Excel.
For 2) I'd read up on the Fusion Loaded Viewer and use that. Fusion is the .net "loader" service, and it can be setup to log all sorts of detailed info about where it's looking for preqs, which one are found where, and which can't be located.
Details here
http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx
Related
I'm using Advanced Installer to try to create an installation package (single EXE setup file) for an MS Project VSTO add-in. I need the installation Type to be Per Machine but when I chose this option and run the setup.exe file, the Add-in will not load for any of the user's on the target machine. The only way I can get it to load is if I change the installation type to Per User, which I don't want.
I'm fairly certain the problem is related to the registry, because the setup.exe is not adding the proper registry keys under HKEY_LOCAL_MACHINE to load the add-in, even though I have it set up to do so:
What am I doing wrong?
There are other things that needs to be done except windows registry keys. For example, you need to specify whether you want to support per-user or per-computer installations.
The Deploy an Office solution by using Windows Installer article describes all the necessary steps for creating per-use and per-machine Office add-in installers. Make sure that you did everything in your installation package.
First let me get this stuff out of the way:
This happens with my own addin, as well as another third party VSTO add-in, so I don't think I'm doing anything incorrect
.net 4.0. VSTO runtime 10.0.50701
Windows 8. Also tried Windows 7
I am using the |vstolocal suffix in the HKLM registry for the addin
I have also tried adjusting the 'program files' paths in the registry here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion to point to my new 'F:' location, and that didn't change any behavior
Here are the steps I'm taking:
Create a new volume on a separate disk other than C:. I called mine 'F:'
Add the program files structures F:\program files and F:\program files (x86)
Install your VSTO addin (I'm using Outlook but it will happen with Word too) to "F:\program files (x86)" instead of the 'C:' drive
Launch Outlook.
Result is this dialog:
According to this, I shouldn't be getting this since its an all users install (see the Inclusion List section):
Is this a Microsoft issue? I realize I can add to the Inclusion myself however then I would be subscribing to more of a per-user approach, and that seems like a bad approach. Is this coming up because anything other than the 'real' program files folder cannot really be trusted by VSTO loader?
The dialog window belongs to the ClickOnce installer. But the link goes to the Windows Installer section in MSDN.
It is up to you where to install the add-in, there is no need to use the Program Files folder.
Make sure that you did all the steps described in the Deploying an Office Solution by Using Windows Installer article. It describes all the required steps for creating add-in installers.
I recently went through the same thing, i got this when i just published the vsto from vs2015. I tried using installshield, yielded the same issues, eventually i switched to wix installer, now i don't have any update checks running and its a clean install. These are some customization updates and our client actually had a firewall blocking it so the install failed. Try wix it worked great for me. Hopefully you don't end up with my current issue of not seeing the add-in if i am not running outlook as Administrator, driving me nuts, good luck.
I'm following the excellent tutorial by Malte Ahrens on how to create a OneNote add-in.
Initially I followed it step by step, making a few changes (just renaming the class, and using my own name and GUID in the assembly) info. As I'm using VS2012 and am not yet ready to hand-roll a WiX installer I manually copied over the built dll to the correct place and also created a registry file to make the requisite entries. I confirmed that they were all there, loaded up OneNote but no add-in, going to "mange COM addins" section I saw the following error:
Load Behavior: Not loaded. A runtime error occurred during the loading of the COM Add-in.
I spent some time debugging this but didn't get very far. So this afternoon I decided to start again but copy his code verbatim. I simply downloaded the example project, used the trial of Vdproj to Wix to create the installer and built everything.
I get the exact same error.
Why is this please? What does this mean and most importantly how do I debug the problem?
A few specifics about my environment and where it may differ from the original tutorial.
I am running Office 2013 AND it's 64bit. His tutorial is for 2010. This means when I loaded up the demo solution I had to remove the non-existent reference to the Onenote 14 Interop and add the v15 version.
In terms of registry entries they go to the right place, not the WOW6432 registry nodes. I doubly know this as if I load up OneNote and then refresh the HKCR registry node for the add-in, the LoadBehavior switches to 0x00000002, (disabled).
Other things that may be worth noting.
I have enabled OneNote logging and it's quiet on my issue.
There are 2 other posts on here with a seemingly similar problem (but Office 2010) here and here, neither got a response. The first guy had it loading once, but then had to manualy start it each time, mine never loads (and I've not signed my assembly) the second guy never got a response.
As I say, even knowing how to debug this further would be a great step forwards.
Edit:
I've gone back to debugging my own version, which is almost identical anyway as I'm not sure what the installer is actually doing and I think because it's a demo of the wix converter it's only allowing me to build for x86.
If I add OneNote.exe under "start external program" and run debug on my add-in, I see the following lines appear when I try and tick the add-in under "manage COM add-ins" within OneNote. I'm afraid I'm still pretty green at all this so I'm not sure what it means.
First-chance exception at 0x00007ffe4f86ab78 in ONENOTE.EXE: 0x800401FD: Object is not connected to server.
First-chance exception at 0x00007ffe4f86ab78 in ONENOTE.EXE: 0x800401FD: Object is not connected to server.
First-chance exception at 0x00007ffe4f86ab78 in ONENOTE.EXE: 0x800401FD: Object is not connected to server.
Also, since reading up more I think me simply copying my dll into the install folder program files\[manufacturer]\[application] (as I don't have an installer) was not enough. I've now executed this against my dll
PS C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319> .\RegAsm.exe
and it came back with
Microsoft .NET Framework Assembly Registration Utility version 4.0.30319.33440
for Microsoft .NET Framework version 4.0.30319.33440
Copyright (C) Microsoft Corporation. All rights reserved.
Types registered successfully
Is there anything else I should be doing to register the dll correctly?
Enable logging for OneNote 2013:
Create a file "EnableOneNote2013APILogging.reg"
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\OneNote\Options\Logging]
"EnableLogging"=dword:00000001
"EnableTextFileLogging"=dword:0000001
"ttidLogObjectModel"=dword:00000001
"ttidLogObjectModelAddins"=dword:00000001
Create a file "DisableOneNote2013APILogging.reg"
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\OneNote\Options\Logging]
"EnableLogging"=dword:00000000
"EnableTextFileLogging"=dword:0000000
"ttidLogObjectModel"=dword:00000000
"ttidLogObjectModelAddins"=dword:00000000
This is based on http://blogs.msdn.com/b/descapa/archive/2006/12/08/debugging-the-onenote-api-enable-logging.aspx but you need to add EnableTextFileLogging ;-).
The logfile is created in %temp%\OneNote.log
For OneNote 2010 change the path in the .reg files to \14.0\ instead of \15.0\
I am working on deploying my first Visual Studio Tools for Office (VSTO) add-in using VSTO 4.
There are some different options for installing the Add-In registry entries. It can be per user under HKEY_CURRENT_USER or per machine HKEY_LOCAL_MACHINE. A number of my users are running under Citrix or Terminal Services. I am in a situation where an administrator will be running my install on the server as the users do not have the correct rights. In addition, my users are only a small percentage of the users on these servers.
For those reasons I was planning on building a small utility that would ship with the Add-In. The utility would create the correct Per User registry keys to enable the add-in. The administrator would install the add-in dll and my utility to c:\program files*. Then the users who actually needed the add-in would be instructed to run the utility one time and click on the "Enable" button.
The problem I am stuck with now is how to uninstall the add-in. My un-installer (run again by an administrator) can deal with everything that it created but does not have a way to remove the Per User registry keys.
I was hoping this would be a problem and that Word would just ignore the missing Add-in on the next startup.
That does not work - Word reports an error trying to "install" the customization on the next run.
"Installing Office customization"
There was an error during
installation. Downloading file
file://xxx/xxx.vsto did not succeed.
I am including "|vstolocal" at the end of the registry entry per the Registry Entries for Application-Level Add-Ins msdn article.
Is there anyway to stop Word from trying to load the add-in if the file does not exist?
or
Is there a way for an uninstaller to clean up Per User registry entries on uninstall for a user other than the one running the uninstall?
I am doing my testing on a Windows 7 machine with Office 2007. I am using VSTO 4 targeting the .Net 4 Framework.
About your two questions
Is there anyway to stop Word from
trying to load the add-in if the file
does not exist?
Not that I'm aware of, but, I just tried moving off the DLL's the my reg entries point to for one of my addin's and I got no message (if I go into Word's options COM ADDins area, i can see the addin is not loaded, which would be correct).
Is there a way for an uninstaller to
clean up Per User registry entries on
uninstall for a user other than the
one running the uninstall?
Nope, I'm virtually positive there is no way to do this. It'd require rights to EVERY user's Profile folders.
HOWEVER, you can create these weird keys under the Office reg tree, that essentially serve as "commands" for office apps to carry out when they load.
So on uninstall, you'd write the extra keys to the Office reg key that essentially says "remove these keys from the current HKCU hive when an office app loads".
Here's an example Reg script I found that shows the weird keys, but I can't right off find any links that document exactly what they are:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\AllUsersTemplates]
"Count"=dword:00000001
"Order"=dword:00000008
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\AllUsersTemplates\Create\Software\Microsoft\Office\12.0\Common\General]
"SharedTemplates"=hex(2):-fill in your own Binary Value-
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\RemoveInstantSearchBar]
"Count"=dword:00000001
"Order"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\RemoveInstantSearchBar\Create\Software\Microsoft\Office\12.0\Outlook\Search]
"DisableDownloadSearchPrompt"=dword:00000001
<<<<< CreateFile >>>>>>>
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\FileCopy1]
"Count"=dword:00000001
"Order"=dword:00000008
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\FileCopy1\CreateFile\FileCopy1.potx]
"TargetFile"="[AppDataFolder]\\Microsoft\\Templates\\FileCopy1.potx"
"SourceFile"="C:\\Documents and Settings\\All Users\\Templates\\FileCopy1.potx"
If you look closely, you'll see under the \Office\ key, a "user settings{name}\Create\" key and then the rest of the key path replicates the path from Software\ on down under HKCU.
You can use the keywords CREATE or DELETE (to remove a key).
Notice the COUNT and ORDER values though. Those are important and need to be set right.
But again, i can't find the links off hand that document this.
You could use an Active Setup to uninstall your per-user VSTO add-in.
If you're unfamiliar with Active Setup, this feature compares HKLM Installed Components subkeys to HKCU Installed Components subkeys and if a subkey is missing (or if found and the subkey Version value is greater) the StubPath value is executed and the HKLM Installed Components subkey is copied to HKCU Installed Components.
Disclaimer: Active Setup is an undocumented, yet frequently used, Windows feature. Use at your own risk. Do not taunt Active Setup.
I have an outlook addin that I have been developing for some time now, and am experiencing a problem. If I have a computer with two 'administrator' users (call them User A and User B), the addin installs and runs just fine as long as the same user tries to run it. In other words, if User A installs the addin, then User A has no problem using.
The strange behavior comes in when we see the following scenario: User A installs the addin (for all users), User B launches outlook and observes that the addin is trying to install itself yet again. If User B cancels out of the 'install', he can then go and use the addin just fine.
Right now, I use office's registry key propagation to do an 'all users' install,
and I inspected the registry for any duplications and found none. I even used the officeins tool to try and detect if there was any duplication going on, and found none.
I'm really bewildered as to why the addin would try to install itself over and over again. Does anyone know why this might be happening?
This has to do with junk being absent from the registry (at least in my case). Using the 'Event Viewer' in windows will allow you to look at the MSI installer logs that point to what registry key was missing.
Here is a great article about installing an outlook addin for all users:
http://blogs.msdn.com/mshneer/archive/2007/09/04/deploying-your-vsto-add-in-to-all-users-part-i.aspx