My IT dept. is telling me that usually apps copy the install MSI to ProgramData\PackageCache and updates the registry key to point to this location. They want me to do this. The registry shows this for other apps:
My apps are not doing it like that as you can see.
How do I get my apps to copy the MSI to the Package Cache folder and change the InstallLocation registry key? Is there a setting for this in the Setup Project or do I have to do these two steps with a custom action to copy the file and a registry action to edit the key?
This is the first time for me making installers so I'm a little new to it.
The behavior you are describing comes from installing an installation package (like an MSI) via a WiX Bundle. If you aren't using a Bundle, you shouldn't find your package in the "Package Cache".
Related
I've developed an Outlook addin that perfectly works with my outlook. I used our organizational code signing cert and used ClickOnce. Now I want to deploy it on a small group of machines (piloting). I followed this to create an MSI. The problem here is it copies all the files to C:\ with I double click on the setup.msi. But when I run it as an admin, it copies the files in the right location. Below is what I get from the msi log file.
MSI (s) (84:FC) [13:43:15:553]: Ignoring disallowed property TARGETDIR
MSI (s) (84:FC) [13:43:15:964]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'C:\'.
What am I doing wrong?
Looks like you need to change the target folder of your installer. Most probably you chose a folder which requires admin privileges for writing.
You may find the Deploy an Office solution by using Windows Installer article helpful.
With Visual Studio Setup Projects the main reason for this is that the installing user does not have admin privileges, as you seem to have discovered. These VS setup projects switch to a per-user non-elevated install when the user is not privileged. Among other things, this means that the install can't create files and folders in restricted locations (the Program Files folders and others) so the install gives you a separate isolated install in C:. The ALLUSERS value in a VS setup project is 2, and as the documentation here says:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367559(v=vs.85).aspx
you can get a per-user non-elevated install if the user is not privileged. Windows won't let limited users write to restricted locations just because it's an install.
Is it possible to get pug in project for Outlook that is depend on NuGet packages to be installed with Microsoft Visual Studio 2017 Installer Projects? I’m trying to create an installation file for a plug in for Outlook that have a drag and drop functionality dependent on the Easyhook Nuget package. That the plugin have a taskPane with a webbrowser there are drop Outlook e-mail messages as .msg files.
It works to install the plug in but the drag and drop functionality that is dependent on the NuGet package doesn’t work. That I can drop the message but the webpage doesn’t recognize the drop mails as .msg files or even as uploadable files. While if I try with the trial version of InstallShield 2018 Express Edition everything works including the drag and drop functionality.
I tried to do the same thing with Installer Project as with InstallShield. To output I added content files, debug symbols and primary output. Files I added was the manifest and vsto files for the Plugin and the .dll file for the NuGet Package, Easyhook32.dll. I got an error because the content file included the 64bit for the NuGet Package files, and I’m doing a 32bit installation, and also that the Easyhook32.dll file was duplicate, that it seems that the dll file also was added with the content files.
So, I excluded the 64bit files in the plug In project that should be installed and in the installation project I removed Easyhook32.dll files from the files that should be include in the installation. Also then it worked to install the plugin but the drag and drop functionality didn’t work. I also tried to for example not add the content files and just add the Easyhook32.dll and that also made the installation work except the drag and drop functionality.
I can of course also try other installation programs that is able to add NuGet but also are able to be installed from the Internet and also add registry keys and values. That I also have tried Microsoft Click Once installations program and it was easy to create an installation files but it seems like you need a valid certification if you want users to download the installation file from the Internet.
Also, this is the first time I working with type of installation like this ones and with Outlook Add In so I can have missed some obvious solutions. That at the same time english is not my first language so I can also have missed using the correct terminology.
NuGet is a build-time package manager. You'll need to redistribute any required binaries in your installer package by adding them manually. Typically, required binaries from NuGet packages will be copied to your output folder, so you could add them from those paths just like your project output.
I have created an installer package using VS 2010. The setup is working fine.
It includes a msi package file and an external config file.
When I run the installer, and if the software is previously installed, instead of upgrading it, can we just change the config file?
If yes, how ? Please suggest
Regards,
Gagan
How did the config file get copied to the system in the first place?
If it was with custom action code then what might work is a repair of the existing installed product. If the CA condition allows it, then the code will be called again and do another copy of the new file.
Otherwise the answer is no. The supported upgrade in a VS-generated MSI is a RemovePreviousVersions major upgrade.
If I knew in advance that updating the config file separate from the product was going to be a requirement, and it's used by an installed application, then I'd make it app's responsibility to have a choice to load a new config file. By tying the config update to an MSI file the design effectively limits the update choices to what's available in VS setup project updates (RemovePreviousVersions).
I want to update a VSTO addin for word I create without let VSTO automatic update launch. In fact, my end-users have not enough rights for installing.
I only want to update it, not install because first install will be done with vsto installation from VS publish folder with administrator rights.
To update, I copy
MyWordAddIn.dll
MyWordAddin.dll.manifest
from publish folder to appData folder where my addin is installed.
When I launch my word document which is linked with my VSTO file. I have an error
Sorry for french, It said that there's already another version which is installed.
But when I launch it the second, third... time, I have no error.
It appears that you did not disable ClickOnce from automatically installing updates on application startup. That would explain why your application is detecting that there is a new version in the publish folder and attempting to install the update. Then, the error is occurring because you already manually updated the DLL in the appData folder, so when it see's that publish folder contains a DLL with the same version number, it gives the error stating that it's already installed.
You can disable the autoupdate by going into your startup project's settings in VS, clicking the publish tab, and then press the update button and set it to never check for updates.
Just FYI, ClickOnce installations themselves do not require administrative privileges. The prerequisites may, but the installation of the actual ClickOnce app does not. That's why it gets installed under the user profile. So once the user has the prerequisites installed, you can use the automatic updates, unless in your case the user can't even write to his own profile folders.
You could also just run the following command from the command prompt:
rundll32 dfshim CleanOnlineAppCache
You wouldn't need to change any update settings. Any newer versions would update from the specified location when found during the specified update interval.
I have an update to third party .DLL that must be installed onto my clients' computers. We currently employ automated installs via MSI that are created in Visual Studio 2010
Unfortunately, the third party .DLL was versioned incorrectly and file version of it was not increased by the provider (they only increased assembly version). The third party provider is Microsoft, so waiting on them to fix the issue is not realistic. We need to get the new .DLL to people now and within one MSI update. Right now, MSI update is not overriding the .DLL
Is there a way within VS2010 Setup project to force override a .DLL even if the file versions match?
If you are willing to do msi postbuild tweaking you can hit the File table and do "version lying". Another thought is to not put that DLL in your install. Find an installer from Microsoft ( if it exists ) that you can put into a bootstrapper or create your own installer and use AMUS instead of OMUS for the version rules.
Can't you just add the file to your installer as a 'file' and install it with the other files? Don't set it as project output, or any of the canned install actions. Go to the file portion and right click the "Application Files" folder, and say > add file. Navigate to the file that you want and choose it.