Windows Installer XML (WiX)

Question

Why should one go for Windows Installer XML (WiX) when we have in built .net MSI installer?

Thanks in advance

Answer 1

1. Some of us don't want to use / can't use the .NET installer.
2. Some of us don't want to have to install Visual Studio to distribute a program, written in, say, Borland Delphi. WiX and .NET have nothing to do with one another.
3. WiX provdes a much more complete feature set than the .NET installer.

Answer 2

Visual Studio deployment packages can only be built by visual studio. They cannot be built using plain MSBuild command lines, which makes them less than ideal for e.g. build servers.

Answer 3

The introduction of WiX tutorial gives the basic idea about WiX advantages comparing to other setup development tools (including VS setup projects):

• declarative approach
• unrestricted access to Windows Installer functionality
• source code instead of GUI-based assembly of information
• complete integration into application build processes
• possible integration with application development
• support for team development, both in-house and third-party
• free, open source

Hope this helps.

Answer 4

It would take me hours to rant about everything I hate about VDPROJ. I won't because in my (expert) opinion it's already settled law that VDPROJ sucks. If your install is so simple that you haven't noticed any problems, then be my guess and stick with it. But if you already find yourself fighting the tool trying to get it to do things it doesn't do, then take my advice and dump it fast for WiX.

10 things I hate about VDPROJ

1) No MSBuild Support. Sure, you can call devenv from the command line but it's not as good. 2) No exposing of the critical concept of a component. Every file/reg key is a keyfile of it's own component. 3) No effective way to fully exclude automatic dependency scanning. 4) Shortcuts are always Advertised 5) No way to describe a service. 6) No way to describe many things which leads to overuse of custom actions. 7) No way to fine control the scheduling / execution of custom actions. Too abstracted. 8) Abstraction is wrong. Deferred CA's are scheduled with Impersonation which breaks on Vista. 9) Various limitations lead you down a path of massaging the built MSI during postbuild to get around all the limiations. Results in a very poor build automation hacks. 10) Merge Module directory tables are authored incorrectly. 11) 100 other things suck that I'm not remembering right now.