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 |
spsingam
|
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 professional, top-end developers that are stunned with how crappy doing an installer for Windows is. I've never met a single developer that isn't flabbergasted at the hoops you need to jump through to do the simplest things. >"I believe you should write the install then the code - if you can't install it, don't code it." That's simply not the way it works, and that isn't going to change. I get where you are coming from though... the general installation layout of the product does need to be understood sooner rather than later. The reason that the installer isn't "done first" or in parallel with other development is simple - everyone hates it. Getting anyone to do it is like pulling teeth. Nobody on the team wants to be the "installer guy", for good reason. (There is also the fact that it is intuitively backwards to write an installer for something that doesn't exist yet.) Regards, Scott On Mon, May 12, 2008 at 10:01 PM, Rob Mensching <Rob.Mensching@...> wrote: 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. ------------------------------------------------------------------------- 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
|
Some javascript/style in this post has been disabled (why?)
As this was my comment I thought
I should respond. >"I believe you should write the install then the
code - if you can't install it, don't code it." I like doing installs! I know it is a bit flippant to say
write the install first but in my experience no one considers the install when choosing
the latest and greatest development code. If they did (and I feel Microsoft is
to blame here) they wouldn’t touch a lot of the technologies. COM+ was never
properly supported for installs, moving up to date some of the WFP stuff is incredibly
completed to configure. SQL server it still not properly scriptable without
writing you own code. I don’t think it is intuitively
backwards to write an installer first – my analogy is – hydrogen powered cars
might be a good idea but if you can’t buy hydrogen or aren’t going to put the
infrastructure in place there is no point building them. I think the same is
true of code, make sure you can deploy it before you write any code. Together
we can make it happen J Neil Neil Sleightholm ------------------------------------------------------------------------- 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 |
||||||||||||||||||
Josh Rowe
|
Some javascript/style in this post has been disabled (why?)
Agreed. Software Engineering is many times about risk management. Many projects
leave understanding the deployment model of an application until just before it
ships, and then because MSI often isn't well understood and the product wasn't
written to work well with MSI people run into problems that cause the ship date
to fall back because of an installer issue. If you reverse it, and do the install up front, this allows you
to make updating the installer a development responsibility and include the
install in your integration test suite. Doing an MSI integration test is
trivially easy: just spawn the MSIEXEC.EXE process passing your .msi file and
properties w/o a GUI in the way (msiexec /i x.msi /quiet ADDLOCAL=features
MYPROPERTY=1 MYOTHERPROPERTY=2 is what I'm using, I think). Now, if a
developer breaks the install, your automated tests should pick that up and that
developer can fix it long before the ship date. Re. COM+ etc, I ran into exactly that problem and ended up
writing a whole CA system in MSI to deploy our 20+ COM+ applications at my last
job. It took weeks of effort to write deployment operations for our
applications. We started with .vbs and .zip files, but soon progressed to
needing the full functionality of MSI. It turns out that MSI really is quite
simple, as long as you work within what it does well from the beginning rather
than trying to back-port your existing application to be installed via MSI. We
would have chosen a different software model that would have cost a little more
coding time but a lot less deployment effort time if we had spent the time to
understand the deployment model up front. The moral of the story is that deployment procedures really are
part of the source code for an application. They are also risky, so implement
them first to minimize risk. Â jmr From:
wix-users-bounces@...
[mailto:wix-users-bounces@...] On Behalf Of Neil
Sleightholm As this was my
comment I thought I should respond. >"I
believe you should write the install then the code - if you can't install it,
don't code it." I like doing
installs! I know it is a bit
flippant to say write the install first but in my experience no one considers
the install when choosing the latest and greatest development code. If they did
(and I feel Microsoft is to blame here) they wouldn’t touch a lot of the
technologies. COM+ was never properly supported for installs, moving up to date
some of the WFP stuff is incredibly completed to configure. SQL server it still
not properly scriptable without writing you own code. I don’t think it is
intuitively backwards to write an installer first – my analogy is – hydrogen
powered cars might be a good idea but if you can’t buy hydrogen or aren’t going
to put the infrastructure in place there is no point building them. I think the
same is true of code, make sure you can deploy it before you write any code.
Together we can make it happen J Neil Neil Sleightholm ------------------------------------------------------------------------- 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
|
On Tue, May 13, 2008 at 1:26 PM, Josh Rowe <Josh.Rowe@...> wrote:
This is the problem. Deployment SHOULD be trivial. That it is a "risky" part is outrageous. Shouldn't the hard part be in your application's algorithms rather than how to install it? (Your statement also ignores the fact that there is risk in other parts of the development - should those parts also be done first to minimize risk? :-) ) Saying it's risky is fine to justify the point that installers should be dealt with sooner in the development process - Given the current state of installer technology I must sadly agree. But it belittles the fact that the installer technology sucks so bad and is the root problem that needs fixing. Am I the only one that thinks it is somewhat pathetic to not consider a certain technology for the development of my application because I wont' be able to write the installer? Doesn't that just say that A: the technology to be installed (e.g. COM+), and B: the installer technology itself (e.g. MSI) both suck? On a Mac you would just drag and drop the application icon. The very existence of an installer is frowned upon for most things. Why doesn't Microsoft rip-off that instead of the desktop eye-candy? :-) Isn't the goal of WiX to make creating MSI easier without giving up any of it's raw abilities? Should we really have to worry at the WiX level about naming icon Ids with extensions that match what shortcuts that use them point to? That is just plain dumb and WiX should deal with that behind the scenes for us. Just like it deals with the insane requirement for 8.3 filenames (WiX V3). Should I have to hack the component keys when I want to use shortcuts in a simple install for ALL_USERS? No, WiX should handle that too. Regards, Scott ------------------------------------------------------------------------- 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 Josh Rowe
Hi all
> If you reverse it, and do the install up front [...] I agree that things like KnownFolders and related security implications should be considered early in the development process. But this should be a high-level architectural topic, well above the trenches of writing an actual installer. In most respects however, the IT incarnation of the "chicken or the egg" dilemma is *moot*! In any reasonably professional shop you can't just say "hey, MSI doesn't support doing that, we just can't have that in our application!". Not deploying a default configuration file, just because MSI can't do it, is not an option for most if not all professional developers. How does writing the installer up front help here? That's just one example. See the long list of problems I already posted in this thread. Most of these problems just *have* to be solved, whether up front or later doesn't matter. _m ________________________________ Von: wix-users-bounces@... [mailto:wix-users-bounces@...] Im Auftrag von Josh Rowe Gesendet: Dienstag, 13. Mai 2008 19:26 An: WiX Users Betreff: Re: [WiX-users] yep - back to being 100% frustrated Agreed. Software Engineering is many times about risk management. Many projects leave understanding the deployment model of an application until just before it ships, and then because MSI often isn't well understood and the product wasn't written to work well with MSI people run into problems that cause the ship date to fall back because of an installer issue. If you reverse it, and do the install up front, this allows you to make updating the installer a development responsibility and include the install in your integration test suite. Doing an MSI integration test is trivially easy: just spawn the MSIEXEC.EXE process passing your .msi file and properties w/o a GUI in the way (msiexec /i x.msi /quiet ADDLOCAL=features MYPROPERTY=1 MYOTHERPROPERTY=2 is what I'm using, I think). Now, if a developer breaks the install, your automated tests should pick that up and that developer can fix it long before the ship date. Re. COM+ etc, I ran into exactly that problem and ended up writing a whole CA system in MSI to deploy our 20+ COM+ applications at my last job. It took weeks of effort to write deployment operations for our applications. We started with .vbs and .zip files, but soon progressed to needing the full functionality of MSI. It turns out that MSI really is quite simple, as long as you work within what it does well from the beginning rather than trying to back-port your existing application to be installed via MSI. We would have chosen a different software model that would have cost a little more coding time but a lot less deployment effort time if we had spent the time to understand the deployment model up front. The moral of the story is that deployment procedures really are part of the source code for an application. They are also risky, so implement them first to minimize risk. jmr From: wix-users-bounces@... [mailto:wix-users-bounces@...] On Behalf Of Neil Sleightholm Sent: Tuesday, May 13, 2008 12:51 PM To: Scott Palmer; WiX Users Subject: Re: [WiX-users] yep - back to being 100% frustrated As this was my comment I thought I should respond. >"I believe you should write the install then the code - if you can't install it, don't code it." >>That's simply not the way it works, and that isn't going to change. I get where you are coming from though... the general installation layout of the product does need to be >>understood sooner rather than later. The reason that the installer isn't "done first" or in parallel with other development is simple - everyone hates it. Getting anyone to do it >>is like pulling teeth. Nobody on the team wants to be the "installer guy", for good reason. (There is also the fact that it is intuitively backwards to write an installer for >>something that doesn't exist yet.) I like doing installs! I know it is a bit flippant to say write the install first but in my experience no one considers the install when choosing the latest and greatest development code. If they did (and I feel Microsoft is to blame here) they wouldn't touch a lot of the technologies. COM+ was never properly supported for installs, moving up to date some of the WFP stuff is incredibly completed to configure. SQL server it still not properly scriptable without writing you own code. I don't think it is intuitively backwards to write an installer first - my analogy is - hydrogen powered cars might be a good idea but if you can't buy hydrogen or aren't going to put the infrastructure in place there is no point building them. I think the same is true of code, make sure you can deploy it before you write any code. Together we can make it happen J 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 |
||||||||||||||||||
|
Josh Rowe
|
In reply to this post by Scott Palmer-3
Some javascript/style in this post has been disabled (why?)
Scott, I actually agree with you. Deployment SHOULD be trivial. It's
usually risky and non-trivial because people tend to write programs that
require special steps during deployment. By understanding the desired
deployment model up-front you reduce the tendency to write software that operates
with complex deployment models. If you want a deployment model that is a
simple file copy, make sure your software doesn't require any more "registration"
and "deployment" activities than simple file copies. Then, your WiX
file becomes a simple list of components and files, maybe a feature or two. On
the other hand, if your deployment steps require a lot of registration, feature
choices, etc., those facts will be apparent from the increased complexity of
the source code that represents those deployment steps. As people modify the
software, they are responsible for understanding how they are changing the
deployment model. Every piece of software has a deployment model. Somewhere,
someone had to decide how software should be structured, how third party
products integrate with a parent product, etc. When the base platform you are
installing onto requires complicated deployment steps, I guess you're just
screwed. Especially when things come up like: Icon files that are associated strictly with file extensions or
CLSIDs can have any extension, such as .ico. However, Icon files that are
associated with shortcuts must be in the EXE binary format and must be named
such that their extension matches the extension of the target. The shortcut
will not work if this rule is not followed. For example, if a shortcut is to
point to a resource having the key file Red.bar, then the icon file must also
have the extension .bar. Multiple icons can be stuffed into the same icon file
as long as all of the target files have the same extension. I assume this is the madness you were referring to. Probably,
this has more to do with how explorer works than with how MSI works, I don't
really know. I do think that it is pathetic to not consider a technology for the
development of an application because you can't write the installer for it. But
instead of blaming WiX or MSI, I blame the author of the technology. If the
developer of that technology made good decisions about how to deploy software that
uses that technology, you wouldn't be forced into making those hard choices. For
example, if COM+ registration was as simple as copying a .xml file to a specific
directory, deployment of COM+ applications would be simple and none of us would
be moaning about it. But the authors of the COM+ technology didn't consider how
its clients would actually go about deploying a COM+ application or a whole suite
of COM+ applications. Therefore, COM+ deployment sucks because MS didn't come
up with a good story for it, not because MSI or WiX didn't handle it. This begs me to ask: why does the installer suck when people
just wrote bad software? If all software followed simple file-based deployment
models, would MSI still suck? I'm not sure that it would. If explorer
shortcut files didn't use some crappy proprietary format would they be nearly
as difficult to get installed? Probably not. But the explorer team didn't
consider how deployments should work when writing explorer. Of course,
hindsight is always 20/20, and it's really only recently that people are really
paying much attention to deployment of software as compared to authoring it in
the first place. For your own software: learn from MS's mistakes and don't write
it the same way. Â jmr From: Scott Palmer
[mailto:swpalmer@...] On Tue, May 13, 2008 at 1:26 PM, Josh Rowe <Josh.Rowe@...> 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 |
||||||||||||||||||
ILT
|
Some javascript/style in this post has been disabled (why?)
Since this
conversation is going nowhere (perhaps because WiX is dependent on MSI, and MSI
seems to predicate most of the limitations) I would like to introduce a
tangent: whether other install / deployment / packaging technologies have made
an impact. How
about Altiris Software Delivery Solution (now owned by Symantec)? I don’t
think it has changed since mid-2005, so I’m assuming it’s had
almost no beneficial effect. From:
wix-users-bounces@...
[mailto:wix-users-bounces@...] On Behalf Of Josh Rowe Scott, I actually agree with you. Deployment SHOULD be
trivial. It Every piece of software has a deployment model. Somewhere,
someone had to decide how software should be structured, how third party
products integrate with a parent product, etc. When the base platform you
are installing onto requires complicated deployment steps, I guess you Icon files that are associated strictly with file extensions or
CLSIDs can have any extension, such as .ico. However, Icon files that are
associated with shortcuts must be in the EXE binary format and must be named
such that their extension matches the extension of the target. The shortcut
will not work if this rule is not followed. For example, if a shortcut is to
point to a resource having the key file Red.bar, then the icon file must also
have the extension .bar. Multiple icons can be stuffed into the same icon file
as long as all of the target files have the same extension. I assume this is the madness you were referring to.
Probably, this has more to do with how explorer works than with how MSI works,
I don I do think that it is pathetic to not consider a technology for
the development of an application because you can This begs me to ask: why does the installer suck when people
just wrote bad software? If all software followed simple file-based
deployment models, would MSI still suck? I For your own software: learn from MS jmr No virus found in this incoming message.
[ILT Personal (il.thomas@...).vcf] BEGIN:VCARD VERSION:2.1 N:Personal;ILT FN:ILT Personal (il.thomas@...) EMAIL;PREF;INTERNET:il.thomas@... REV:20070620T050625Z END:VCARD ------------------------------------------------------------------------- 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 Chris Mumford-2
Hi all > If you reverse it, and do the install up front [...] I agree that things like KnownFolders and related security implications should be considered early in the development process. But this should be a high-level architectural topic, well above the trenches of writing an actual installer. In most respects however, the IT incarnation of the "chicken or the egg" dilemma is *moot*! In any reasonably professional shop you can't just say "hey, MSI doesn't support doing that, we just can't have that in our application!". Not deploying a default configuration file, just because MSI can't do it, is not an option for most if not all professional developers. How does writing the installer up front help here? That's just one example. See the long list of problems I already posted in this thread. Most of these problems just *have* to be solved, whether up front or later doesn't matter. _m ________________________________ Von: wix-users-bounces@... [mailto:wix-users-bounces@...] Im Auftrag von Josh Rowe Gesendet: Dienstag, 13. Mai 2008 19:26 An: WiX Users Betreff: Re: [WiX-users] yep - back to being 100% frustrated Agreed. Software Engineering is many times about risk management. Many projects leave understanding the deployment model of an application until just before it ships, and then because MSI often isn't well understood and the product wasn't written to work well with MSI people run into problems that cause the ship date to fall back because of an installer issue. If you reverse it, and do the install up front, this allows you to make updating the installer a development responsibility and include the install in your integration test suite. Doing an MSI integration test is trivially easy: just spawn the MSIEXEC.EXE process passing your .msi file and properties w/o a GUI in the way (msiexec /i x.msi /quiet ADDLOCAL=features MYPROPERTY=1 MYOTHERPROPERTY=2 is what I'm using, I think). Now, if a developer breaks the install, your automated tests should pick that up and that developer can fix it long before the ship date. Re. COM+ etc, I ran into exactly that problem and ended up writing a whole CA system in MSI to deploy our 20+ COM+ applications at my last job. It took weeks of effort to write deployment operations for our applications. We started with .vbs and .zip files, but soon progressed to needing the full functionality of MSI. It turns out that MSI really is quite simple, as long as you work within what it does well from the beginning rather than trying to back-port your existing application to be installed via MSI. We would have chosen a different software model that would have cost a little more coding time but a lot less deployment effort time if we had spent the time to understand the deployment model up front. The moral of the story is that deployment procedures really are part of the source code for an application. They are also risky, so implement them first to minimize risk. jmr From: wix-users-bounces@... [mailto:wix-users-bounces@...] On Behalf Of Neil Sleightholm Sent: Tuesday, May 13, 2008 12:51 PM To: Scott Palmer; WiX Users Subject: Re: [WiX-users] yep - back to being 100% frustrated As this was my comment I thought I should respond. >"I believe you should write the install then the code - if you can't install it, don't code it." >>That's simply not the way it works, and that isn't going to change. I get where you are coming from though... the general installation layout of the product does need to be >>understood sooner rather than later. The reason that the installer isn't "done first" or in parallel with other development is simple - everyone hates it. Getting anyone to do it >>is like pulling teeth. Nobody on the team wants to be the "installer guy", for good reason. (There is also the fact that it is intuitively backwards to write an installer for >>something that doesn't exist yet.) I like doing installs! I know it is a bit flippant to say write the install first but in my experience no one considers the install when choosing the latest and greatest development code. If they did (and I feel Microsoft is to blame here) they wouldn't touch a lot of the technologies. COM+ was never properly supported for installs, moving up to date some of the WFP stuff is incredibly completed to configure. SQL server it still not properly scriptable without writing you own code. I don't think it is intuitively backwards to write an installer first - my analogy is - hydrogen powered cars might be a good idea but if you can't buy hydrogen or aren't going to put the infrastructure in place there is no point building them. I think the same is true of code, make sure you can deploy it before you write any code. Together we can make it happen J 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 |
||||||||||||||||||
|
Neil Sleightholm
|
Some javascript/style in this post has been disabled (why?)
>>In any reasonably professional shop you can't just say "hey, MSI doesn't >>support doing that, we just can't have that in our application!". I don't think anyone was suggesting that but if you new it would need a custom action, for example, you could either not do it that way or schedule in writing one. ________________________________ Von: wix-users-bounces@... [wix-users-bounces@...] Im Auftrag von Josh Rowe Gesendet: Dienstag, 13. Mai 2008 19:26 An: WiX Users Betreff: Re: [WiX-users] yep - back to being 100% frustrated Agreed. Software Engineering is many times about risk management. Many projects leave understanding the deployment model of an application until just before it ships, and then because MSI often isn't well understood and the product wasn't written to work well with MSI people run into problems that cause the ship date to fall back because of an installer issue. If you reverse it, and do the install up front, this allows you to make updating the installer a development responsibility and include the install in your integration test suite. Doing an MSI integration test is trivially easy: just spawn the MSIEXEC.EXE process passing your .msi file and properties w/o a GUI in the way (msiexec /i x.msi /quiet ADDLOCAL=features MYPROPERTY=1 MYOTHERPROPERTY=2 is what I'm using, I think). Now, if a developer breaks the install, your automated tests should pick that up and that developer can fix it long before the ship date. Re. COM+ etc, I ran into exactly that problem and ended up writing a whole CA system in MSI to deploy our 20+ COM+ applications at my last job. It took weeks of effort to write deployment operations for our applications. We started with .vbs and .zip files, but soon progressed to needing the full functionality of MSI. It turns out that MSI really is quite simple, as long as you work within what it does well from the beginning rather than trying to back-port your existing application to be installed via MSI. We would have chosen a different software model that would have cost a little more coding time but a lot less deployment effort time if we had spent the time to understand the deployment model up front. The moral of the story is that deployment procedures really are part of the source code for an application. They are also risky, so implement them first to minimize risk. jmr From: wix-users-bounces@... [wix-users-bounces@...] On Behalf Of Neil Sleightholm Sent: Tuesday, May 13, 2008 12:51 PM To: Scott Palmer; WiX Users Subject: Re: [WiX-users] yep - back to being 100% frustrated As this was my comment I thought I should respond. >"I believe you should write the install then the code - if you can't install it, don't code it." >>That's simply not the way it works, and that isn't going to change. I get where you are coming from though... the general installation layout of the product does need to be >>understood sooner rather than later. The reason that the installer isn't "done first" or in parallel with other development is simple - everyone hates it. Getting anyone to do it >>is like pulling teeth. Nobody on the team wants to be the "installer guy", for good reason. (There is also the fact that it is intuitively backwards to write an installer for >>something that doesn't exist yet.) I like doing installs! I know it is a bit flippant to say write the install first but in my experience no one considers the install when choosing the latest and greatest development code. If they did (and I feel Microsoft is to blame here) they wouldn't touch a lot of the technologies. COM+ was never properly supported for installs, moving up to date some of the WFP stuff is incredibly completed to configure. SQL server it still not properly scriptable without writing you own code. I don't think it is intuitively backwards to write an installer first - my analogy is - hydrogen powered cars might be a good idea but if you can't buy hydrogen or aren't going to put the infrastructure in place there is no point building them. I think the same is true of code, make sure you can deploy it before you write any code. Together we can make it happen J 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 ------------------------------------------------------------------------- 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 |
||||||||||||||||||
chrpai
|
I think they are. Everytime you hear things like `solve the applicartion problem`, `custom actions are an admission of failure`, `we won't implement that feature`, `There are few setup experiences more stable than an application that simply needs a bunch of files installed`, I believe that very notion is being implied. On one hand I understand why you'd say it, and in theory I agree with it. But in practice it's not possible. The reality is even if you are lucky enough to be in a shop where the developers/architects believe that their design choices should be guided by integration ( read build/install ) implications, they rarely have the specialized domain knowledge to know what those implications are because they usually never touched a build or an install while they were cutting their programming teath. Setup is rarely taught, it's not included in books, it's not
included in certifications and if you offer up a lecture at work or at a code camp you won't get anyone to come. The reality is they are much more interested in discussing the merits of the latest new thing. ( Agile, Scrum, ALT.NET, WCF, WPF, SliverLight, DSL's are very popular topics at my local DNUG ... no one is interested in MSI ). So from my perspective, I try to influence upstream design decisions but when it doesn't happen the way I'd like, I do what all good Marines do: Adapt and Overcome.
|
||||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
