I have a fresh WIX UI Install project in VS which compiles down into an MSI. Everything is working great with it.
It installs/uninstalls the files I want successfully. For example, it drops 3 DLLs into a Program Files folder, installs a Windows Service, and GAC's a DLL.
Now let's say I install on this in a given environment. Then one of our DLLs change and we need to upgrade this install without affecting other files already installed (such as the service) So my thought would be I would need a patch/upgrade MSI that would target that one DLL and just overwrite that particular file.
What is the simplest way to accomplish this? Do I need VS projects essentially for each patch/update MSI? Below is my current 2 WIX related projects (installer + custom action)
For updating just the DLL a patch is recommended. Visual Studio doesn't support patches, but you can try using WiX: http://wix.sourceforge.net/manual-wix2/patch_building.htm
Please note that patches have some restrictions: http://msdn.microsoft.com/en-us/library/aa367850(VS.85).aspx
A MSI which overwrites just one file is a bad mistake because you are not using the Windows Installer update mechanism.
If you want a MSI, it will have to be a major upgrade. A major upgrade will automatically uninstall the old version before installing the current one.
Related
My Visual Studio 2008 setup project is changed so that merge modules for MFC and VC have replaced DLL's that were installed manually in the installation folder. I'm okay with merge modules, but there is a problem. In previous setup user could choose between "Everyone" and "Just me". In new setup this choice has no effect, and installation is always for everyone because of merge modules, which must be installed for everyone. So, if previous installation was "just for me" then new installation does not remove DLL's of previous installation, and in Control Panel there are two installations with the same name.
In setup project of new version ProductCode is changed, UpgradeCode is not, RemovePreviousVersion is set to true, and Version is higher than it was before.
If I exclude merge modules from setup, and install new version "just for me" then all is well. Old files are removed, and there's only one installation in Control Panel. But I would rather not burden users with separate installation of redistributable packages.
How can I in Visual Studio 2008 setup have both merge modules, and instruct setup to remove previous version, even though previous version was "just for me", and new is for "everyone"?
Mаybe better question would be what would you do in my place to resolve this issue?
Windows Installer (handler of MSI files) will not uninstall one product during the installation of another. Also, the same installation is viewed as two different products when installed both per user ("just me") and per machine ("everyone"). It is therefore nothing you can do from .msi to uninstall old per user installation if new is to be installed per machine.
Options are, ordered by preference:
Make bootstrapper installation (.exe) that would seek and uninstall all that needs uninstalling. Bootstrapper is also preferred way to install prerequisites, instead of doing with merge modules.
From .msi you can just detect that something is wrong, and stop the installation. I've done this, but will work on first option as well.
Ignore the problem, say it's by design, and do nothing. It's all in the hands of the user.
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.
I have a web setup project built using VS2008. I've converted my solution to VS2010 and now when I build my new installer and run the install from the MSI it installs fine, then at the last step, removes all the files it's just installed.
I have RemovePreviousVersions set to true. If I turn this off the files remain in place (but I get multiple instances in the Programs and Features in the control panel).
If I run the install again, the files reappear. From then on, the files always remain, even when installing another version. So, the problem seems to be with running an installer built using VS2008 and then running the same installer built by VS2010. The upgrade GUIDs on each installer are the same.
What is the cause and how can I fix this?
I haven't tried porting a setup from VS2008 to 2010, but having the same upgrade code for different build versions will cause problems; simple explanation is the msiexec installer fails when it tries to remove the old components because the older components have the same upgrade version as the newer components being installed. There is a VS project setting where you can automatically generate a new upgrade code each time you rebuild your .msi; I generally select this and saves a lot of these versioning headaches.
Uninstall all copies of your app using
add/remove programs
Delete the contents of your %TEMP% folder ( to
get rid of any "old" (VS2008) copies
of your .msi)
Update the GUID for the VS2010 version (I think you do this by right clicking on the
GUID in the properties window and clicking "genereate new GUID")
rebuild the project and try again!
I just encountered this error. Had the exact problem when upgrading. I tried the solution at:
https://connect.microsoft.com/VisualStudio/feedback/details/559575
I edited my MSI-file in Orca resequenced RemoveExistingProducts right after InstallInitialize (sequence number 1501). This was found in the InstallExecuteSequence table. This was originally sequence number 6550.
That solved my problem.
What I've discovered is that changing the UpgradeCode will prevent the files from being removed, however it's then treated as a separate installed program - i.e. in the control panel (Programs and Features) my program appears twice. Logically, I think, this is because it's not the same program.
My only option seems to be to programmatically uninstall the old version in the installer of the new version by writing a custom action.
I've submitted a bug to Microsoft Connect and they've confirmed it's reproducible.
I'm using a VS 2008 Setup and Deployment project to deploy a mixed managed / unmanaged application. I've had trouble registering mixed-mode DLL's using the built-in registration property ("vsdraCOM" enumerated value of the "Register" property.) As a workaround, I've added a .NET custom install assembly (with a class that derives from System.Configuration.Install.Installer.) I'm certain that that class is running and a number of operations successfully install and uninstall through code in that assembly, including executing the Dll(Un)RegisterServer entry point of a number of assemblies.
However, one DLL is not successfully registering. It is the only DLL that depends on some 3rd-party redistributable assemblies that want to be installed to the GAC. I have those assemblies installed to the GAC thanks to the built-in support for that in VS 2008's setup and deployment projects, and I know that is working. I've confirmed that what is happening is that the custom action is executing before the installer executes the GAC installation.
Whew. So my question is, is there a way to force the installer to execute the GAC installation before executing the custom action? Is there a way to use the "Condition" property of the custom action to do this? If not, what's my best alternative? Capturing the registry entries from the DLL and adding them to the registry settings for the installer (don't like this because someone may add new COM servers to the class in the future)? Using .NET code to install the assembly into the GAC manually (don't know how to do that yet)?
Thanks,
Dave
The setup projects you can create in Visual Studio are very limited. It only allows custom actions to be scheduled at 4 points. However, MSI allows custom actions to be scheduled at any point in the process with some restrictions on what they can do.
My first solution is to stop using Visual Studio 2008 as your setup development tool. The Visual Studio team has tried to abstract away all the complexity of creating an install. However, in the process they have also taken away all the flexibility of MSI. Wix, InstallShield, or Wise are much better products for anything but simple installs. I started off using Visual Studio for our installs and it ended up being too much work. There was always one more workaround to be implemented and its side effects to be dealt with.
If you can't switch technology, then you will need to learn how to manually modify the resulting MSI file. In your case you will need to modify the InstallExecuteSequence table, http://msdn.microsoft.com/en-us/library/aa369500(VS.85).aspx. You can do this manually through Orca, http://msdn.microsoft.com/en-us/library/aa370557(VS.85).aspx or through the MSI API http://msdn.microsoft.com/en-us/library/aa372860(VS.85).aspx. Make sure to download Orca and run the validation scripts against your install. The scripts point out numerous problems that fixing will save you countless hours when deploying to customer machines.
I have a Windows Forms application with an installer (.msi) already created with Visual Studio. I am now creating a new installer for version 2.0 with the property RemovePreviousVersions set to true.
Now, when I install 2.0 over 1.0 it removes 1.0 and installs 2.0 completely.
Is there a way that I can tell the installer if you find some files already installed (like .xml files used for data) then don't override them?
I am trying to have my 2.0 installer serve the 2 purposes:
Install from scratch for new users
Existing users will upgrade but not lose their customizations
The deployment project in VS does not overwrite files. What happens is that since you have RemovePreviousVersions set to true, when you change your program file version and the ProductCode GUID of the setup project, it will first uninstall the previous version and then will do a clean install of the new version.
To make sure some files don't get overwritten, I usually exclude them from the Content or Primary output files (wherever they are located) and then add them separately to the setup project. Doing this, you can individually set properties for those files. The property you are looking for is called Permanent" that if set to true will never uninstall the file in question, and therefore will never overwrite it with a new version. The only drawback with this is that when you uninstall the product, the Permanent files will not get removed from their target locations, but in my case (usually local DB files), that's a good thing ;)
Cheers!
[edit] The above is true for VS 2008 SP1. Haven't tried it on other versions, so hopefully you are using the same VS version or it works for the version you use.
[edit2] Oh, also you could also use the "Condition" property to achieve something similar. If you do that, make sure that "Transitive" is set to True so the Condition is always evaluated. Haven't tried it with Conditions, but that's another option you could look at. Other than these 2, I think that's pretty much it for VS deployment projects.
When I was in a similar situation what I did was:
The files that were customized by each user and should NOT be touched by the installer were NOT included in the MSI (NOT in the Visual Studio Setup Project). When the app was run for the first time I generated the XML files through the code.
The files that were static (e.g. data that was used to populate Dropdownlists) I included in the MSI and I can update those by building a new MSI with Visual Studio.
Basically don't include customizable files in your MSI project. Create them in code for new users.
I never looked into telling the MSI not to update certain files that are included in the MSI file. The solution I came up with was perfect for me. I don't know if it can be done.
I hope this helps.