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.
Related
Inside our .NET Framework 4.6.2 solution; we have a WiX project responsible for generating the .msi installer package for our WPF application.
The generated .msi installs fine on my machine, but not on colleague's computer.
After investigating for a couple of hours, we concluded that it was because of the nature of the D:\ drive on my colleague's computer.
The .msi was being run from an alias hard drive. He created the alias by following instructions here. So an alias drive is just a regular folder on C:\ but you turn that into an alias hard drive.
When the .msi is run from outside the aliased drive, the program installs without any problems, otherwise he gets these errors:
Clicking Retry doesn't do anything, but clicking cancel gives the following:
On my machine, I don't have any alias hard drives set up, and things just work, in other words, the program installs without any issues.
How do we get the installer to work with alias drives too?
This isn't supported by Windows Installer. The alias created by Subst only exists in the user profile that created it. MSI runs as SYSTEM and can't see it.
Subst Considered Harmlessly Useless: Yes, as Chris states we have both seen this before. MSI is an old girl, and newer Windows features or old ones that are weird cause such problems.
Workaround: In the realm of workarounds, maybe check features and / or transforms:
Optional Features: what is this D:\ drive? Is it his personal data storage? Are you installing files into "My Documents" or something like that? It you make a separate feature for the components going into the D:\ drive and then unselect that feature from installation, does it then install? (albeit with a few missing files). Screen shot of feature selection.
Transforms: There are also other ways to achieve the suppression of features and files from installing. You can use transforms - little database fragments - to apply runtime changes to a running MSI installer. More on transforms here. Shorter version here. And just one more.
Administrative Installation: You can (also) get hold of the missing files from another computer, or maybe by running an administrative installation of the MSI: What is the purpose of administrative installation initiated using msiexec /a? (glorified file extraction).
I developed an application with VS2010 and a setup deployment with IS Limited Edition. The application provides some data in a XML file, which is installed in the same folder. If the app was making changes in the XML file, this was saved in virtualStore.
I use now VS2015 and Wix Toolset. The application can be compiled and I was able to code a WXS File. The new built MSI install the app and all seems ok. But now the app cannot access the XML file. The access is denied.
I tried to compare both MSI with Orca, but don't see something noticeable. I'm not sure, if this is a problem of setup or of the application itself.
edit
If I copy the "old" EXE file in the new installation, the application can access the XML file.
Thank you for help and hints
If a program appears to be from before Windows Vista, is running as a limited user, and attempts to write to certain machine-only locations, Windows may redirect its access to the virtual store as part of a backwards compatibility shim. If the program does not appear to be from before Windows Vista, no redirection is performed.
I believe Windows detects whether a program appears to be from before Windows Vista by reading its manifest for supported platforms - the supportedOS elements in the application manifest. My guess is the change in your toolchain from VS 2010 to VS 2015 has resulted in this element being added to your application's manifest (Windows XP is past its supported lifetime and thus Visual Studio 2015 can implicitly assume you are supporting at least Vista).
You may be able to override the manifest, but really you should fix your program to not attempt to write to per-machine locations. Ideally you should use a location such as the LocalAppData folder, although for backwards compatibility there may be benefits to at least reading the old file from the Virtual Store.
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've created my first Office Add-in using Visual Studio. It targets the 4.0 .Net framework and was created using the new VS 2012. I need to distribute/install this project on various 32-bit XP and 64-bit Windows 7 computers around the office. So I configured the project to be installed on XP (which was my first speed bump because I didn't realize VS 2012 needed an update in order to make a solution that was XP compatible). Now that I have a valid win32 application, I am getting another error:
The following error occurred attempting to install 'C:\filepath...\Import Contacts.vsto':
"No application is associated with the specified file for this operation."
After doing some digging, I think I need to install the Microsoft Visual Studio Tools for Office Runtime on the client computer. To do this, I would like to use the prerequisites properties for the project. So I read up on creating custom prerequisites using some noteworthy sites (e.g, Creating Bootstrapper Packages, Application Deployment Prerequisites, Adding Custom Prerequisites, and Creating a Bootstrapper package for Office 2013 in Visual Studio 2012). I created the files according to that last URL (even though I'm not sure it pertains to the package I need just yet), but it is not appearing in the dialog box under Project > Properties > Publish > Prerequisites
If you read the article, it says the VS prerequisites dialog box should automatically update once I restart VS 2012, which I did but to no avail. I know I'll need to use this feature again in the future, so I would really like to know what I'm doing wrong and fix this. Please help! And I promise to quickly give the ACCEPT to whoever helps me fix this problem! Thank you in advance.
I didn't have any problems following the directions given in the web page and got the bootstrapper added to the Prerequisites dialog. However, there are plenty of possible ways to get it wrong. Some possibilities:
Triple-check the folder you added these files to. Be sure that you picked Program Files (x86) on a 64-bit version of Windows and not Program Files. And be sure that you now see the added VSTOR40 folder along with the other existing bootstrapper folders, like ReportViewer and VBPowerPacks.
You do not have write permission to this folder, UAC prevents copying files there. Be sure that you managed to copy them from, say, an elevated command prompt. Right-click the Command Prompt shortcut and click "Run as Administrator".
If you created the .xml files with Notepad then make sure you didn't accidentally saved them with the .txt extension. If necessary, put Explorer in "programmer mode" so you can see the filename extensions. Control Panel + Folder Options, View tab, untick the "Hide extensions for known file types" checkbox. If you now see product.xml.txt then rename the file to product.xml, same for package.xml.txt
If you created the .xml files with Notepad then be sure to save the file in UTF-8 encoding. File + Save As, Encoding combobox.
For all those who still may face similar issue I think that I found the cause of this issue. It seems that copying folder with custom bootstrapper package (and all necessary files in it) does not "refreshes" the list of available packages. Only when i went through this walkthrough and manually created folder in %Programfiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\ for sample package from this walkthrough my package has shown
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.