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.
Related
I have a redistributable package installation file, a flash installation file, and an exe installation file.
I want to create a file that combines these three into one and installs them all at once.
From what I searched for, I know you can use advanced installer and wix.
However, the advanced installer is difficult to use because it requires a license.
I'm trying to use wix, a free program, but I'm running out of information.
Does anyone know a tutorial or how to combine three files?
I am a foreigner and have trouble communicating. please understand.
Copying of license files using Wix 3.10.2? We have a requirement where we need copy some license files after the installation of the webapplication to IIS. Copying of license files will be the last in the sequence. The license files will reside next to the burn (bootstrapper) setup.exe. This way we can control what license file need to be installed based on the user. I am trying to understand if there will be an issue with number of license files reside along with .exe? Is there a custom action to pick files that are not part of the msi or exe?
1) There will not be an issue with number of license files residing along with exe
2) Using the Media element without a Cabinet name you can specify that certain files will neither be inside a cab or embedded into the msi, no custom action needed. See http://wixtoolset.org/documentation/manual/v3/xsd/wix/media.html
You may need to be more precise about exactly when you want the copy to occur. Your original question says "after the installation" which implies that the install has finished and that your generated MSI is no longer running. but in a later comment you say "during the install".
If after the install is what you want, then you could add a custom executable to your Burn bundle that will do whatever you want. In many of these kinds of situations the application that needs the file just goes and gets it with help from the MSI saying where it was installed from, or by using the SourceList capabilities of Windows Installer to get the location.
If you want to copy files during the install then the CopyFile element is probably what you need. It has wildcard capability to define the files you want to copy. Your source location will be the SourceDir property and the destination will be one of your defined directories. Note that the files will not be uninstalled when the product is uninstalled.
WiX Copyfile:
http://wixtoolset.org/documentation/manual/v3/xsd/wix/copyfile.html
I had to use native bootstrap that comes with Visual Studio SDK. With the bootstrap you can also create pre-requisite like installing .net. This worked for my requirement. Also there is a msbuild task so that you can automate it. Used setup project to create msi and VS bootstrap to create setup.exe
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
I am using WiX Burn 3.9 to create a bootstrapper (with a custom managed bootstrapper application for the UI). I'm building a tiny version of the bootstrapper (a couple of megabytes) that downloads dependencies as needed. I'm also building a version with all dependencies embedded, to support easy installation on secure networks. The /layout command line option would work for pulling down the dependencies, but my organization prefers a single, monolithic executable to keep things simple for the users.
Everything was going along pretty well until I was asked to add a 1GB virtual appliance file and associated installation readme. All the bootstrapper has to do is place them in a folder that the user specifies in the bootstrapper UI. I put the *.ova and *.htm file into a self-extracting zip executable and passed the destination folder to it on the command line. The web installer version works just fine, but then I tried to build the offline installer, with everything embedded. I started getting an error from light:
light.exe(0,0): error LGHT0306: An error (E_FAIL) was returned while finalizing a CAB file. This most commonly happens when creating a CAB file with more than 65535 files in it. Either reduce the number of files in your installation package or split your installation package's files into more than one CAB file using the Media element.
The only relevant-looking conversation about this error that I have found is here. This seems to be related to file size, not file count. I'm wondering if the problem is related to the overall size of the bootstrapper executable (which would be about 2 GB) or the size of the very large self-extracting zip executable (about 1 GB). When I'm building an MSI with WiX, the syntax for breaking things up into separate cab files is pretty clear, but I'm not sure whether the same concepts are exposed for a Burn-based boostrapper, or if it's possible to do much to embed a file of that size.
With embedded payloads, Burn uses a .cab file that it attaches to the .exe during the build process. That means there's a 2GB limit on the size of embedded payloads. There might also be a limit on how much you could attach to an .exe.
I haven't tried it but it looks like you can try attaching multiple containers by using explicit Container elements.
Unless you absolutely need a single .exe, you can also just create an uncompressed bundle. The .msi, .cab, and .exe files would be external but it works if you're creating .iso images for download (for example).
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.