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
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
[WiX-users] Using heat.exe as part of an automated build process
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? The reason I don't see this as a problem, is because we're not going to be using our installers for widespread distribution of our product, and not likely to upgrade an existing installation, but really just override it. Well, not actually override it, but I'd like to setup the installer to check whether or not there's a previous version of the product installed, and if there is, don't upgrade it, just uninstall it before installing the new version. So, from what I can tell, since that's the way we want to use our installer, that issue shouldn't really matter to us, and using heat.exe to help generate our component and feature source files as part of our build process should be fine, right? Any help or guidance would be greatly appreciated. Thanks. __ // YEX // // Bob Yexley // Contractor / Software Engineer [Extreme Consulting] // LexisNexis - Risk & Information Analytics Group (RIAG) // 937.865.6800 ext. 58655 // [EMAIL PROTECTED] - 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
Re: [WiX-users] Sample web application wxs file
Thanks for the information Richard, very helpful. It definitely gives me some things to think about, but also raised a few additional questions for me: Since I'm trying to create a web application installer, there aren't really any "executables". It's basically a collection of DLLs, .aspx files, .css files, etc. We're basically trying to provide our infrastructure group with a simplified way of deploying the application that we're creating in house to staging and production servers. So it's ultimately just going to put a bunch of files in a directory selected by the user, and then possibly even create a vdir in IIS, etc...and there will be a few files that will either be copied or not copied to the installation directory, based on a couple of simple user choices. The one other requirement I could see this having would be possibly detecting if the application has previously been installed on the machine, and if so, uninstall it first before installing the new version. So, based on that, would it make more sense to make a single component with all of the required files in it? Or an individual component for each file? __ // YEX // From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 11:22 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Sample web application wxs file Bob, As far as features / components are concerned, you probably want to look at the Microsoft installer documentation. Very basically though, "Features" are what the end user sees (e.g. "Word", "Excel", etc), and have a one-to-many mapping with the "Components" (word.exe, wordsupportfile.dll, etc.). If you wish to be able to create a patch file at some point in the future, then versioning rules require that you only have one executable per component. If you have multiple executables in the same component, you can only modify them as a complete set (remembering, of course, that component rules also dictate that you change the GUID if any files are added or removed). For non-executable files which are always installed as a "package", it may be appropriate to place them in the same component. That's really a design decision for your installation and will vary depending on your specific needs. Hope this helps, Regards, Richard ____________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yexley, Robert (LNG-CON) Sent: Tuesday, March 13, 2007 11:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Sample web application wxs file For some reason, I'm having some trouble following the WiX Tutorial provided online. I was wondering if anyone on the list might happen to have a sample of a WiX source file for installing an ASP.NET web application that they wouldn't mind sharing. I really feel like if I could look at a good sample file it would be more clear how I need to approach this. More than anything, I'm having trouble understanding the relationships between "components" and "features", and whether or not to install each of my binaries for the app individually in its own component, or just one component with all of the binaries I need in it, etc. It seems to me like the tutorial and the help documentation provided with the toolkit has a lot of "you can do it like this or like this or like this", but not any "this is the best/right way to do X". I just need to create an installer for a web app that will provide the user with some options. Any advice or samples would be greatly appreciated. __ // YEX // // Bob Yexley // Contractor / Software Engineer [Extreme Consulting] // LexisNexis - Risk & Information Analytics Group (RIAG) // 937.865.6800 ext. 58655 // [EMAIL PROTECTED] * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Peek Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll
[WiX-users] Sample web application wxs file
For some reason, I'm having some trouble following the WiX Tutorial provided online. I was wondering if anyone on the list might happen to have a sample of a WiX source file for installing an ASP.NET web application that they wouldn't mind sharing. I really feel like if I could look at a good sample file it would be more clear how I need to approach this. More than anything, I'm having trouble understanding the relationships between "components" and "features", and whether or not to install each of my binaries for the app individually in its own component, or just one component with all of the binaries I need in it, etc. It seems to me like the tutorial and the help documentation provided with the toolkit has a lot of "you can do it like this or like this or like this", but not any "this is the best/right way to do X". I just need to create an installer for a web app that will provide the user with some options. Any advice or samples would be greatly appreciated. __ // YEX // // Bob Yexley // Contractor / Software Engineer [Extreme Consulting] // LexisNexis - Risk & Information Analytics Group (RIAG) // 937.865.6800 ext. 58655 // [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Reusable properties?
Aahhh...the Preprocessor. That was what I was looking for. Thanks very much. __ // YEX // From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, March 12, 2007 4:35 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Reusable properties? In that case, look at the "Preprocessor" section in the WiX help, it describes the preprocessor variables (which was what I mentioned), and also how a similar technique can be used to access environment variables and "system" variables. Be aware though, that the $(var.) format I mentioned is the Wix 2.0 form. I believe the $ character may have been changed to something else in WiX 3.x so check the documentation appropriate to the version you are using. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yexley, Robert (LNG-CON) Sent: Monday, March 12, 2007 4:25 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Reusable properties? Richard - You're close...I don't want to be able to change anything at runtime. What I want is a simple way to define a string variable that will be used in several placed throughout the source file, and then reference in some way wherever I need to use it. I'd like to do that so that, if the value changes, I can just change it in one place, instead of having to try to remember all of the places in the file that its used and change them all, and possibly miss some. I liked what you mentioned with the "define" and "$(...)" syntax. If that syntax is accurate, that may just be exactly what I was looking for. __ // YEX // * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Peek Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Reusable properties?
Richard - You're close...I don't want to be able to change anything at runtime. What I want is a simple way to define a string variable that will be used in several placed throughout the source file, and then reference in some way wherever I need to use it. I'd like to do that so that, if the value changes, I can just change it in one place, instead of having to try to remember all of the places in the file that its used and change them all, and possibly miss some. I liked what you mentioned with the "define" and "$(...)" syntax. If that syntax is accurate, that may just be exactly what I was looking for. __ // YEX // From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, March 12, 2007 4:16 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Reusable properties? Robert, One thing I'm not sure about... Are you saying that you want to be able to change the property at runtime? If so, then I think what you are suggesting may actually break the component rules (you would have the same component, but multiple different filenames). I'm sure someone else here can tell me if I'm right about that one! If what you are actually looking for is the ability to use the same source file(s) to create different packages, then using $(var.whatever) is probably a better choice. You can either define the settings for that type of variable in an include file, or (possibly more appropriately) with the -D command line parameter. A quick sample for how something like that may be used would be as follows: http://schemas.microsoft.com/wix/2003/01/wi";> syntax for string parameters. You may need to put quote marks around the actual string... We pass ours in from the command line, using a parameter of the form: "-dManufacturer=Some Company" Hope this helps, Regards, Richard ____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yexley, Robert (LNG-CON) Sent: Monday, March 12, 2007 2:24 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Reusable properties? Hey everyone, Just getting my feet wet with WiX. I've been working my way through the documentation and the online tutorial the past few days, but so far I've not been able to figure out if WiX has the ability to create anything like a global, reusable property, and if so, how are they applied? For example, what I would like to do, is create a property whose value can be referenced from various other places within the installer source file (.wxs). So, something like the following... __ // YEX // // Bob Yexley // Contractor / Software Engineer [Extreme Consulting] // LexisNexis - Risk & Information Analytics Group (RIAG) // 937.865.6800 ext. 58655 // [EMAIL PROTECTED] * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Peek Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Reusable properties?
Hey everyone, Just getting my feet wet with WiX. I've been working my way through the documentation and the online tutorial the past few days, but so far I've not been able to figure out if WiX has the ability to create anything like a global, reusable property, and if so, how are they applied? For example, what I would like to do, is create a property whose value can be referenced from various other places within the installer source file (.wxs). So, something like the following... __ // YEX // // Bob Yexley // Contractor / Software Engineer [Extreme Consulting] // LexisNexis - Risk & Information Analytics Group (RIAG) // 937.865.6800 ext. 58655 // [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
