4 ms·

For installers, use http://wixtoolset.org/ http://wixtoolset.org/.

anton_gogolev 13y ago
Yeah, because I really want to spend hours upon hours studying obscure incantations that someone decided to be making sense. WiX (and MSI, for that matter) is a disaster.
- DrJokepu 13y ago
  It’s really not that bad. WiX is actually pretty decent, definitely not a “disaster”. It might look more frightening than InstallShield because you don’t get a nice UI that allows you to set up an installer with a few clicks, but I mean, we’re programmers here, surely editing textual configuration files is not an issue? It took me somethong like 30 minutes to replace our old InstallShield installer with WiX.
  - coffeeaddicted 13y ago
    I gave it a shot for a day recently but found it way harder to use than InstallShield or NSIS. Part of it was probably the broken documentation where half the links just ended in nirvana. But I gave up when I learned you really have to add each single file one-by-one and the documentation even defended this as a feature.
    - euroclydon 13y ago
      You can use this Wix tool or command called Heat, which will automate the adding (and creating GUIDs) for a bunch of files. Really it's the underlying MSI target that's so painful, especially when you get into versioning. The OS wants to have detailed information on every file that is part of your installation. I think this is primarily for uninstallation purposes, but also for upgrades and who know what else. If I could get away with it, I'd just use NullSoft. It's like writing assembly, but it's so much simpler. With Wix/MSI, there were certain executables that I could never get it to run as part of the install process. The XML would look the same as other execute commands that worked, but I could never figure out why they didn't run.
      - deleted 13y ago
        [deleted]
    - anton_gogolev 13y ago
      Amen. This can "kinda" be worked around with "heat.exe" (don't get me started on naming of tools in the toolchain), but even then you'll need to explicitly specify half a dozen command-line arguments (-ag -dr -cg -srd -scom -sreg -svb6 -sfrag) to make the thing work.
    - powertower 13y ago
      So how would one deal with projects that contain 1000s of files? Run a script to enumerate the files and populate a wix file? Zip up the different parts and have the installation process unzip them?
      - rockin 13y ago
        That's exactly how we did it. Our wix files where 90% created automatically by a script
  - anton_gogolev 13y ago
    Don't mean to sound like an ass, but oh really? WiX is a thin wrapper around MSI (which sucks beyond belief) and as such it suffers full blast from all the "design" decisions of the latter, not even trying to remedy the situation. I really could pour out a full-blown rant on MSI in general and WiX in particular, but that would be wildly offtopic and of no interest to fellow HNers.
    - ConceptJunkie 13y ago
      If you think MSI is bad, and I'll have to take your word for it, what MS had prior to it was probably worse. Writing installers for Windows using MS tools has always been a nightmare.
  - eropple 13y ago
    He's not wrong: WiX is a horrorshow. It's unintuitive, difficult to read and parse, and is saddled with much of the cruft of years of Windows; when you compare it (or NSIS, or InstallShield) to building an .app (or even a .pkg) under OS X, it fares very poorly.
- roel_v 13y ago
  The same can be said of programming in general. It's true that msi is different from other installer builders, but it's for a reason. And if you have a concrete project you can build while following along with the wix tutorials and book, it's not difficult, it just takes some time.
  - anton_gogolev 13y ago
    Yeah, the "reason" being that Windows Installer was designed to support corporate deployment of applications to shared machines with install-on-demand and roaming profiles, and to support Windows 95 and up. This, and Microsoft's manic affection to backwards compatibility plus "architecture astronautery" (on-demand installs of COM objects, anyone) makes MSI a disaster. The fault of WiX is that it's too thin of a wrapper.
- breischl 13y ago
  Wait, weren't you complaining about all the "wizard clickety clicky" things in another thread? If you hate wizards, and you hate "obscure incantations", which I'm assuming means code, then what do you like? Do you program in natural language with voice recognition?
  - anton_gogolev 13y ago
    Where's the conflict? By "obscure incantations" I mean having _three_ different syntaxes for string interpolation/variable substitution, providing _six_ command line arguments for the tool so that it does the one reasonable thing, having illogical rules in comparison operators, having to use a frickin' _bootstrapper_ to install prerequisites and not being able to chain MSIs, not being able to have a single installer for x86 and x64, not having a _simple_ way to define logic for "Back" button, yet having to write heavily nested XML to do simplest thing.
nickpp 13y ago
Or Advanced Installer's free edition if you're xml-challenged.
Pxtl 13y ago
While that's obviously a solution, it's not quite the same y'know? There's a lot more skill overhead in learning that tool vs the comparative ease of the installer project. Considering how thoroughly MS screwed the pooch on ClickOnce, I was genuinely surprised when they completely abandoned their working installer system.
- gecko 13y ago
  What's wrong with ClickOnce? I've not used it from a developer's perspective, but Chrome's installation (which uses it) always seems smooth as butter.
  - jonnii 13y ago
    There's a lot of things wrong with ClickOnce. IIRC chrome's installer only uses clickonce as a bootstrapping mechanism for the _actual_ installer. Problems: * Can't choose installation path * No offline installation * Hard (impossible?) to use with a CDN. Here's an example of how to turn a directory of precompiled binaries into a click once package using powershell: https://gist.github.com/jonnii/2628150 https://gist.github.com/jonnii/2628150 My powershell isn't _great_, so forgive any powershell oddities, but notice how much you have to massage the output of the mage tools to actually get it to do what you want.
  - whazzmaster 13y ago
    For small things ClickOnce is fine, but it's a pain in the ass to automate. For example, there's no way to synchronize the 'version' of the installer with the version of the EXE it's installing. I had to hack[1] it so I could pull the version metadata off the EXE assembly and then force it into the XML of the project file where the ClickOnce settings are stored. There's also no ability to publish the built installer outside of the UI- my build scripts had to build the /app.publish directory and then just copy the whole shebang to a network location for deployment. I'm not as upset about this being a separate step, but if they indeed allow you to configure and deploy the installer from within the UI why not expose an API to do it as well? Overall I think ClickOnce is fine for internal, self-updating tools. It's worth noting, however, that I was inspired to create my workflow based on looking at what Github was doing with their windows client. [1]: http://whazzing.com/blog/2013/04/11/automated-clickonce-build-and-deploy-using-powershell-and-msbuild/ http://whazzing.com/blog/2013/04/11/automated-clickonce-buil...
jaredsohn 13y ago
I've always liked InnoSetup (http://www.jrsoftware.org/isinfo.php http://www.jrsoftware.org/isinfo.php). You describe your installation in a short file created via its syntax-highlighting IDE. A big con is that its scripting is done in Pascal, but you can likely find existing scripts to do many common operations.

Yeah, because I really want to spend hours upon hours studying obscure incantations that someone decided to be making sense. WiX (and MSI, for that matter) is a disaster.

DrJokepu 13y ago
It’s really not that bad. WiX is actually pretty decent, definitely not a “disaster”. It might look more frightening than InstallShield because you don’t get a nice UI that allows you to set up an installer with a few clicks, but I mean, we’re programmers here, surely editing textual configuration files is not an issue? It took me somethong like 30 minutes to replace our old InstallShield installer with WiX.
- coffeeaddicted 13y ago
  I gave it a shot for a day recently but found it way harder to use than InstallShield or NSIS. Part of it was probably the broken documentation where half the links just ended in nirvana. But I gave up when I learned you really have to add each single file one-by-one and the documentation even defended this as a feature.
  - euroclydon 13y ago
    You can use this Wix tool or command called Heat, which will automate the adding (and creating GUIDs) for a bunch of files. Really it's the underlying MSI target that's so painful, especially when you get into versioning. The OS wants to have detailed information on every file that is part of your installation. I think this is primarily for uninstallation purposes, but also for upgrades and who know what else. If I could get away with it, I'd just use NullSoft. It's like writing assembly, but it's so much simpler. With Wix/MSI, there were certain executables that I could never get it to run as part of the install process. The XML would look the same as other execute commands that worked, but I could never figure out why they didn't run.
    - deleted 13y ago
      [deleted]
  - anton_gogolev 13y ago
    Amen. This can "kinda" be worked around with "heat.exe" (don't get me started on naming of tools in the toolchain), but even then you'll need to explicitly specify half a dozen command-line arguments (-ag -dr -cg -srd -scom -sreg -svb6 -sfrag) to make the thing work.
  - powertower 13y ago
    So how would one deal with projects that contain 1000s of files? Run a script to enumerate the files and populate a wix file? Zip up the different parts and have the installation process unzip them?
    - rockin 13y ago
      That's exactly how we did it. Our wix files where 90% created automatically by a script
- anton_gogolev 13y ago
  Don't mean to sound like an ass, but oh really? WiX is a thin wrapper around MSI (which sucks beyond belief) and as such it suffers full blast from all the "design" decisions of the latter, not even trying to remedy the situation. I really could pour out a full-blown rant on MSI in general and WiX in particular, but that would be wildly offtopic and of no interest to fellow HNers.
  - ConceptJunkie 13y ago
    If you think MSI is bad, and I'll have to take your word for it, what MS had prior to it was probably worse. Writing installers for Windows using MS tools has always been a nightmare.
- eropple 13y ago
  He's not wrong: WiX is a horrorshow. It's unintuitive, difficult to read and parse, and is saddled with much of the cruft of years of Windows; when you compare it (or NSIS, or InstallShield) to building an .app (or even a .pkg) under OS X, it fares very poorly.
roel_v 13y ago
The same can be said of programming in general. It's true that msi is different from other installer builders, but it's for a reason. And if you have a concrete project you can build while following along with the wix tutorials and book, it's not difficult, it just takes some time.
- anton_gogolev 13y ago
  Yeah, the "reason" being that Windows Installer was designed to support corporate deployment of applications to shared machines with install-on-demand and roaming profiles, and to support Windows 95 and up. This, and Microsoft's manic affection to backwards compatibility plus "architecture astronautery" (on-demand installs of COM objects, anyone) makes MSI a disaster. The fault of WiX is that it's too thin of a wrapper.
breischl 13y ago
Wait, weren't you complaining about all the "wizard clickety clicky" things in another thread? If you hate wizards, and you hate "obscure incantations", which I'm assuming means code, then what do you like? Do you program in natural language with voice recognition?
- anton_gogolev 13y ago
  Where's the conflict? By "obscure incantations" I mean having _three_ different syntaxes for string interpolation/variable substitution, providing _six_ command line arguments for the tool so that it does the one reasonable thing, having illogical rules in comparison operators, having to use a frickin' _bootstrapper_ to install prerequisites and not being able to chain MSIs, not being able to have a single installer for x86 and x64, not having a _simple_ way to define logic for "Back" button, yet having to write heavily nested XML to do simplest thing.

nickpp 13y ago

Or Advanced Installer's free edition if you're xml-challenged.

Pxtl 13y ago

While that's obviously a solution, it's not quite the same y'know? There's a lot more skill overhead in learning that tool vs the comparative ease of the installer project. Considering how thoroughly MS screwed the pooch on ClickOnce, I was genuinely surprised when they completely abandoned their working installer system.

gecko 13y ago
What's wrong with ClickOnce? I've not used it from a developer's perspective, but Chrome's installation (which uses it) always seems smooth as butter.
- jonnii 13y ago
  There's a lot of things wrong with ClickOnce. IIRC chrome's installer only uses clickonce as a bootstrapping mechanism for the _actual_ installer. Problems: * Can't choose installation path * No offline installation * Hard (impossible?) to use with a CDN. Here's an example of how to turn a directory of precompiled binaries into a click once package using powershell: https://gist.github.com/jonnii/2628150 https://gist.github.com/jonnii/2628150 My powershell isn't _great_, so forgive any powershell oddities, but notice how much you have to massage the output of the mage tools to actually get it to do what you want.
- whazzmaster 13y ago
  For small things ClickOnce is fine, but it's a pain in the ass to automate. For example, there's no way to synchronize the 'version' of the installer with the version of the EXE it's installing. I had to hack[1] it so I could pull the version metadata off the EXE assembly and then force it into the XML of the project file where the ClickOnce settings are stored. There's also no ability to publish the built installer outside of the UI- my build scripts had to build the /app.publish directory and then just copy the whole shebang to a network location for deployment. I'm not as upset about this being a separate step, but if they indeed allow you to configure and deploy the installer from within the UI why not expose an API to do it as well? Overall I think ClickOnce is fine for internal, self-updating tools. It's worth noting, however, that I was inspired to create my workflow based on looking at what Github was doing with their windows client. [1]: http://whazzing.com/blog/2013/04/11/automated-clickonce-build-and-deploy-using-powershell-and-msbuild/ http://whazzing.com/blog/2013/04/11/automated-clickonce-buil...

jaredsohn 13y ago

I've always liked InnoSetup (http://www.jrsoftware.org/isinfo.php http://www.jrsoftware.org/isinfo.php). You describe your installation in a short file created via its syntax-highlighting IDE. A big con is that its scripting is done in Pascal, but you can likely find existing scripts to do many common operations.