There are lots of tools for creating installers on Windows (InstallShield, InnoSetup, NSIS, just to name a few). All tools I've seen fall in one or both of these categories
Point-and-click. Nice GUI for creating the installer, but the installer definition/project file can not be manually edited.
Textfile: No (official) GUI. The installer is compiled from a definition in a text-file which is manually edited.
The installers I'm building are all defined using a DSL (represented as YAML files), so using a GUI is out of the question, and creating is textfile is cumbersome although doable.
What I really would want is a tool which exposes a (complete) API, through which I can control the creation of the installer. Are there any such tools out there?
Edit: I'd love to hear about non-MSI based tools as well. MSI is not a requirement (rather the other way around...)
Wix 3.0 beta has .NET support included for this purpose. I don't know how well it works but it includes documentation. It's a framework of types for manipulating the installation creation process and all that goodness, so I don't think you even need to write a line of WiX XML if you don't want to.
WiX is a great tool, but you will have to do a lot of direct coding in order to make things happen. Fortunately the documentation is pretty good and there are several GUI tools, such as WixEdit on SourceForge to aid in the process.
Well, there is the Windows Installer API which you could use to create MSI files directly, however I think you'd be better off using WiX.
The "direct coding" will be much less than dealing with the Windows Installer API directly, I'm guessing that's probably going too "low level" for what you need. Depending on what you're looking to do, you could use WiX to generate an MSI and then tweak that afterwards using the API.
What's wrong with generating XML? That's really going to be your simplest option... you won't need to manually edit it, just write your own code to generate the required XML from your DSL files and a few templates.
Related
Just out of curiosity, I would like to understand the behaviors of those self contained installer programs and try to write a simple installer myself.
I did some search on Google and did not really find a useful article explaining it. However AFAIK, an installer should have a small chunk of code residing in the top of the executable. It pulls data out from the rear of the executable and interprets them as files according to an inventory file (probably xml?). Other operations such as writing register entries can also be specified in the inventory file.
Now is my guess of the file structure true? If so I think I just need to read about the PE format and then it would be conceptually easy for me to implement it. If my guess is wrong, I would love to know how exactly it works.
Thanks for your time!
Normally installer packages are self-contained compressed executables (SFX) that contains:
A small installer executable
A compressed file structure with files to extract
Some configuration files (xml, ini, json, properties) to define file destinations, registry entries, desktop/start menu shortcuts, instalation modes
Extra files (dll, icon/image resources) to make the installer work.
For MSI packages, it's a bit more complex. It's a propietary format packaged as a SQL database in a COM structured storage file. It contains also a virtual file system inside the installation package (file access using file streams).
You can review some free tools and check many typical features to make installer executables like:
Wix (For MSI installers) http://wixtoolset.org/
Nullsoft Installer (NSIS) http://nsis.sourceforge.net/Main_Page
Inno Setup http://www.jrsoftware.org/isinfo.php
For Windows it's pretty much
Declarative: MSI, AppX, ClickOnce
Imperative: any number of third party tools, scripts and home grown EXEs
MSI is typically your best choice. The runtime is already part of windows so when you double click the MSI database MSIEXEC takes over. The point of the declarative models is to separate what needs to be done from how you do it. The imperative models are basically some simple to complex framework to write procedural code to do the actual installation work.
It's far to broad of a question to ask in detail how any of these work at a low level. For MSI it's all in the Windows Platform SDK documentation on MSDN.
I desperately trying to convert .vdproj proj. into wix project, with same custom actions(reason is that i dunno exactly what all is installation supposed to do) - right now confused about this:
/installtype=notransaction /action=install /LogFile= /sd="[SourceDir]\" /td="[TARGETDIR]\" /cf=[CF] "[#_DF75DCA6_84B6_7B49_8F15_EAEE08D32EA4]" "[VSDFxConfigFile]"
No idea what [VSDFxConfigFile], and missing overall picture what is behind this Custom action generated by Visual Studio in WinService project.
If anyone give me clue about PROCESS i would highly appreciate it!
Update:
today i discussed installer requirements and one which is known among collegues is that it should be able to change .config file according to parameters - XML has whole configuration element tree in it - and it should replace installed .config file - i just wonder if there is direct way to accomplish this in WIX
Moreover - .vdproj files already has some custom actions in it(which i guess aren't standard custom actions) - which calls some dll lib .NET installer component - which i guess changing .config according to parameters, but way it is happening isn't really clear to me. I used ORCA and MSI logs, however i still feel like Alice in world of dreams. Well thing is that also i'm unable to say what all parts of code called so that's why i still thinking call all CustomActions which are generated in msi file throught vdproj
Ignore all that stuff. it's related to managed code custom actions, and managed code custom actions don't use the same framework in WiX - they use DTF. VS setups put several custom actions in that you don't need to worry about, such as checking for the NET Framework. So it's going to be pointless trying to transfer internal VS custom actions (because WiX has its own that do similar things) and because your managed code custom actions won't use the same framework of installer classes, Install methods etc.
VS setup projects install services with Installer classes, and WiX doesn't use those either - there's no reason to, because Windows Installer has built-in support for installing/starting/stopping services, so if your manage code is realted to that then again, ignore it.
p.s. This may be useful:
http://blogs.technet.com/b/alexshev/archive/2008/02/10/from-msi-to-wix.aspx
We have a product with more than 100 'pieces' most of which are optional 'plug-ins'. We would like a non-programmer to be able to make a "customized" installer on a per-customer/sale basis. Our ideal would be simply a single executable/msi with a folder structure from which files/folders could be deleted, then when run the installer would simply not offer features corresponding to the deleted bits.
A separate, but similar issue is that the developers of these plug-ins are not installation experts and we would prefer not to have to edit shared installer source to add/remove one from our build-set. We've been using the "synchronized folders" feature of Advanced Installer for this, but we would like a separately selectable feature for each plug-in.
Is there an installer tool-chain that can support such(or similar) behavior?
If so does anyone have tips on how to actually implement it using said tool?
I created such a tool stack at my last job. We did product line development with dozens of service families, hundreds of features, thousands of merge modules and tens of thousands of files in a typical installer.
Each merge module was authored using IsWiX and compiled using WiX. We then used WiX XML as an input to our build automation system to generate InstallShield installers. A service family would have an XML file to describe it's portion of the feature tree and it would all get emitted into an empty InstallShield project.
Finally a product XML file would describe the INSTALLDIR, UpgradeCode and other meta along with which features to consume. We built dozens and dozens of installers off this common base code.
It would take days to explain everything but that gives you the idea. For a simpler environment you could create a UI to generate WiX code and then compile it into an MSI.
But I don't know that I'd ever give this to a non-programmer. Creating installers is programming.
There is no tool that creates features at runtime in the MSI package, at least no MSI based tool. This complicates too much the installer logic, as you would need a very complex custom action that reads the contents of the folders found next to the installer and then generate entries in the following MSI tables: Files, Directory, Component, Feature, FeatureComponents. And then inter-connect all of this.
That is not something easy to do at all, and very error prone is tried by something how does not have extensive experience in building MSI packages.
have you considered/tried any non-MSI package builders?
I would like to create an installer of my program.
However because the installation is quite complicated, I need something more advanced than installshield limited edition.
I have to run another installer from my current one. It doesn't matter if the user press "cancel" or installs the program, I just need to run it.
I have to install a directory structure on user computer which has a lot of files, that's why i'm going mad with wix: 100 files and I should write all of them with my hands in that xml file? Are we mad?
I have to install files from point 2 into a registry key. That's why I was using wix
I played with nsis long time ago and I liked it, but the language is not so nice.
Wix has "similar" problem. I would love using something like C# and things like that otherwise I'll stick with wix but I need a way to add files faster to xml file, can't add 100 files manually.
Any suggestion?
You can give Advanced Installer a try. It has folder synchronization, which means it can batch add contents of folders, with the possibility to filter out certain file name patterns, for example you'd want to filter *.pdb files and add all the rest to the project automatically.
I use it myself and never had a problem.
Wix Heat can generate the wxs source files for you.
You should look at InnoSetup. It has an IDE available that allows drag and drop of files (and multiple select in a file selection dialog), can launch other applications (including additional setup files), create and modify registry settings, and supports pretty complex scripting if needed. It's pretty easy to use, and the documentation is pretty good. It comes with pretty comprehensive sample installations, too.
The installation scripts are created by the IDE and then compiled into an installer, so the script source is editable by hand if needed. It's also not XML, but more like an INI file, so it's a little easier to work with manually as well.
Best of all it's free, and so is the IDE.
I would go back to using NSIS, if you use the HMNSIS editor http://hmne.sourceforge.net/ to write your scripts you can use the Wizard mode to make a list of the files and directory structure you will use in your installer.
Running other installers and registry settings are also easily done with NSIS.
I installed WiX 3.5 with Visual Studio 2010, as I've read lots of people saying that WiX is a great alternative to that hellhole that is the Visual Studio Setup project, but it sure seems like it requires a lot more effort to make even the simplest installer. Am I missing something?
In a VS setup project, I can add a project output to my ProgramFilesFolder, and VS automatically sweeps up all the dependent dll's from the other projects in the solution, as well as 3rd-party libraries and such. After reading this from the (apparently somewhat out of date) online docs, I thought maybe WiX finally had something similar, but it doesn't actually pull in dependent libraries--it just makes it easier to add that single project's output to a fragment without a lot of extra typing.
So the best I can see to do is manually add to my WiX setup project every single project in my solution that I want in the installer (and set Harvest to true, since that doesn't seem to be the default). I'd probably write a little perl script to do that. Then I have to determine all the non-project dependent dll's somehow (probably easiest to look at the VS setup project for that) and add by hand some wxs code to include them (since apparently the WiX project only handles references to projects, not raw dll's). Then edit in a simple UI, for which there are samples on the web I can work from. And code for shortcuts.
Is there a better way?
This is a very subjective and long answer type question. From a quality and capability perspective, WiX kills VDPROJ. From a learning curve perspective, not so much.
Check out IntallShield 2010LE ( Limited Edition / Free ) or look at Industrial Strength Windows Installer XML ( IsWiX ) (Disclaimer: I am the coordinator ) I use this tool to do the majority of my heavy lifting and then write small amounts of WiX by hand to glue it all together.