Yes, you're breaking rule 1 of the component rules: a file installed to the same location must always belong to the same component and have the same GUID. Change the GUID, it's a new component; change the component, you must change the final path name of the file. If you don't, you mess up Windows Installer's reference counting and it may either remove files prematurely or not remove them when it should.
At the very least you restrict where you can schedule the RemoveExistingProducts action when performing an upgrade (if you do it after InstallFiles in the new product, Windows Installer will happily remove all the old components - and the files it's just installed). -- Mike Dimmick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser Sent: 21 May 2007 20:46 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using heat.exe as part of an automated build process I've just built a similar tool today, to help me copy a set of sample files to the installation, because I never want to do that by hand, and heat's output was just too messy for my liking. What I've done is taken all of the files in a tree, and created a component for each file, with a unique GUID, automatically generated. In addition, the files are relative to a folder elsewhere. The file looks more or less like this: <?xml version="1.0" encoding="utf-8"?> <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi";> <?define SampDir="C:\projects\business\artgallery\sample_src\"?> <?define SampDiskId="1"?> <?define SampParentDir=INSTALLLOCATION?> <Fragment> <DirectoryRef Id="$(var.SampParentDir)"> <Directory Id="D0" Name="sample"> <!-- more directories nest here, containing file/component groups as below--> <Component Id="C00" Guid="81f9ff04-e26a-45e6-ba24-6cd1466b4f3f"> <File Id="F00" Name="404.htm" KeyPath="yes" Source="$(var.SampDir)\sample\templates\404.htm" DiskId="$(var.SampDiskId)" /> </Component> <!-- lots more components go here for each file in the folder--> </Directory> </DirectoryRef> <ComponentGroup Id="CGSamp"> <ComponentRef Id="C0000" /> </ComponentGroup> </Fragment> </Wix> As you can see, I've marked each of the files as KeyPath="yes" and also automatically generated ID's for each file, component and folder. Then I've wrapped the whole lot up inside a fragment, which also contains a component group, so I can link the whole file into my build, and then just add a simple Feature that uses a ComponentGroupRef. My intention was to build this as the initial listing of all of the files in my folder, and then manually add any additions, but your post made me question whether that was necessary. Is there a downside of just redoing all of the GUID's each time I do an update, apart from installation speed? Anthony Wieser Wieser Software ltd ----- Original Message ----- From: Yexley, Robert (LNG-CON) To: Rob Mensching ; Scott Palmer Cc: wix-users@lists.sourceforge.net Sent: Monday, May 21, 2007 8:21 PM Subject: Re: [WiX-users] Using heat.exe as part of an automated build process Thanks Rob. But the "code divination" that you speak of is not really what I'm looking for. I'm not looking for some voodoo that will get me out of doing my job, I'm just looking for a way to do it more efficiently and effectively. The *actual* situation that I have is that the files that make up the web application that I'm trying to create an installer for change, at least slightly, from week-to-week. ASPX pages get added, js files get removed, etc. The file system is a moving target. I've discussed the maintenance of .wxs files with the development team and the general consensus seems to be that having to update/change a .wxs file to add or remove a "component" whenever a file is added or removed from the codebase is not really feasible. The hope, then, was that there might be some way, some tool that I could use, to automatically generate a .wxs source file with all of the "components" needed by simply pointing it at a given directory. I can setup my automated build process to take the raw code directory and copy only the files needed to a "staging" directory (remove all files with the following extensions: .cs, .csproj, etc)...that directory then becomes a mirror image of what I want the target machine to look like after having run the installer. I have no problem with creating a main .wxs source file with all of the custom UI logic and stuff like that in it, but having to manually maintain files for each and every single file that makes up an application is tedious at best (more colorful ways of describing that process come to mind as well). The other major consideration here is the fact that I don't really have a requirement to deploy to a large user base, nor is there a requirement for component "upgrades" either. We're developing an installer to simplify the process of internal deployment. Within the company that I work, there is a completely separate organization that maintains our server environments, and the deployment of applications to those servers. The idea of simplifying that process for them by creating a simple installer is very appealing to everyone. So, for our purposes, an "upgrade" would really just be a matter of checking to see if the application is already installed and if it is, uninstall it before continuing with the current installation. There are a few custom actions that I would want to perform as part of the process, but again, I can write that into the installer source and handle that myself. I simply want something that is capable of looking at a directory and generating a source file with a component for each of the files and directory structures in the given directory. I hope that clears some things up. I also hope that makes what I'm wanting/hoping/trying to do fairly easy. I just need some guidance as to how to do that, whether it involves the use of heat.exe or something else. If nothing else exists, fine...I'll write my own tool to do it. I just wanted to at least ask the question because my scenario seemed to me to be a common enough one that someone was bound to have faced this challenge before me, and hoped that someone had already figured out a solution for it. Thanks. ______________________________________ // YEX // From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Monday, May 21, 2007 1:16 PM To: Yexley, Robert (LNG-CON); Scott Palmer Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Using heat.exe as part of an automated build process WiX is intended to be used in an automated build system. It fits in extremely well with every automated build process that I've been introduced to. What you appear to be looking for is an "automated code generation" process. Code generation is a completely different problem than building. Code generation is about divining what a developer is thinking (or at least should be thinking) and writing the code for him or her. The WiX toolset does not include any good "automated code generation" tools. There are tools (namely heat.exe, and dark.exe if you start with an MSI) to help developers capture large amounts of data and translate that into .wxs code. But those tools are designed to be guided by a developer, not run blindly in an automated build process. Of course, the results of the tools can be checked into source control and then operated on in an automated build system. Note that writing a "automated code generation process" requires significant amount of domain specific knowledge. I had a conversation just this last week with a developer from a company where significant amounts of IDL and VB code is generated by the build process. In that company "analysts" can only write code into some well known named functions and the rest of the structure was provided for them. Because the system was so structured (and strict) he was able to automatically generate the .wxs code in much the same way the IDL and VB code was generated (for example he was already handling breaking interface changes and there is no resource sharing). Another very large company has strict development guidelines and provides their developers with a complete template of .wxs code that adheres to those guidelines. If the developers need to stray from the company development guidelines then they can tweak/extend the template .wxs code as necessary. However, the generated template code no longer applies. That company likes the WiX toolset because it provides both a solid starting point and the flexibility when needed. I have yet to see an automated code generation tool that can just point at any application of any complexity and go, "Oh, that's a FizzlyBear and it needs to be installed, uninstalled, upgraded, patched, and handle rollback like this. Oh, and it needs to be per-user/per-machine and store state in this location and. and. and." Today the WiX toolset provides a solid foundation for your automated build system. We're still dabbling in tools to help make it easier to work with the .wxs code but "Code Divination" is still a skill I haven't mastered at Hogwarts yet. From: Yexley, Robert (LNG-CON) [mailto:[EMAIL PROTECTED] Sent: Monday, May 21, 2007 6:19 AM To: Rob Mensching; Scott Palmer Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Using heat.exe as part of an automated build process Is WiX designed to be used in an automated build process? If so, is there any guidance anywhere on how to do so? I need an installer, and I need it to be generated as part of an automated build process. The code based that it needs to be generated from is a moving target...changes on a ~weekly basis. If WiX isn't what I'm looking for, that's fine, I can move on. I just need to know that. ______________________________________ // YEX // From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Friday, May 18, 2007 10:23 PM To: Scott Palmer; Yexley, Robert (LNG-CON) Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Using heat.exe as part of an automated build process Heat isn't designed to be used in an automated build process. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Palmer Sent: Friday, May 18, 2007 7:10 PM To: Yexley, Robert (LNG-CON) Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using heat.exe as part of an automated build process Not exactly. If you use Heat on a COM DLL, Heat inserts "PUT-GUID-HERE" for the GUID so you can do a search/replace as part of the automated build to keep the GUID correct and always the same for that component. Other issues are with the directory structure that Heat uses and the fact that it's output doesn't compile anyway. It seems Heat isn't ready for real use yet.. to be expected I guess. Scott On 5/18/07, Yexley, Robert (LNG-CON) <[EMAIL PROTECTED]> wrote: I'm still learning the ins and outs of WiX. I'm working on trying to integrate the generation of an MSI into our automated build process, and was wondering about the possibility of using heat.ext to harvest the files needed for the features and components for the MSI. I've read a few archived messages from the list that suggested that doing something like this could potentially be problematic, and isn't recommended, but if I understand correctly the reasons why, I'm not sure it would really cause us a problem for what we're wanting to accomplish. So, I'd like to try to confirm whether or not I understand what the issue is with using heat, describe why I don't think its an issue for us, and it'd be great if someone could confirm whether my thinking is correct or not. So, if I understand correctly, the issue with using heat.exe to generate source files for me as part of an automated build process is that for each build, the GUID for each component would be different on each build, which causes problems for the installer if you want it to be able to "upgrade" a product installation. Is that right? ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
