I need to launch an MSI depending on the version installed on the target machine.
To elaborate:
MSI shouldnt install if its version is less than the currently installed version.
Otherwise it should do REINSTALL using REINSTALLMODE=omus.
I know that this can be done by wrapping the MSI within a bootstrapper application or using cmd to launch MSI.
But could this intelligence be implemented within the MSI itself, so that it appropriately launches itself when I double-click it?
Will LaunchCondition or CustomAction help to achieve this?
I am using Visual Studio Setup Project to build my MSI. Will using WIX help to achieve this?
Thanks,
-Kunal
The first can be done inside the MSI but the second cannot. The MajorUpgrade Element has the AllowDowngrades and DowngradeErrorMessage attributes that implements a detect and block pattern.
The second isn't possible because it's immutable once the MSI starts. You need to invoke from bootstrapper such as burn to achieve this.
Related
I have a working WiX installer with a custom UI using a WixUI_Mondo_MyApp.wxs file. I have to extend my installer to also run another exe installer. I understand Burn is the way to do this.
I created a Burn project that chains my original MSI with the custom UI (using DisplayInternalUI="yes"), and that works fine. But I don't want two UIs popping up (the Burn default UI, and my MSI UI), and I need to get some info from the MSI UI to determine if I should install the other exe (it will listed as one of the features).
I suppose the proper solution would be to migrate my UI code from my MSI to my Burn project, but I can find no docs on describing how to do this.
Thanks in advance.
There is no migration path; MSI UI is declarative using the MSI UI tables and Burn supports arbitrary code in a bootstrapper application. If you have any logic in your UI customizations, you'd have to write a custom bootstrapper application to get that in a bundle.
Are there are any templates or guidelines for creating a Windows Installer XML (WiX) project for deploying a Petrel plugin?
Are there any reasons for WiX not having been selected as the natural successor to the old *.vdproj/MSI recommendation?
Has anyone tried WiX for Petrel plugins? I'm interested in exchanging ideas and experiences. I'm new to WiX, and find it difficult to get started.
(Off topic: the "new" PIP paradigm is lean and simple, but is a bad fit for enterprise use, where clients expect to be able to repackage an MSI in order to facilitate mass deployment through e.g. group policies. I'll post another question on this.)
MSI deployment is still supported in Ocean/Petrel regardless of the way of MSIs generation (and WiX is just another way to generate them).
In Ocean/Petrel 2012.1 you need to define custom action calling command-line tool PluginManager.exe with /install and /uninstall switch during the installation and uninstallation steps respectively. Custom actions are defined using <CustomAction> tags in WiX. There are two tricks you need to keep in mind when calling PluginManager.exe from MSI custom actions:
you need to supply your MSI installer ID (usually GUID) in /installerId:your_installer_id command-line switch during the installation. This will enable automatic MSI uninstallation of your plug-ins when Petrel is uninstalled
you need to run PluginManager.exe with /runFromInstaller switch during the uninstallation. By doing this you let PluginManager know that you run it from MSI installer, and so there is no need to run MSI uninstallation once more
You can find these and other tips and tricks, with full PluginManager.exe command line speicifications in the Plug-in Identity and Deployment White Paper in Ocean.chm (section "How to use PluginManager.exe in MSI installer").
Important information with Petrel 2013:
We have plugins that can be installed or uninstalled using MSI, created with Wix. When installing a PIP with PluginManager.exe without using the argument /installerId:<msi_installer_id> uninstalling the plugin using the Petrel physically deletes all your files, but create an inconsistency in windows uninstaller plugin. If we use the argument /installerId:<msi_installer_id> uninstalling the plugin using the Petrel occurs only logical deleting the plugin, keeping it physically in their original directory. This allows it to be installed subsequently also by Petrel. In the latter case, there is no inconsistency, because the windows uninstall the plugin and be able to delete all your files.
The problem is that uninstalling the plugin using the Petrel 2013 is not calling its MSI uninstaller. It should not be? This looks like a bug.
Is there a way i can uninstall (and dont upgrade after) a previous version of my app, using an upgraded MSI (created in WIX)?
Is that possible at all?
Sorry, I missed the part with:
and dont upgrade after
I haven't see this done before. Why don't you just use the MSI from the original application to launch the uninstall?
If you want a simple double click package that performs the uninstall you can create an executable, doesn't matter the programming language, that executes this:
msiexec /x {..<product code>..}
I have .Net product with msi installer implemented using WiX. Now it is possible to run several instances of my installer at the same time. I am wondering whether it's possible to restrict run more than one instance of installer at the same time?
Thanks.
Only one .msi will install at a time, but you can open the UI of any number; nothing in MSI prevents it.
my application requires the microsoft visual c++ redisributable package (vcredist_x86.exe).
i have a custom action to run the vcredist_x86.exe
i want it to run only if it's not already installed. i created a registry search to check it.
the question: how do i run this action with the check? when using the InstallExecuteSequence element, as shown below, the vcredist_x86.exe crashes because you cannot run an msi while running a different msi
thanks,
Uzi
what you need is a bootstrapper that would install the VC++ redistributable before your MSI starts.
i'm using open source dotNetInstaller and it works pretty well.
Don't use the exe at all. To distribute the VC++ runtime in an msi-based install, use a merge module. No custom actions, no conditions to add, it just works.
Aaron Stebner's blog specifically talks about doing this with WiX.
http://blogs.msdn.com/astebner/archive/2007/02/13/building-an-msi-using-wix-v3-0-that-includes-the-vc-8-0-runtime-merge-modules.aspx