Richard > Like anything else, it helps if you read the documentation.
I've just done that. Read what scarce documentation is available about WiX. Read the dusty "tramontana" tutorial cover to cover before I started. Maybe its my mistake, but it took me a long time to realize that WiX is just a wrapper and that it in no way aspires to abstract from MSI. That indeed it assumes you know all about MSI to succeed in the first place. In hindsight it's clear as water but that's now. On the WiX site it says: "The Windows Installer XML (WiX) is a toolset that builds Windows installation packages from XML source code" when it should say something like "The Windows Installer XML (WiX) is a toolset built around a human readable, easily machine generatable XML representation of the otherwise unaltered relational structure of Windows Installer packages" Now, it's true that by the time I realized this, I was knee deep into my installer generator and learned many things the hard way, desperately scratching together morsels of information from bad, outdated and incomplete documentation bits, desperado blogs and mailing lists. Just consider the "pain level" in this mailing list as evidence of that! I should have stopped and bought me a Windows Installer Book. Maybe. However, I (kind of) succeeded in the end. So this is NOT a "non-productive frustration" rant like you suggested. Its more a glance back over my shoulder, still shaking my head in disbelief. My critisism does not come from the frustration of being stuck. It does come from realization, once it was solved, how complicated even the simplest task was! Just some of the snags I encountered (if I'm talking about "custom action", I mean "self-made"): - minor updates/small updates can't be administered by double clicking the .msi; this bug was not fixed since at least 2004 (I think) - adding a bootstrapper to fix this, IMHO breaks the rule of self-containedness - non-advertised shortcuts need to piggy back on a dummy per user(!) registry entry just to pass ICEs; incredibly, even with per machine installations! - advertised shortcuts bloat the .msi if you use external .cabs - advertised shortcut with same binary but different command-line argument did not work (didn't really try to confirm or resolve that, because I switched to non-advertised) - shortcuts can't have dynamic names (set by property) - shortcut folders need to be explicitely removed on uninstall while file directories need not (why?) - ini file entries must be piggy backed to the containing directory component (no, I can't use the registry: it's not network transparent) - IniFileSearch does only work in the Windows folder! - FileSearch produces parent folder when @Id not set: documentation wrong and/or does not work; bad hack work-around required - features without components (empty or all conditioned false) behave eradically (don't know if that's WiX_UI's or MSI's fault) - features can't be declared mutually exclusive (basic requirement IMHO) - because of the last two shortcomings: you can't use the feature tree to configure simple additional setup options; custom dialogs are required - there is no "warning->OK|cancel" action built in (just "error->cancel"); again: custom dialog required for the simplest thing - incredibly there ist not even a properties expression syntax: anything more complex than concatenating properties together and some text, does require a custom action - condition expressions is limited to ~200 odd characters, again requiring custom actions to set dedicated condition properties (condition expressions tend to become huge as there is no "else if"-chaining possible) - component update rules (confusingly named REINSTALLMODE, although active on initial install) are global, not per component - component update rules operate on momentary assumptions, not taking RemoveExistingProducts into consideration, thus leaving some files uninstalled(!) if you choose the wrong (but documented as valid!) sequence; (incredible, considering the huge database driven overhead behind the scene - what is it for, then?) - this one took me ages to believe: MSI does not support setting up the initial version of files (like databases or configuration files) that are thereafter modified by the application and should be left alone both on repair AND on major upgrade (I managed to get one or the other working but not both); one needs to copy/write those files using a custom action (like I said: deploy static stuff only!) - internationalization? don't ask; incredible considering it's just looking up strings (no, our product does not need a language code; it's multilingual); many bugs in WiX there too - the overall confusion, the misinformation about component GUIDs is amazing! in complete violation of the zero overhead rule, ALL components of an installation suffer the full blast from the complexities of the oddest shared component scenario! (our app has no shared components) - auto-generating WiX files and GUIDs? a contradiction! I solved it using type 3 MD5 UUISs on product [version] URI + relative installation key path (a solution that was later independantly added to WiX3, I read somewhere). There was much more. I must have repressed the memory to save some of my mental sanity... And no. Just because I have finally (sort of) clawed my way to the top of that heap, I don't think everybody else should suffer as much as I have. RTFM? No, FTFS! (fix the f**ng software!) Cheers. _Mark -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Richard Gesendet: Montag, 12. Mai 2008 21:10 An: WiX Users Betreff: Re: [WiX-users] yep - back to being 100% frustrated In article <[EMAIL PROTECTED]>, "Markus Kuehni" <[EMAIL PROTECTED]> writes: > 1. learn how to write custom actions and use them liberally Disagree > 2. learn how to write custom dialogs and use them liberally Use custom dialogs only when needed; most projects don't need them. > 3. forget minor and small updates - use major upgrades only Disagree > 4. realize that they only really thought of files and registry entries! Disagree > 5. realize the power of properties set through custom actions For Type 51 (set a property) CAs, Agree. > 6. realize the power of conditions [...] Agree > 6. isolate everything in your application that remains absolutely static > once it's deployed I'm not sure what this is even talking about. > 7. then only(!) setup that static part with MSI/WiX Disagree, if this is talking about files and not items in 8. If only talking about items in 8, then Agree. > 8. setup everything else (such as initial configuration, initial databases, > etc.) either with a custom action or with your application (first run) Agree > 9. expect problems - this "technology" (to insult that word too) is gagging > for trial and error (and shot deadlines) Disagree. Like anything else, it helps if you read the documentation. I've had a summer intern do just with with a relatively complex MSI installation (and this was with MSI 1.2) just by taking the time to read documentation and understand what it says before flailing about in a non-productive fashion and then declaring frustration. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/> ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
