19

I have been unsuccessfully trying to find an article or post listing functional limitations of WiX (Windows Installer XML)/WiX Toolset. After using WiX for a couple of weeks, I can think of at least two limitations in the most recent RTM version (v3.0):

  • WiX Toolset cannot make a bootstrapper (setup.exe).
  • WiX Toolset cannot retrieve COM registration info from a COM executable.

Can you think of other limitations? Something you ran into while working on a deployment project? I think this info could be handy for people who learn WiX.

Mark Pearl
  • 7,573
  • 10
  • 47
  • 57
Alek Davis
  • 10,628
  • 2
  • 41
  • 53
  • 1
    Thanks to both Yan and Chris for insightful answers. I wish I could pick both responses as accepted answers. – Alek Davis Nov 16 '10 at 06:12

2 Answers2

21

It's easiest for me to answer this question in terms of what is WiX missing that InstallShield has ( feature gap ).

  • Bootstrapper/Chainer - WiX has a bootstrapper called Burn which is now included in WiX v3.6.
  • XML Read - WiX only has CA's for writing not reading ( AppSearch ) XML files
  • Text Search / Replace - InstallShield has patterns for reading/writing non INI/XML files
  • MSSQL Only - No support for Oracle and MySQL
  • Automation Interface - No DOM for programatically updating/generating projects. Have to do it all with raw XML.
  • No Native IIS 7 support - Native IIS7 support is present from WiX v3.5
  • Mostly Text Only toolset. No GUI Designers for heavy lifting ( see IsWiX ). XML is concise and has it's place but it's like comparing Notepad to Blend.

I've used heat to extract COM fairly successfully so that's no longer a concern to me.

Justin
  • 84,773
  • 49
  • 224
  • 367
Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • Excellent points. Thanks you. Btw, I assume you use heat to extract COM info from DLLs, not EXEs, right? – Alek Davis Oct 18 '10 at 22:34
  • @Chris: +1 for points 2 - 4. Those also affected my work, but I forgot to mention it in my answer. – Yan Sklyarenko Oct 19 '10 at 08:39
  • I do it for EXE/DLL and Managed/Unmanaged. I use a little program I wrote that puts a filesystem watcher on a directory and calls heat everytime the contents change. I put in my file then I put in it's dependencies until it works and cut/paste the COM elements. Then on a clean machine I install and test. – Christopher Painter Oct 19 '10 at 12:09
  • Sometimes it doesnt work and I have to use a registry diff tool and regsvr32 to profile out the differences then manually massage that back into the XML. We have less and less COM these days and typically once it's done it stable. – Christopher Painter Oct 19 '10 at 12:10
  • I tried dumping registry before and after registering COM EXE and then use a WinDiff tool to find the differences. The problem is that you then need to map the registry entries to the appropriate WiX attributes. I guess you can treat them as is, but it does not look "pure" to me. I just ended up calling the EXE with /RegServer switch. I wouldn't do it for a commercial app, but for internal app, it's fine: I just did not want to spend too much time on this. – Alek Davis Oct 19 '10 at 16:55
  • Actually WiX be default will take the COM elements/attributes and just build them as regular old registry table rows. Read: http://robmensching.com/blog/posts/2007/3/12/RobMens-Recommendation-Do-not-advertise-COM-information-in-MSI – Christopher Painter Oct 19 '10 at 17:16
  • As for "No GUI Designers" see SharpSetup. – Tomasz Grobelny Nov 06 '10 at 01:32
  • IIS 7 support is in WiX 3.5. Haven't a chance to test it out yet though. – si618 Feb 25 '11 at 14:41
  • Take a look at Community MSI Extensions https://github.com/dblock/msiext. It has many Custom Actions (including reading XML) to ease the WiX/MSI day-to-day. – Santi Agüero Oct 06 '12 at 19:29
12

I would add several more points, but these can hardly be called serious limitations since they all can be worked around:

  • There's no ready-made tool to embed transforms (MST) into the MSI package; this is where msidb.exe comes to the rescue
  • You have to do extra work to create a single package with a number of localizations, like creating N packages, generate N language transforms against a neutral package, embed those transforms into the package, instruct your bootstrapper to call correct language transform
  • WiX 3.0 has rather limited IIS extension - it supports IIS 7 only in IIS 6 compatibility mode; but fortunately this is no longer true for WiX 3.5
  • Heat can't generate "1 component - N files" by default. Yeah, I know, it's not recommended, but sometimes you need it; fortunately, you can transform the heat output the way you like with XSL
  • PermissionEx of UtilExtension doesn't have a switch to set ACLs on folders only. If you need to set ACLs to your installed files only, this is quite minor. But I had to patch WiX with a quick fix to be able to say "apply these permissions to folders only" on existing file system tree

Again, let me repeat that I don't consider those serious limitations. I'm very happy with what Rob and the team have done so far, and they are on a right track! :)

Yan Sklyarenko
  • 31,557
  • 24
  • 104
  • 139
  • Exactly the info I'm looking for. Thanks Yan. – Alek Davis Oct 18 '10 at 20:42
  • 1
    The train may be (mostly) on the right track but it's about 5 years behind schedule. I survive WiX's limitations by blending it with InstallShield but from my perspective the lack of a bootstrapper is a deal killer that prevents me from going 100% WiX for the moment. Still, using WiX stragically to replace portions of InstallShield has turned out very well for me. – Christopher Painter Oct 18 '10 at 22:05
  • As for the second point: this is exactly what SharpSetup does (+ couple of other things like it adds ability to edit installer GUI in VS designer). – Tomasz Grobelny Nov 06 '10 at 01:30