I have standalone setup project created with wix. And I need some solution for auto update my application.My application should check for new version on start up and automatically download and install new version if available.What's the best solution to do this? Can anyone give me some examples?Thanks.
If you use Burn as your bootstrapper/chainer (something I definitely recommend when distributing MSI files over the internet) then you can create a custom bootstrapper application that implements the update mechanism. This is how the WiX toolset updates itself. You can see the code in WiX v3.7 (or later) branch in src\Setup\WixBA\UpdateViewModel.cs.
Related
I work on WIX installer, I want the auto-update system that ClickOnce provide. I upload the new version on server and the end client can check online to see if there is a newer version available.
Can WIX do this?
Thanks.
You need to write something yourself to check for updates and download the new installer. Once you have the new installer, WiX can handle upgrading the version installed on the end user machine. Typically people have a secondary executable embedded within the main program which is responsible for launching the downloaded installer, so that the main program can close during the update process.
In the past, I've handled checking for and downloading updates with NAppUpdate, which is easily extensible for however you want it to behave. I'm sure there are plenty of other open source alternatives to handle this as well.
Wix does not have the capability to do so.
You can read the diffrences between ClickOnce and Wix (Windows installer) from:
https://msdn.microsoft.com/en-us/library/ms973805.aspx
I think you can wrap MSI in ClickOnce and use both.
Also you have Squirrel (Like clickonce) that is based on PowerShell but may not work on all target machines.
I am trying to create a new installer (using Wix) which will going to substitute the current one (InstallShield). Problem is many clients already have the application installed using the current installer. I need my new Wix installer to detect currently installed application perform the update or force the user to uninstall current application before running the new Wix installer.
I am new with creating installers. I need to know which GUIDs (and version numbers) must be the same for the system to know this is actually the same application just a new version. I didn't create the old InstallSheeld installer but I do have access to its code.
Thank you very much.
To uninstall the old InstallShield package, you should find out your old upgrade code and use that within your new WiX installer and do a major upgrade (which will ensure that the old package is uninstalled and removed). Check this Wix Upgrade document for doing the major upgrade.
Since we are on the topic, you can also make use of the Dark.exe to convert the current MSI into WiX source files.
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.
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 created a bootstrpper using the dotNetInstaller tool. The created bootstrapper internally has these installers:
.NET Framework 4.0
SQL Server Express
Now through WiX, what are the steps that I need to follow to invoke the above Bootstrapper from WiX?
You should not invoke a bootstrapper from WiX - that has no sense. The idea behind the bootstrapper is to "bootstrap" the prerequisites of the installation (.NET and SQL Express in your case) and the main installation package. The main package you generate with WiX should be launched from inside the bootstrapper when the prerequisites are checked and optionally installed.
See this article for better understanding how to start with bootstrapper authoring with WiX.
If you are using WiX to create installers, I would suggest using WiX to create your bootstrapper as well.
http://wix.sourceforge.net/manual-wix3/authoring_bundle_intro.htm
You can only invoke packages from using bootstrapper, you can't invoke it from WiX. By the use of dotNetInstaller you can easily invoke one after another. One of the process as #Yan introduced. By the help of prerequisites folder. It is a very efficient and popular process. But what can I suggest for you, invoke link instead of folder. So your installation full package wouldn't not so bulky. Whatever the msi need it can directly download from internet and install it one after another. Follow the link.
http://www.codeproject.com/Articles/5116/dotNetInstaller-Setup-Bootstrapper-for-NET-Applica