tags:

views:

78

answers:

2

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 does 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.

+2  A: 

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
Exactly the info I'm looking for. Thanks Yan.
Alek Davis
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
+2  A: 

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

  • Bootstrapper/Chainer - Burn is coming in v3.6 but that's a long, long ways away.
  • 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 ( a big deal where I work )
  • 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.

Christopher Painter
Excellent points. Thanks you. Btw, I assume you use heat to extract COM info from DLLs, not EXEs, right?
Alek Davis
@Chris: +1 for points 2 - 4. Those also affected my work, but I forgot to mention it in my answer.
Yan Sklyarenko
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
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
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
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