yep - back to being 100% frustrated
|
|
Chris Mumford-2
|
Man:
I can't believe how much making Windows Installer based installs suck - I mean really sucks! Did we just invent this technology to make us hate our lives?
And WiX doesn't make it any easier.
I'm calling it a night.
Peace out man...
------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ WiX-users mailing list WiX-users@... https://lists.sourceforge.net/lists/listinfo/wix-users |
|||||||||||||||||
Siva Poobalasingam
|
well.. the local supermarket here .. is looking for a Security Guard???
if u want i can help pass ya resume... 
|
||||
Markus Kuehni
|
In reply to this post by Chris Mumford-2
Some javascript/style in this post has been disabled (why?)
Hi Chris
I can only second your opinion. It's almost unbelievable, how difficult
even the most common, primitive task is.
One has this long-honed professional developer instinct that constantly
tells you "there must be an easier way, I just have to find it". Believe me: in
case of MSI there is none! Stop wasting your time searching for any sign of
logic, design or even common sense.
And it took me a while to realize, that WiX is only a wrapper. No
abstraction whatsoever. So dont't blame WiX, except maybe for not making
the "thin wrapper catch" clear from the
beginning.
It helps to cross the custom action / custom dialog barrier. Don't even
try without, even if you think your application is plain vanilla!
There has to be an awful lot of (pre-)historical
bagagge that crippels MSIs "design" (to insult that word). I guess its a
cross-breed between declarative and imperative princibles terribly gone
wrong and awfully neglected since.
Survival guide:
0. switch off your expectations
1. learn how to write custom
actions and use them liberally
2. learn how to write custom dialogs and use them
liberally
3. forget minor and small updates - use major upgrades
only
4. realize that they only really thought of files and registry
entries! Shortcuts, .ini-file entries, in some cases even directories,
etc. were seemingly "tacked on later" and are terribly crippled because
they have to somehow "piggy back" either on a file, directory or registry
key; use the ugly hacks in the internet and don't waste your time searching
for elegance
5. realize the power of properties set through custom
actions
6. realize the power of conditions (often you can't dynamically change
even the simplest things, like i.e. the name of a shortcut. But you can switch
OFF one component and switch ON another - sometimes that
helps)
6. isolate everything in your application that remains absolutely static
once it's deployed
7. then only(!) setup that static part with MSI/WiX
8. setup everything else (such as initial configuration, initial
databases, etc.) either with a custom action or with your application (first
run)
9. expect problems - this "technology" (to insult that word too) is
gagging for trial and error (and shot deadlines)
Hope that helps a bit.
-Mark
Von: wix-users-bounces@... [mailto:wix-users-bounces@...] Im Auftrag von Chris Mumford Gesendet: Montag, 12. Mai 2008 06:13 An: wix-users@... Betreff: [WiX-users] yep - back to being 100% frustrated Man:
I can't believe how much making Windows Installer based installs suck - I
mean really sucks! Did we just invent this technology to make us hate our
lives?
And WiX doesn't make it any easier.
I'm calling it a night.
Peace out man...
------------------------------------------------------------------------- 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@... https://lists.sourceforge.net/lists/listinfo/wix-users |
|||||||||||||||||
Richard-45
|
In article <013801c8b461$680f26f0$0301a8c0@venom>, "Markus Kuehni" <markus.kuehni@...> 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@... https://lists.sourceforge.net/lists/listinfo/wix-users |
|||||||||||||||||
|
Chris Mumford-2
|
In reply to this post by Markus Kuehni
Definitely interesting commentary. I'd have to say that I agree with Richard and mostly disagree with Markus' comment - although I see where he's coming from. My guess is that his rules are mostly born from experience and he's chosen the most pragmatic approach that seems likely to work. It's my understanding that nearly all custom actions are improperly written and I really want to try to create an installation with zero CA's if possible. I'm sure that when I get to some crazy things like deleting files and registry values (that no installer would ever want to do <sarcasm />) I'll have to write a CA.
I did my first MSI somewhere around 8-9 years ago and have used most of the major installer tools from Wise, InstallShield, WiX, and MakeMSI. It's been a good five years since I've wrestled with Windows Installer - staying away for obvious reasons. So now I'm rewriting one of my installations (which has always had issues) and I'm going to try to do it "right" with WiX. So I get it to install a few files in the right folder, and my very next step is to create a simple stupid shortcut - and it doesn't work with an ICE48 error. Searching around didn't really turn up much, but there was a Google hit on Rob's site - which was down - Grrrr. Call me old fashioned but I think that any solution should make it easy to do what 80% of the users want. Maybe this is a bad example but who cares a flip about advertised features. I don't see this as a feature at all. It just complicates our lives as installer writers and it complicates the lives of the end user too. Sure this isn't a WiX thing - it's a *feature* of Windows Installer, but man I wish WiX made things easier for us - and it could. Well anyhow, I've gotta get back to my day gig now. Thanks for your thoughts. BTW stay in touch Siva - I may be begging you forward my resume for that security guard gig after a few more weeks of playing with this tech. ;-) Cheers. On Mon, May 12, 2008 at 11:53 AM, Markus Kuehni <markus.kuehni@...> wrote:
------------------------------------------------------------------------- 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@... https://lists.sourceforge.net/lists/listinfo/wix-users |
|||||||||||||||||
|
Markus Kuehni
|
In reply to this post by Richard-45
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: wix-users-bounces@... [mailto:wix-users-bounces@...] 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 <013801c8b461$680f26f0$0301a8c0@venom>, "Markus Kuehni" <markus.kuehni@...> 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@... 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@... https://lists.sourceforge.net/lists/listinfo/wix-users |
|||||||||||||||||
|
Richard-45
|
In reply to this post by Chris Mumford-2
In article <42852f730805121445k510107ffs9fe3eaa9db6afdcb@...>, "Chris Mumford" <cmumford@...> writes: > So now I'm rewriting one of my installations (which has always had issues) > and I'm going to try to do it "right" with WiX. So I get it to install a few > files in the right folder, and my very next step is to create a simple > stupid shortcut - and it doesn't work with an ICE48 error. Searching around > didn't really turn up much, but there was a Google hit on Rob's site - which > was down - Grrrr. Creating plain shortcuts is rather straightforward, but for some reason its something that people seem to get hung up on relatively often. From the MSI documentation for the Shortcut table: "Target The shortcut target. [...] For a non-advertised shortcut, the installer evaluates this field as a Formatted string. The field should contains a property identifier enclosed by square brackets ([ ]), that is expanded into the file or a folder pointed to by the shortcut. For more information, see the CreateShortcuts action." If you're getting an ICE48 error ("ICE48 checks for directories that are hard-coded to local paths in the Property table."), then that doesn't have anything to do with shortcuts. In your Target column of your shortcut, you should be using the properties associated with directories as you've defined them in rows of the Directory table. If you're trying to create shortcuts to items in folders you didn't create, then use AppSearch to set the directory property. That WiX isn't an abstraction that raises you above having to understand the MSI table schema is a valid observation. I don't know if its a valid criticism of WiX as having an abstraction that raises you above the schema wasn't a design goal of WiX. You might as well criticize WiX because it doesn't solve world hunger. My aversion to CA's is that for some reason people immediately rush to create a CA when most of the time the standard actions already do what they want. Then there's the stupid VS.NET documentation that tells people to write CA's to get around the limitations of their authoring tool and not Windows Installer... Yet, CAs are there for a reason and sometimes you need them. But getting all the error handling working properly in a CA isn't easy and most of the bugs that I've fixed in complex installs revolved around CAs that failed in some peculiar way and didn't handle the failure properly. -- "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@... https://lists.sourceforge.net/lists/listinfo/wix-users |
|||||||||||||||||
|
Markus Kuehni
|
Hi Richard
> Creating plain shortcuts is rather straightforward It's not the shortcut @Target but the @Name I wanted to vary. >Shortcut [..] ICE There seems NOT to be any other solution than to use a dummy current user(!) registry entry according to various blog entries by the "gurus". I just want to have a non-advertised Shortcut to an exe that I install and one to another (third party) exe I found using FileSearch. Solution: http://robmensching.com/blog/archive/2007/04/27/How-to-create-an-uninstall-s hortcut-and-pass-all-the.aspx (the uninstaller example is obviously a bad thing to do, but the solution applies to my problem as well) If you know another solution (through WiX), glad to revise that. > You might as well criticize WiX because it doesn't solve world hunger. Like I said: "So dont't blame WiX, except maybe for not making the "thin wrapper catch" clear from the beginning." >My aversion to CA's is that for some reason people immediately rush to >create a CA when most of the time the standard actions already do what >they want. That's exactly how I felt at the beginning. I set goals very alike those of Chris in his second post. "zero CA's if possible". I can only laugh at that now. Just two examples Pop Quiz 1: You have a configuration file (.ini, XML, database, etc.). The user can change the preferences saved in it during normal use of the application (no elevated priviledges required). You would like to provide an initial setting with your installer. But of course the file should not be overwritten on [major] update or repair. Oulandish requirement? I don't think so. Possible with MSI? No! Pop Quiz 2: I want to read an .ini file entry from outside the Windows folder into a property. Why .ini and not Registry? In our case it's because the .ini may reside on a network server. Million other reasons thinkable. Outlandish requirement? I don't think so. Possible with MSI? No! Regarding self-made CAs: I'm a professional, university trained developer with lots of theoretical and practical background in multi-user concurrent transaction processing, serializability and all. I know all about the complexities of "commits and rollbacks". I know enough NOT to meddle with the transactional actions of the installer. My CAs are purely side effect free, except for setting properties. The real work is left to MSI. The CAs read some .ini files and mostly perform logic on properties that MSI can't. They set new properties to condition actions, components and dialogs. This is also the reason why I postponed the setup of non-static files (Pop Quiz 1) to the first application start, so I don't have to handle the rollback case. No really. Chris' initial statement really sums it up: "I can't believe how much making Windows Installer based installs sucks - I mean really sucks! Did we just invent this technology to make us hate our lives?" Cheers, Mark. -----Ursprüngliche Nachricht----- Von: wix-users-bounces@... [mailto:wix-users-bounces@...] Im Auftrag von Richard Gesendet: Dienstag, 13. Mai 2008 00:07 An: WiX Users Betreff: Re: [WiX-users] yep - back to being 100% frustrated In article <42852f730805121445k510107ffs9fe3eaa9db6afdcb@...>, "Chris Mumford" <cmumford@...> writes: > So now I'm rewriting one of my installations (which has always had issues) > and I'm going to try to do it "right" with WiX. So I get it to install a few > files in the right folder, and my very next step is to create a simple > stupid shortcut - and it doesn't work with an ICE48 error. Searching around > didn't really turn up much, but there was a Google hit on Rob's site - which > was down - Grrrr. Creating plain shortcuts is rather straightforward, but for some reason its something that people seem to get hung up on relatively often. From the MSI documentation for the Shortcut table: "Target The shortcut target. [...] For a non-advertised shortcut, the installer evaluates this field as a Formatted string. The field should contains a property identifier enclosed by square brackets ([ ]), that is expanded into the file or a folder pointed to by the shortcut. For more information, see the CreateShortcuts action." If you're getting an ICE48 error ("ICE48 checks for directories that are hard-coded to local paths in the Property table."), then that doesn't have anything to do with shortcuts. In your Target column of your shortcut, you should be using the properties associated with directories as you've defined them in rows of the Directory table. If you're trying to create shortcuts to items in folders you didn't create, then use AppSearch to set the directory property. That WiX isn't an abstraction that raises you above having to understand the MSI table schema is a valid observation. I don't know if its a valid criticism of WiX as having an abstraction that raises you above the schema wasn't a design goal of WiX. You might as well criticize WiX because it doesn't solve world hunger. My aversion to CA's is that for some reason people immediately rush to create a CA when most of the time the standard actions already do what they want. Then there's the stupid VS.NET documentation that tells people to write CA's to get around the limitations of their authoring tool and not Windows Installer... Yet, CAs are there for a reason and sometimes you need them. But getting all the error handling working properly in a CA isn't easy and most of the bugs that I've fixed in complex installs revolved around CAs that failed in some peculiar way and didn't handle the failure properly. -- "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@... 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@... https://lists.sourceforge.net/lists/listinfo/wix-users |
|||||||||||||||||
Rob Mensching-2
|
In reply to this post by Markus Kuehni
1. Yes, WiX is a relatively thin layer above MSI. Some people liken it to assembly but I still think C/C++ is more appropriate. The only thing that makes C++ reasonable is a wide range of libraries to help do some heavy lifting (like file IO (libc, kernel32) or drawing pixels on the screen (gdi32)). We're still building up those layers.
2. I basically agree with all of the issues raised below. I don't see anything new in that list of pain points with the Windows Installer. 3. However, the real question is how would you fix them in a way that always works? So far we have been very cautious about "automagically fixing things" since there are a lot of different valid ways to solve the same problem. -----Original Message----- From: wix-users-bounces@... [mailto:wix-users-bounces@...] On Behalf Of Markus Kuehni Sent: Monday, May 12, 2008 15:02 To: 'Richard'; 'WiX Users' Subject: Re: [WiX-users] yep - back to being 100% frustrated 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: wix-users-bounces@... [mailto:wix-users-bounces@...] 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 <013801c8b461$680f26f0$0301a8c0@venom>, "Markus Kuehni" <markus.kuehni@...> 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@... 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@... 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@... https://lists.sourceforge.net/lists/listinfo/wix-users |
|||||||||||||||||
Neil Sleightholm
|
Just to add my thoughts on this.
For me the key thing was learning that deployment is hard, no very hard! I was relatively late to MSIs but have used Wise Installer and SMS Installer (same thing really) to write many script based installs. I found these tools hide far too much from me and actually made it too easy, I think I was just lucky that installs worked and I always ignored uninstall. In one corporate environment we decided that all installs would be install only and that uninstall meant rebuild the box! IMHO part of the reason for deployment being hard is that application designers rarely think about it, then 2 days before shipping someone says "write an install for this". Rob wrote an interesting blog about this http://robmensching.com/blog/archive/2007/08/10/SDD-before-TDD.aspx and as I commented before, I believe you should write the install then the code - if you can't install it, don't code it. I find a lot of the odd things I am asked to do installs could have been solved in the application much easier and if I can push back I do but it is usually too late. Neil Neil Sleightholm X2 Systems Limited neil@... ------------------------------------------------------------------------- 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@... https://lists.sourceforge.net/lists/listinfo/wix-users |
|||||||||||||||||
Scott Palmer-3
|
In reply to this post by Rob Mensching-2
Well I dropped by to ask for help (I wonder if I will get it now :-)) but first I have to chime in and agree with Chris and Mark. I dislike that what I am about to post is basically a rant, but I think there are a lot more people on their side than others seem to think, so I want to show my support. Rob, it's worse than assembly... I can handle assembly, it's just low level, there is still logic and order to it (well, less so with Intel.. but still). Many of the statements in this thread defending WiX demonstrates to me how out of touch some people (the development team?) are with the needs of the users. Of course the fact that MSI sucks beyond belief isn't the fault of WiX. That WiX does so little to remedy the situation is something that can be addressed though. If it wasn't a "design goal" one wonders why? Your #3 - "being very cautious" is valid of course... but there is a very strong need to "automagically fix things" because what you've got with MSI is a REALLY big mess. I still laugh that short filenames are required in what is labelled as version 2... that is so far off the mark. I've even seen comments relating to V3 (where short filenames were addressed) that go something like "apparently some developers found that useful" maybe I missed the sarcasm, but it seemed as if the WiX development team didn't get how brain dead the short filenames were in the first place? Keeping short filenames around at all has got to be one of Microsoft's biggest blunders, the fact that MSI only runs on systems that support long filenames adds to the pain. I still to this day am dumbfounded that anyone uses WiX V2, they are masochists I guess. (comments below are referring to other messages, not Rob's that I have quoted at the bottom) >> 2. learn how to write custom dialogs and use them liberally >Use custom dialogs only when needed; most projects don't need them. So very wrong. They are needed.. in my experience, almost always. In the cases where you don't need them, you usually don't even need an installer at all - though I think all software on Windows should require an installer that is properly integrated into the Add/Remove programs database before the system will even run it. It would probably plug a few user vulnerabilities in a much friendlier way than the Vista disaster, It's just not practical because of the difficulty in making a proper installer - a fault of MSI. >"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!" Full agreement here. We have a team of very bright developers.. and all of them stare in disbelief at what needs to be done for the installer. When I have to seriously struggle with the decision to write an installer framework from scratch or suffer though the poorly thought out crap that is available already - something is wrong. I choose to suffer through MSI because it appears to be "the right way to install software on Windows" - why else is it "built-in"? We moved to WiX because the other products like Install Shield/Install Anywhere were too narrow and only worked well for the most trivial installs - and they were severely overpriced for that. Hearing that internal projects at Microsoft were using WiX gave us some confidence in it. I do need to re-state that I realize most of the pain points with WiX are because of the complete rubbish that WiX has to work with - MSI. MSI is so filled with seemingly arbitrary restrictions and odd-ball requirements. Simple things like getting icons to work properly for example are needlessly encumbered with nonsensical requirements. That's a perfect example of something WiX could "fix" but doesn't. Another example is the simple task of getting the "back" button to work in a UI if you need a few custom dialogs (with some of them conditionally shown). That the end user EVER has to code the logic for the back button is ridiculous. I realize that the way MSI does UIs is much lower level, that having a back button at all isn't a requirement of MSI... but be practical - handling the common case of having the back button is a good thing and doesn't need to interfere with anyone that chooses to slap some odd-ball UI on their installer. I think the WiX development team underestimates the number of p | |||||||||||||||||