I'm still very new to Wix so i'm trying to get my head around how it works. There is a lot to it and its a bit hard to get an understanding of it. If my Wix MSI Contains a bunch of patch files. Can i use a Custom Action with extract the files to a temp location, run a patcher, update the version with the patched file version and then run any other MSI actions?
I'm not really sure how to do this in the XML. I Assume there is some sort of execution sequence
Also if this is possible i need a way to dynamically add the patch files to the MSI during the Build. Can you base this on an output folder?
WiX is far better than installshield and the like, but without seeing your existing .wixproj this is hard to answer directly. You can use custom actions to do all of what you want, but it's not exactly the "WiX way", as that would not be easily reversible for a rollback or uninstall. Dynamically adding files during a build is absolutely possible. I must absolutely direct you to Ramirez' WiX: A Developer's Guide for Windows Installer XML. I got stuck building a complicated installer like this, and this book was invaluable.
What I can easily say is that for the patching portion, you can run exec tasks to run the patcher program and pass the patch files you want to run. You can dump all of these to a temporary directory to do it.
Related
We use InstallShield InstallScript projects to create our installers and are looking for a good way to migrate to the WiX Toolset. As far as I know there is no UpgradeCode (as for MSI) to update from an Installshield InstallScript project to a WiX project.
The only solution I found so far is:
manually save configurations
uninstall the InstallScript installation completely
install the WiX installation
apply the saved configurations
Is there a better way?
Ok after all those comments I think I understand why this is such an issue. Unfortunately I don't think there is a very simple way to do waht you want to do.
I think your method will be the only real way to migrate from this isntallscript setup based installation. There should be some registry entry in HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Uninstall that relates to your product. In here there may be a uninstall command which you could read into a Variable from your burn package and pass that value as a property to your msi.
In you MSI you can have 3 custom actions specifically related to upgrading from the installshield product installation. All these tasks should be deferred custom actions so that they can run with administrator elevation. The first task should copy all the configuration settings to a safe place (generally %temp%\ProductConfig\ would be fine). The second part after saving the configuration would run that uninstall command to remove the product, you may need to append /q or something to make it run passively/quietly. Then at the end of the installation you can copy back the configuration files from temp.
Each of the custom actions should run conditionally on whether or not the property you passed in is set to something. I would schedule the copy cofig after InstallInitialize, the uninstall after the copy and the restore before InstallFinalize just to ensure that everything is copied over after the installer puts all the files on the system.
Ideally you would like to get everything to upgrade without the user needing to interact except in a minimal way by clicking next and Install.
I've only dealt with InstallShield enough to know I really don't like it so if someone else knows more and knows of a better way to do it they'll hopefully chime in.
Can someone help me understand how WiX works? I have a directory structure which I would like to create an installer for. I have generated the for the directory structure with heat.exe and when I build the setup project it generates an .msi file but I don't think it installs anything.
Maybe someone can walk me through the steps of generating a .msi installer.
Any advise is appreciated,
Thank you
If you're using Visual Studio:
Install the WiX Toolset V3 Visual Studio plugin.
Install the Wax interactive editor.
Build your project if you haven't already.
Add a new project to the solution containing the project you want to create an installer for.
Choose the template Setup Project for WiX v3.
Name the installer. A personal convention is the name of the project plus ".Setup"
A Product.wxs file will open up. Change the Manufacturer="" value to something like your company name or your name. Keep the file open.
Go to Tools -> WiX Setup Editor
On the left under Root Directory choose InstallFolder
Under Projects to install, choose the project you want to install.
In the red area to the right, you'll see a list of files. These are the output results of your build from step 3.
Click the plus sign next to files you want to copy. They should turn white and change to a Resolved state.
This might look daunting, but you're just telling it what to copy--which would be your project's executable, configs, dll libraries, and images it's dependent upon.
You typically want to copy everything. If there are dll's you know you don't need, it's better to remove them as a dependency from the Visual Studio.
Notice the Product.wxs has changed. It now has the files you checked off in the Setup Editor GUI added to the <Wix><Fragment><ComponentGroup> section. Save that file.
Close the Setup Editor.
Build the setup project you just configured.
Open Windows explorer and go to that project's bin/Debug or bin/Release folder, depending on what mode you built in. There you'll see the .msi that you can copy to where you need.
To make an update, make the necessary changes and then change the version number in that project's Properties -> Application -> Assembly Information. Then also change it in Product.wxs <Wix><Product.Version>. Then just build your setup project again.
Good tutorial here:
http://wix.tramontana.co.hu/
http://www.codeproject.com/Tips/105638/A-quick-introduction-Create-an-MSI-installer-with
They should get you started.
If you learn something about the MSI log that will also help - install the MSI with a command line that includes /L*vx
And "doesn't install anything" should be easy to check - are there are any files installed, or did it create an entry in Programs&Features?
WiX is a language (XML/XSD) that serves as a way of authoring (compiling) Windows Installer (.MSI) databases. WiX doesn't install anything, MSI does.
I maintain an open source project called IsWiX. The concept is simple. IsWiX provides additional WiX project templates (scaffolding) and graphical designers to assist you in creating installer. Then as you gain knowledge of WiX and MSI you can make additional tweaks of the WiX XML by hand and go beyond what IsWiX currently knows how to author.
Here's a video showing how to author, build and test an MSI to deploy an IIS website in a mere 3 minutes.
Update: IsWiX has tutorials now.
After a few 'false starts' trying to learn WiX from online tutorials I noticed that on http://wixtoolset.org/ there is a link to the book "WiX 3.6: A Developer's Guide to Windows Installer XML". You can buy it pretty inexpensively in E-book form from Packt, or also Amazon if you like the easy interface with Kindle.
I found this book to be VERY helpful with every little step regarding the .msi creation process. The book will guide you to create your first .msi in the very 1st chapter! Granted, you have to continue a little more to have a fully functioning .msi, but given the complexity of Wix, this book is terrific. It may not be for the gurus among us, but for those of us who need a little more help to understand the material it's wonderful. I've seen many posts speak to the 'steep learning curve' regarding WiX and it is a complicated process to create a valid .msi, but this book goes a long way toward making that learning curve very bearable.
If you are using the build system 'cmake', then you can use cpack to generate .msi file by setting the cpack generator to wix.
What worked for me best, was this fantastic tutorial video: https://www.youtube.com/watch?v=6Yf-eDsRrnM
Its best selling points for me was
independent of visual studio version
it describes deploying a .NET (Core) app also
it focuses on what an average app's installer should be capable of (including heat, icon, background image and banner)
you don't have to learn another layer on wix
it gives you good practices on easy package generation and future maintenance
it gives an installer project template which you can reuse: https://github.com/angelsix/youtube/tree/cecd38ea3d5eea11cc75fc0123297ffc3b5e662b/C%23%20General/Windows%20Installer%20Wix%20DotNet%20Core/ConsoleApp1.Installer
My existing WIX works fine. It allows the user to select a number of features, and when the user proceeds after feature selection, it runs a customaction to install the files using command lines tools. (My features relates one to one with files that just happen to be VSIX files that are installed using VSIXINstaller.exe from the command line customaction).
This has been working fine for months, and to date it has included all the files in the installer package itself. The files are first put on disk, and then the command line customaction is run on them locally.
However, my installer has grown quite large to download on its own (because it includes all the feature files that could possibly be installed), and it is preventing people bothering with the download. Becuase most of our users will only select one of the features (not all), what I want to do is host the individual files online somewhere at know URLs, and change the installer so that depending on what features the user selects, download each feature file in turn, save them to the same local folder and run the same cutomaction on them (like before).
So really this is just a change to the installer that already works file when the files are packaged within it. Now instead of having the files within it, they are fetched from a URL first.
Can anyone give me some guidance how to do this?
I'm not sure that you should be using Windows Installer at all but you are benefiting from the feature selection tree. If you are willing to replace that with a custom GUI (e.g., with WinForms or WPF), you could use a WiX Bootstrapper project. It provides for installing ExePackages with downloadable payloads.
You could also split your MSI into one per feature and use those with the bootstrapper.
See this demo, this article and the WiX source code for WiX's bootstrapper.
I am trying to make my Wix Burn installer install two applications that use NSIS for their installer. Install works great. However, I want them to be removed when I uninstall my app (Permanent="no"). This is not so straightforward as I cannot call a different exe (the uninstall.exe that is created) from the UninstallCommand property on he ExePackage. Is there another way? Is there a simple command line argument that an NSIS installer can take to uninstall?
You would have to request the author of those installers to add support for that, NSIS does not support it by default.
I don't even think it makes any sense for installers to support it:
The same program could be installed multiple times on the same machine (single user and all users?, multiple versions?)
What if the installer does not write to the registry, how is it even supposed to find the original install?
Not what I would call a perfect answer, but a functional one, so I thought I'd share. Save someone providing a better option, I am creating custom actions to handle the uninstall. NSIS is consistent (by default, anyway) in their uninstall policy. Knowing what that is, I can plan for it. Messy, for sure, but seems sound.
I have a .wixproj in VS 2010 that makes a MSI just the way I need it (using heat for harvesting in the pre build event). Now I need to distribute 3 versions of the same thing, that only need to differ in app.config settings, output MSI name, and some dialog stuff defined in some secondary .wxs files.
I was thinking about creating a console app that would take parameters and modify the .wixproj and .wxs and app.config files and then kick off MSBuild, but that seems like a lot of work.
What would be a better way to use WiX as a build factory so I can have it generate many customized MSI installers?
Thanks.
The WiX Preprocessor is your friend here. Using its values and conditional statements will help you to make "universal" sources, which will output various packages based on what you pass in.