WiX isn't hard. Keeping to MSI's rules is. Creating visual designers to abstract people away from the complexities can be a bad thing. For example, try to get your software certified for Vista without a good understanding of MSI and ICE.
InstallShield Developer/7 was terrible, 10/X/10.5 wasn't much better. 2008 is good, however I still find myself in the direct editor a lot, avoiding the fancy InstallShield GUI. That's just my opinion/experience. WiX has made me a better packager (with both WiX and InstallShield). I say get the CLI tools right before adding visual designers (increasing the complexity/opportunity for issues). Cheers, David. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Christopher Painter > Sent: Monday, 2 June 2008 11:04 PM > To: General discussion for Windows Installer XML toolset.; Friedrich > Dominicus > Subject: Re: [WiX-users] (was: RE: WIX 3.0 release date) > > Up until just 2 weeks ago the Managed Code debate was certainly > applicable. Also I believe that your desire to be 100% perfect on > authoring content ( a good goal ) is conflicting with users goals to > decrease the learning curve and accelerate authoring with visual > designers. But you usually don't frame it in that context, you > usually just say something along the lines of a `I'm a command line > guy` or `notepad is fine`. Users clearly don't think that as I > often get comments talking about how hard WiX is. > > In the end, I don't know if refusing to automate authoring really > helps any as people can still get unexpected results. Take the recent > MergeMod.dll problem in WiX. That was a pain point as a result of > OMUS and MSI's narrow view of what you should and should not do. > InstallShield has a checkbox called always overwrite that helps on a > per component basis but you still have to know to check it. > > I was at InstallShield a year and a half ago and one of the things > that I suggested was to extend validation across builds. Write now > validation can catch some problems with a package but it can't catch > the type of problem that MergeMod caused. But if you could identify > the database elements that influence all of these unexpected behaviors, > catalog them and then holistically validate the package against > previous packages you could problem solve many of them. Then you > could probably consider more automated authoring. > > > Rob Mensching <[EMAIL PROTECTED]> wrote: > That article focuses on the case where the leaders of the project > become detached from the users of the project. It really doesn't matter > if the project is open source or commercial, the results are the same. > Users quit using the project. For commercial entities that usually ends > up affecting the bottom line (the article refers to this as "get > developers fired"). For open source projects the project ends up with > fewer users or ends up forking and going in different directions. > > To bring the point back home, I can't currently think of any cases > where this is a problem for the WiX toolset. There are plenty of things > that need to be fixed/addressed in the WiX toolset but I don't think > the leaders of the project or the users of the project disagree here. > The two cases I can think of where there has been some contention: > > 1. FragmentRef. Fragment ref was a WiX v2 concept that over time I > found wasn't really necessary. What I found was everyone was putting > FragementRefs everywhere. In WiX v3 we removed the FragmentRef concept > and some people complained. The complaints were exactly what I was > looking for because it helped us find the remaining places where > references were not being automatically generated by the WiX toolset. > Now that those are fixed, functionality that was not necessary was > removed for a better system... I think. > > 2. Component Rules. These things have been the bane of my existence > since the end of my internship on the Windows Installer team back in > 1998. I documented the rules and sent them around to all of the > developers back then. I was incredulous that they could be real but as > well all know now they are. The Component Rules make auto-generating > content in the core toolset very, very difficult because so much > management infrastructure has to be in place to make sure the Component > GUIDs remain stable. Otherwise, a product will end up unpatchable or > worse. IMHO it is not acceptable for the WiX toolset to autogenerate > content that makes one's packages to be unpatchable. I know there are > some tools out there that solve some of the problems with Component > GUID generation but they aren't perfect. Still working on the "perfect > solution" here since being partially wrong has very negative > consequences. In any case, I think the "leaders of the project" and the > "users of the project" > are still mostly aligned... since we all just want a working solution. > > > I'm curious if there are any topics that people feel there is a > disconnect between the "users of the project" and the "leaders of the > project"? > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Friedrich Dominicus > Sent: Wednesday, May 28, 2008 23:19 > To: Christopher Painter > Cc: Bob Arnson; wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] WIX 3.0 release date > > Christopher Painter writes: > > > Hmmm... > > > > > > > > > >http://www.productbeautiful.com/2008/05/02/why-product-management-is- > open-sources-fatal-flaw/ > > Nice read, I can sympathize with both sides. Howerver the users are > not willing to pay and so why should I care as developer. I do as I > like, the latter is the "right" answer. And haveing a product manager > should help? I doubt it very much, how comes that Office 2007 was auch > a plight, I bet MS surely have some very clever Product managers, how > comes that Vista reputation is that bad, hardly the result of clever > product management ... > > Regards > Friedrich > > > ----------------------------------------------------------------------- > -- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > ----------------------------------------------------------------------- > -- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > Christopher Painter, Author of Deployment Engineering Blog > Have a hot tip, know a secret or read a really good thread that > deserves attention? E-Mail Me > > > ----------------------------------------------------------------------- > -- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
