I'd also add that it's taken us quite a while to come up with mechanisms to handle the creation stable identifiers. It wasn't until late in WiX v3.0 that we really got it. We tried adding the auto-harvesting to Votive but there were too many bugs to get it stable (VS2010 shipped and we need a stable version of Votive to go with it). WiX v4.0 is where I hope we get to revisit a lot of these challenges and get to a place where handling files is less onerous.
However, Blair's points are true. If you want to see some of the limitations check out the MSI SDK about minor upgrades and patches and my blog entry about the Component Rules ( http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101). Those rules make live very difficult on the WiX toolset. On Wed, Jul 28, 2010 at 7:23 PM, Blair <os...@live.com> wrote: > Windows Installer has severe limitations when it comes to files being > added/removed arbitrarily from installations that will cause problems like > orphaned files, etc. This is due to some of the architectural decisions at > its core. > > To overcome those limitations, requirements such as yours can only be > achieved by using only "major upgrades, by enforcing a > "single-file-per-component" authoring model and by taking advantage of > WiX's > automatic component guid generation. The easiest way to do that is by > careful use of the arguments to the Heat.exe tool in your build. What you > are most likely seeking (based on my reading of your requirements) is: > harvest all files in a given directory - generate automatic component guids > - place all generated components into a single named (by you) > component-group. What you give up when doing things this way include: > generating MSPs, affiliating files to specific executables, assigning > different subsets of those files to different features, etc. > > Setup development is analogous to COM development or IIS development or > n-tier development or <name-your-favorite-platform-whatever> development in > that, even with the use of tools to automate aspects of the code > generation, > good coding will still require thought, experience, and training, including > supervising the output of the tools. 100% manual production is not required > to do "setup deployment", but tools that hide too much tend to cause > problems when the limits of their use cases are exceeded even while the > platform permits the desired use case (and some tools almost always produce > bad code except in the most trivial use cases). > > -----Original Message----- > From: IFM Lists [mailto:jkli...@ifm-services.com] > Sent: Wednesday, July 28, 2010 5:42 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Element to harvest all files in a directory > > > > Bear in mind that heat.exe isn't a substitute for actual setup > > development. It's a tool to make doing things (initially) easier > > especially for people migrating from things like InstallShield where > > there's a lot of stuff hidden from/done for you in the background. > > > I'm not trying to be critical of anything, just wanting to understand > something that appears counterintuitive. > > What constitutes "setup development"? What I read leads me to believe it > means "100% manual WiX code production and maintenance". (I could be wrong > here.) > > . . . > > My situation... > > My client's development team of dozen or so produces scores of DLLs, > perhaps > 80 or more. They expect the install build process scoop up the assembly > DLLs > produced by the build system, and the resulting MSI to drop the files in > the > correct directory. (The executables are fixed in WiX, the assemblies are > not.) > > As far as I can tell (I may be wrong here) - unless one uses heat or some > other method of code generation, this is impossible. WiX requires manual > human intervention whenever the list of assemblies changes (which is > frequent during active new development). > > Is this correct? If so, I'm struggling to understand how this is a Good > Thing. It appears that that is having a human do what a computer is better > suited to. > > If the list of DLLs is not exact, the automated testing system fails with a > variety of symptoms, some a little cryptic. > > Again, my apologies if I'm way off in left field here. > > > > > ---------------------------------------------------------------------------- > -- > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- virtually, Rob Mensching - http://RobMensching.com LLC ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
