I want to make a MSI installation using WiX and EmbeddedGUI. I really want to make it highly modular - ie the main MSI will contain only the basic files (the required ones), and all other features will be split into separate MSI files, which will be downloaded from internet if not present on hard drive and installed only if selected in my EmbeddedGUI.
But I am totally new to WiX, and I can't find a way to actually how to make that modules? MS Office and MS Visual Studio seems to be using this scheme, by using the modules which it downloads over internet and installs them in case of need - something like this:
It seems that Fragments is mostly like "static libraries", not "dynamic libraries" which would be more useful in such a situation. There is also the Chaining mechanism, but I'm not sure I will be able to bundle the features as the same application (only one entry in "Install/Delete" window) because it seems to be calling external MSIs completely separately (more like invoking "separate exes" instead of loading "dynamic libraries").
So, what is the way to go for making a highly modular setup package with WiX?
Use a bundle (chain). The Burn engine, which manages bundles, will show only the bundle in Add/Remove Programs and can download any packages that aren't already present -- for example, using the MsiPackage/#DownloadURL attribute.
Related
Background
I'm currently triaging migrating an existing non-MSI setup to a Windows Installer based solution. The current solution is written in InnoSetup and I very much like it, however, customer IT departments start to require MSI, and where they do so, it is often the case, that many/some of the prerequisites and scripts we include in our setup.exe are not needed for their automated tasks (but, then, some are).
Therefore it seems a pure MSI wrapper doesn't make too much sense here, so I'm looking at (multiple?) MSI files plus a boostrapper.
Prior knowledge
I'm good an InnoSetup, but I'm just starting to read into the Windows Installer technology.
Question
As far as I can tell, for any multistep / "complicated" setup requirements including prerequisites and stuff, using just a bare MSI file is a no-go. (As evidenced by the existence of all the different boostrappers, including the one bundled with WiX, Burn)
Therefore, I would need to split our existing monolithic setup into several steps, some of which (mostly those that install our files) bundled into MSI databases and some of the steps just "scripted" in the bootstrapper.
And here is where I really could use some prior experience regarding setup packages: What parts of a (chained) setup go into the MSI package(s) and what part goes into the bootstrapper?
Should all the (normally visible) UI reside in the bootstrapper or do you put some of it into the MSI files?
How "dumb" should each MSI file ultimately be? That is, if using a bootstrapper and multiple MSI files anyway, should any individual MSI file contain any optional parts, or should all the options be factored out into separate MSI files (that just check for the existence of their respective prerequisites, but contain no logic to install them)?
Basically, the application (suite) needs to support a click-through average user scenario where the setup handles everything and for corporate clients needs to be able to be split up into MSI files that only contain our stuff minus dependencies like the .NET runtime, SQL Server, ... that'll be handled by the client's corporate IT and our software MSIs will be deployed by the client IT automagically.
So, should all the glue and dependency scripting go into the bootstrapper and only use very simple MSI files? Or should some "logic" go into (some) MSI files?
Short-ish answer:
When there are multiple MSI files it is normal for the UI to be handled by the Burn bootstrapper because you do want to see combined progress, not all the separate MSI UIs. You also should set up appropriate rollbacks of more than one MSI in the event of a failure of one if you are really packaging several MSIs as a product, so if one fails they all need backing out.
The bootstrapper contains detection logic that determines what needs installing, and can install prerequisites like SQL, NET etc, but must not otherwise change the system.
The MSI files contain all the files, service installation, COM registration and so on that is appropriate for the files being installed. Any custom action code you use that alters the system must be in the execute sequence, deferred, and have a corresponding rollback CA to undo whatever it does. The MSI should be capable of being run independently to install its content - I've found that to be a useful guideline. The MSI files will be installed without their UI, so ensure that they can be installed silently with parameters passed as property values on the command line, including install location.
Hard to answer this in brief. Do use Burn or a similar bootstrapper, and leave runtimes with their own deployment solution as a separate file to run - and run in silent mode by default.
For home users you should install everything without too many questions to avoid confusion.
For corporate deployment you should deploy only what is needed and make it clear what each included deployment file is for:
Write a one page PDF with deployment instructions describing what every file does and what runtime it relates to. Call it "DEPLOYMENT README.TXT" or similar. This is the best way to get your application approved for corporate deployment. It can be tiresome to analyze this.
Application packagers in the corporate environment will analyze the prerequisites and determine if your application will work well with their standard framework packages. These standard packages will be set as a prerequisite in the distribution system.
Document in particular what .NET framework version is needed and other runtime requirements in detail.
Don't install windows hotfixes, msiexec engine updates or .NET framework runtimes automatically. Document them as prerequisites in your text file. These runtimes are tightly controlled in corporate settings and they are deployed by customized corporate packages.
You can include merge modules of simple runtimes in your MSI, they can be easily removed by the application packaging team in the corporate setting.
This answer didn't get terribly good, but I am out of time. Perhaps check this answer as well:
MSI Reference Counting: Two products install the same MSIs
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
Is it possible to create a wix installer (msi) that offers the user the choice of installing the target product as either full or portable (i.e. non-installed, running from a thumb drive, for example) using the predefined wix controls?
As far as I searched, the feature property (minimal, typical, full...etc.) is irrelevant in this context. The only solution I can think of is adding a custom UI form element that displays the choice of full & portable installation as radio buttons. Based on the choice of the user, with the help of "if clause", the msi package will either perform a full installation with shortcuts and registry entries, or it will simply copy the source files to the destination directory.
Note after edit: As a third option, is it a better (or more common) alternative to supply a simple zip file for portable installation and a proper msi file for full installation?
Your third option (a zip file) is good. A similar option would be to package with a PortableApps.com installer.
It is not possible to use Windows Installer to "simply copy the source files to the destination directory." Windows Installer manages installations and provides repair and uninstall support--those features are not optional (though you could hack around them). A successful installation would do more than copy files and a proper failed installation would undo everything it had done.
Recently I was creating a Windows Installer package using a WiX Setup project, and I have following requirements:
When copying a versioned file to the Windows System32 folder, if the same file with a higher version is present then I should not overwrite.
If a lower version is present, I need to overwrite the file.
Before doing this, the user should get a warning message like "File exists, do you wish to overwrite?".
Any suggestions is appreciated.
Windows Installer handles the overwrite decision as you described but does not ask the user.
A couple suggestions in the "don't do this" category:
Although it was common a couple of decades ago for installers to have such a feature, the vast majority of users are not knowledgeable enough to make the decision; those that are probably would not like to make the decision anyway. You should not ask them to do so.
Application frameworks have evolved to the point where putting files in System32 is usually not necessary. In particular, if your application depends on a third-party library, use its installer to handle its installation. You can use WiX Bootstrapper project to chain the installers together (WiX 3.6 or later).
Generally when I use ClickOnce when I build a VB.NET program but it has a few downsides. I've never really used anything else, so I'm not sure
what my options are.
Downsides to ClickOnce:
Consists of multiple files - Seems easier to distribute one file than manageing a bunch of file and the downloader to download those files.
You have to build it again for CD installations (for when the end user dosn't have internet)
Program does not end up in Program Files - It ends up hidden away in some application catch folder, making it much harder to shortcut to.
Pros to ClickOnce:
It works. Magically. And it's built
into VisualStudio 2008 express.
Makes it easy to upgrade the
application.
Does Windows Installer do these things as well? I know it dosen't have any of the ClickOnce cons, but It would be nice to know if it also has the ClickOnce pros.
Update:
I ended up using Wix 2 (Wix 3 was available but at the time I did the project, no one had a competent tutorial). It was nice because it supported the three things I (eventually) needed. An optional start-up-with-windows shortcut, a start-up-when-the-installer-is-done option, and three paragraphs of text that my boss thinks will keep uses from clicking the wrong option.
Have you seen WiX yet?
http://wix.sourceforge.net/
It builds windows installers using an XML file and has additional libraries to use if you want to fancify your installers and the like. I'll admit the learning curve for me was medium-high in getting things started, but afterwards I was able to build a second installer without any hassles.
It will handle updates and other items if you so desire, and you can apply folder permissions and the like to the installers. It also gives you greater control on where exactly you want to install files and is compatible with all the standardized Windows folder conventions, so you can specify "PROGRAM_DATA" or something to that effect and the installer knows to put it in C:\Documents and Settings\All Users\Application Data or C:\ProgramData depending on if you're running XP or Vista.
The rumor is that Office 2007 and Visual Studio 2008 used WiX to create their installer, but I haven't been able to verify that anywhere. I do believe is is developed by some Microsoft folks on the inside.
I agree with Joseph, my experience with ClickOnce is its great for the vast majority of projects especially in a corporate environment where it makes build, publish and deployment easy. Implementing the "forced upgrade" to ensure users have the latest version when running is so much easier in ClickOnce, and a main reason for my usage of it.
Issues with ClickOnce: In a corporate environment it has issues with proxy servers and the workarounds are less than ideal. I've had to deploy a few apps in those cases from UNC paths...but you can't do that all the time. Its "sandbox" is great, until you want to find the executable or create a desktop shortcut.
Have not deployed out of 2008 yet so not sure if those issues still exist.
Creating an installer project, with a dependency on your EXE (which in turn depends on whatever it needs) is a fairly straightforward process - but you'll need at least VS Standard Edition for that.
Inside the installer project, you can create custom tasks and dialog steps that allow you to do anything you code up.
What's missing is the auto-upgrade and version-checking magic you get with ClickOnce. You can still build it in, it's just not automatic.
I don't believe there is any easy way to make a Windows Installer project have the ease or upgradability of ClickOnce. I use ClickOnce for all the internal .NET apps I develop (with the exception of Console Apps). I find that in an enterprise environment, the ease of deployment outweighs the lack of flexibility.
ClickOnce can be problematic if you have 3rd party components that need to be installed along with your product. You can skirt this to some extent by creating installers for the components however with ClickOnce deployment you have to create the logic to update said component installers.
I've in a previous life used Wise For Windows Installer to create installation packages. While creating upgrades with it were not automatic like ClickOnce is, they were more precise and less headache filled when it came to other components that needed to be registered/added.