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.
Related
I have an old installer that is made with InstallShield 2015, its non-MSI based (I tried opening it with 7zip and could not --> non-MSI based, am I right?).
In general, I need to stop using InstallShield and migrate to Wix.
Is it possible some how to convert InstallShield it to Wix?
Using Wix, I need to detect if a previous version (the InstallShield version) is currently installed and automatically uninstall it and then continue with the normal Wix process. Is such a thing possible?
Thank You :-)
I'll add a quick answer for reference, though the problem appears solved already.
If the old Installshield setup is an MSI, you can use dark.exe from the WiX toolkit to "disassemble" an MSI into WiX source code (dark.exe can also decompile WiX setup.exe bundles - there is a somewhat messy description of this here: How can I compare the content of two (or more) MSI files?).
After some cleanup you can compile the WiX source to a new WiX-built MSI. A bit of knowledge and experience is needed for the cleanup to be successful (eliminating GUI sections, add a WiX GUI, realign source paths, clean up binary stream tables, etc... - not trivial, but not rocket science :-).
If the old setup was a legacy installer (not MSI), you can convert it to MSI by using a repackager tool to capture changes done to the system during installation and convert them to an MSI. A lot of knowledge is required to clean up such a capture. If you know the product it is often better to code a new setup "by hand". Or if you are in a large corporation chances are you will have a "repackaging team" available somewhere who will have the expertise to do this job for you.
Yes, old setups can be uninstalled as part of your new MSI.
As you discovered if the old setup was an MSI you can simply use a major upgrade to remove it during the new WiX install.
If the old version was a legacy setup things can get considerably more involved often requiring you to "record" a dialog response file to feed to the uninstaller function of the old setup.exe file. Not at all trivial, and quite error prone. Incidentally one of the major benefits of MSI is the completely suppressible GUI.
For reference, here is an old answer with information on dealing with the infamous setup.exe files that we frequently have to uninstall and upgrade:
How can I use powershell to run through an installer? The setup.exe can be many different things: Installshield Setup, Advanced Installer Setup, Inno Setup, Self-Extracting Zip-Archive, a proprietary setup format, the list goes on...
I would like to create a installer (like BootStarper) to achieve following steps using WiX.
There will be a setup.exe file.
Upon Runnig this file it has to open a UI and show the list of softwares (MSI) available for installation.
The software products are grouped into two Group A or Group B.
Each group may contain Two or more MSI files (Both internal and third party files)
Allow user to Choose a group and one or more products to be installed.
Based on the selection, the products should be silently installed on the local system.
Shall I create a WiX project and display given products(MSI) as its features and can start a deffered custom action to install the seleted ones?
How to author my WiX project to choose the groups and then selected features?
Any help would be greatly appreciated.
Upgrade to WiX 3.6 (Beta) and take a look at the new "Burn" functionality.
You cannot use a deferred custom action to install another MSI because there is a mutex that enforces one running execute sequence per machine.
There is functionality in MSI 4.5 called multi-package transactions however MSI 4.5 may not be already installed on a 2003/XP/Vista Machine so you'd need setup.exe to boostrap it anyways.
Also "concurrent" installs are deprecated and should not be used to do servicing issues.
This is not something you can solve either with the stable WiX release, or Windows Installer.
You will need a separate bootstrapper to launch your MSI files. as the WiX bootstrapper, Burn is only in the WiX 3.6 beta release and not yet properly documented I would suggest trying something like dotNetInstaller.
I have been using InstallShield LE in Visual Studio 2010, but it is heavily limited and sometimes buggy. I looked at paid InstallShield versions, but these also have too many limitations for that price tag.
So I decided to switch to WiX. I have had some experience with it some years ago. It was pretty easy to build a simple installer using SharpDevelop with WiX tools.
Now I am trying to collect solutions and tools for WiX. Basically, I need to get the following functionality (requested by my client):
when I launch the installer, it should check a text file on the server and see if a newer version is available. If it's the case, then the installer should be able to download the updated installer package and launch it (are there any downloader utilities in WiX?)
solving dependencies. Major dependency of my app is .NET 4 (which itself depends on Windows Installer 3). The installer should offer the user to download and install them automatically
logging the installation process, also collecting the log file of the dependencies' installation process. I don't want the user to hunt various .log files in case .NET4 or WindowsInstaller3 installation fails. All the information should be collected in one place and if something fails, I should show the user a custom popup dialog with an option to save the complete install log file and send it to me
installer should be able to detect if there is a newer version of my app already installed, and show a meaningful customized error message before it exits
installer should be able to detect if there is an older version of my app already installed. and offer the user to exit installation or uninstall the previous version and install the new version. BTW, there are no minor component upgrades planned, I prefer to reinstall everything fresh (I guess, this is a major upgrade in the terms of WindowsInstaller). Installshield LE failed on me for this, it just showed an error box with the message about another product, but did not offer to uninstall it
in case of an upgrade, installer should be able to detect if some of application components are in use (running application processes) and show a custom error message and not just some cryptic "Installation failed"
I have read that it may be a bit painful to manage upgrades even if I keep my UpgradeCode intact, because this code is stored in the Windows Registry in a compressed way and also if the user renames the downloaded file, it might get detected as a completely new product by WindowsInstaller ... or maybe this is only the case with WindowsInstaller .msi files and WiX has some trick to avoid this issue?
About update downloading - I need this functionality also in my application itself. I am not sure how to implement it efficiently, so I can reuse the same update downloader code/utility in both WiX installer and in my app.
Is it possible to satisfy all these requirements using currently existing WiX tools, or maybe I'll need to code some components from scratch?
WiX is definitely the way to go in my opinion.
when I launch the installer, it should check a text file on the server and see if a newer version is available. If it's the case,
then the installer should be able to download the updated installer
package and launch it (are there any downloader utilities in WiX?)
In my opinion, this type of functionality is best handled by the application. However you can implement such functionality in a custom bootstrapper. The latest development of WiX includes a bootstrapper engine Burn that allows you to write your own custom bootstrapper on top of it.
solving dependencies. Major dependency of my app is .NET 4 (which itself depends on Windows Installer 3). The installer should offer
the user to download and install them automatically
You can use the standard WiX bootstrapper to install .NET as a prereq. Or if you create your own custom managed bootstrapper application, you can install .NET a prereq to your bootstrapper as in this example
logging the installation process, also collecting the log file of the dependencies' installation process. I don't want the user to
hunt various .log files in case .NET4 or WindowsInstaller3
installation fails. All the information should be collected in one
place and if something fails, I should show the user a custom popup
dialog with an option to save the complete install log file and send
it to me
Using the two bootstrapping methods above, when you launch your msi you can specify parameters for logging. In my own custom managed bootstrapper I created a button to open the log files created during installation.
installer should be able to detect if there is a newer version of my app already installed, and show a meaningful customized error
message before it exits
You can do this using launch conditions
installer should be able to detect if there is an older version of my app already installed. and offer the user to exit installation or
uninstall the previous version and install the new version. BTW,
there are no minor component upgrades planned, I prefer to reinstall
everything fresh (I guess, this is a major upgrade in the terms of
WindowsInstaller). Installshield LE failed on me for this, it just
showed an error box with the message about another product, but did
not offer to uninstall it
In my experience this major upgrades are the least complicated
approach.
in case of an upgrade, installer should be able to detect if some of
application components are in use (running application processes) and
show a custom error message and not just some cryptic "Installation
failed"
I think WiX/Windows Installer are generally good at handling these
scenarios and automatically notifying the user that
files/applications need shutdown without you having to author
anything extra in your installer.
All that said, you may want to look into creating your own custom managed bootstrapper using WiX and Burn. That is not trivial however. The best place to go is to download the source code to the WiX Weekly Releases and checkout the project src\Setup\WixBA. It is the custom BA that they wrote to install WiX. There isn't much documentation out there yet because WiX 3.6 is not released (although it is pretty stable). However you don't have to create your own BA to make a solid WiX installer that can handle upgrades and logging.
I'm looking for a tool (preferably not InstallShield, and also preferably cheap/Free) that supports Chained MSI Installations. I've got several small installations that need to be able to be deployed separately, but also as one group, and I'd like to not have to maintain multiple installers.
It looks like I need Windows Installer 4.5 to do this properly, but I can't seem to find to much info when I'm looking around for what version of Installer is supported.
The MSI 4.5 functionality is just a set of APIs that allow bootstrapper/chainers to do smarter things for multiple MSIs. You still need a bootstrapper/chainer to install multiple packages. In WiX v3.6 there will Burn.
Incidentally, it used to be possible--although not particularly easy--to "nest" or embed other MSIs into one parent, but it involved tweaking custom actions and such to ensure that the nested programs were removed upon removal of the parent, etc. Sadly, this feature is "deprecated" and thus no longer recommended by Microsoft. Here's how to do it in a Visual Studio installer project... but creating a bootstrapper with WiX would be more advised.
What you need is a bootstrapper. Using and InstallShield or Wix will created an MSI themselves which when that is running will not allow the other smaller MSIs to run. If you already have the smaller MSIs to run a bootstrapper is all you need.
MSDN has a free one you can download that plugs into VS2008 and uses MSBuild to compile. What you will probably need to do is create packages for your MSIs and put them in the bootstrapper as prerequisites. This will allow you to set it up to run them in a particular order.
Here is the MSDN link: MSDN Bootstrapper Manifest Generator
Look at NSIS
I'm trying to find a solution for the following issue:
I have numerous programs (lets call them slaves) that all rely on a single program (master). I need to distribute an installer for each slave. This installer needs to install the master.
I want to be able to version both pieces, so multiple msi's appear to be the right solution, chained with a bootstrapper.
My problem is if a slave installer installs the same version of the master that is already installed, the .msi will run in repair/remove mode.
This is unacceptable from a user standpoint and will just cause confusion.
Is there any way to check for a version of the currently installed fiels before trying to run the msi?
I am currently using WIX's setupbld.exe as a bootstrapper.
Any other solutions greatly appreciated (I have also tried merge modules with no success, since the versioning is useless)
Instead of using setupbld.exe (which I don't really know as I can't find any documentation) you can use msbuild's generatebootstrapper task. The wix documentation already covers how to use this task to generate a bootstrapper that installs the .NET framework. See How To: Install the .NET Framework Using a Bootstrapper. This makes use of the pre-defined bootstrapper packages.
However, in this case you will also have to author your own bootstrapper packages. One way to do this is to study the existing bootstrapper packages in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\ (or the ones in the Windows SDK) and read the documentation of the Bootstrapper Manifest XML format. The bootstrapper generator tool might also be helpful.
To determine whether the package needs to be installed, you can use one of the InstallChecks to set a property, and then check the property value in a InstallCondition under the Commands element.
If you're thinking that this is all harder than it should be — I agree, but it's what I've used so far. There are some alternatives which I have not tried yet:
the poorly named dotNetInstaller
which is actually a general purpose
bootstrapper generator.
the wix 3.5 burn bootstrapper which is not yet released. I'm not sure if it is in a usable state yet.