I just had to respond to this. Sorry for picking it back up. XCOPY simplicity in an MSI package is very easy to do. You use empty component guids and change your ProductCode on every single build. You don't ever patch, and removal doesn't do anything (files are left behind). For a complete solution, suppress the component and product registration actions and you won't show up in ARP or have any other side-effects of MSI installation. You can even use SelfReg for your DLLs!
BINGO: XCOPY in an MSI package. And, you get a more user-friendly Files-In-Use as a bonus (xcopy never did that!). Now, you also don't get COM/Registry registration, Firewall registration, Shell integration, Web-Site registration, Application repair, or any of a thousand other things that xcopy never did either. And, if you share any binaries you are back in DLL hell. There's a reason we don't do xcopy deployments anymore for the past ten years, and that is because the platform doesn't support xcopy deployed products for much more than trivial platform integrations. Most developers want a lot of things made more simple, but we have learned to compromise and trade some complexity for some shared increased functionality. Most installations are not 7000 files, and most don't change their file lists daily, and for that majority, code-the-components-once-and-keep-them-in-source-code is absolutely the right way to go (it even gives you the benefit of a build exception/error if a file is missing). For those very few caught in the masses of constantly changing file lists, they need to ask what they really need from the platforms they deploy against and what level of effort is warranted. Last time I asked my developers, they didn't want to not think, they just don't know what to ask; and what they want is the simplest structure within which they can get the best deployment strategy they need for the parts of the platforms they write against. Since MSI is a platform for enabling just about any deployment strategy possible on a modern Microsoft Win dows platform, it has to enable support for all kinds of crap that xcopy could never do. While the architecture of Windows Installer doesn't lend itself to ease-of-correct-use, it does enable almost any scale deployment solution to be created in a correct fashion. It isn't that the analysis has paralyzed us, it is that no one has volunteered a better architecture that works as well with the admittedly too-complicated platform (Windows and all its "environments") we have. The best way out of this is to simplify those environments (COM/IIS/etc.) from a deployment perspective and we can then craft a replacement deployment platform that is simpler. But of course platforms haven't been required to think through most deployment scenarios when engineering their platforms (COM+, anyone?). In fact, platforms on Windows don't even have to come from Microsoft. Until then, you can simplify for some with a different platform, but at the cost of dropping support for others. There are enough of those others that an industry dedicated to deployment technologies is alive and well. Besides, if programming were really easy to do right, we wouldn't ask for college education for those entering the field, and we wouldn't be paid enough to support our families, since solutions involving not thinking can be employed by anyone, correct? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Wednesday, July 23, 2008 10:32 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Merge Module Help What feedback? All I saw was a childish quip/troll post. Personally I'm sick of the component rules and it's associated gotchas. These are artificial problem caused by an overly complicated design. Developers want xcopy simplicity. The features are nice from a platform presevatin perspective but nearly 10 years have gone by since it was invented and we are still sitting around a table scratching our head how to solve the authoring headaches that it created. Talk about analysis paralysis. --- On Wed, 7/23/08, Rob Mensching <[EMAIL PROTECTED]> wrote: > From: Rob Mensching <[EMAIL PROTECTED]> > Subject: Re: [WiX-users] Merge Module Help > To: "General discussion for Windows Installer XML toolset." > <wix-users@lists.sourceforge.net> > Date: Wednesday, July 23, 2008, 11:39 AM > Hey, wait a minute here. > > First, Automating Component/@Guids requires a bullet-proof > solution. The side-effects of violating the Component Rules > are nasty on two fronts a) once violated there are no real > good ways out (something will get messed up on the > user's machine) and b) you don't usually realize > you've violated the rules until it is too late (like > when you need a critical security fix). If you're > going to suggest a solution to this problem then expect it > to be "pedantically picked through". From there > you should adapt your solution based on feedback or specify > how the feedback is actually addressed by the solution or > note that your solution doesn't work and try something > different. Partial success isn't an option here > because the "partial failures" are so horrible. > > > Second, please take the personal comments elsewhere. This > is where we talk about the WiX toolset. > > > Thank you. > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Bob Arnson > Sent: Wednesday, July 23, 2008 08:54 > To: [EMAIL PROTECTED] > Cc: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > Christopher Painter wrote: > > Once again you pedantically pick through my comment > without actually offering anything constructive yourself. > > Wow, I'm really put in my place, aren't I? > > -- > sig://boB > http://joyofsetup.com/ > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge > Build the coolest Linux based applications with Moblin SDK > & win great prizes > Grand prize is a trip for two to an Open Source event > anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge > Build the coolest Linux based applications with Moblin SDK > & win great prizes > Grand prize is a trip for two to an Open Source event > anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
