Re: [WiX-users] Using heat.exe as part of an automated build process
1. Yes. You are correct. Many tools in Visual Studio still encourage self registration. It has been a long hard fight (6 years or so) and I’m just starting to get people over there that understand what a horrible example they are setting. Some of them have asked, “Why is deployment so hard” and I point at the things they’ve done to encourage SelfReg (ATL built in and Installer classes). Believe it or not, SelfReg is a key component of the pain that was/is DLL Hell. 2. I agree that other processes should be put in place to move completely away from SelfReg and towards declarative statements. I would like to point out though that if Visual Studio did not automatically generate the registry code for you to write all of your keys to the registry that you’d probably be complaining about that amount of work. It takes far less effort to declare your COM registration in the WiX toolset (sometimes only one Class element) than code to write the dozen or so registry keys. 3. Actually your comment about SelfReg being self-contained is actually the root of the issue. The SelfReg code can’t see enough of the big picture to do the right things in all cases. For example, let’s say you and I share a DLL that is SelfReg’d. User installs your app and my app (order doesn’t matter). User decides she doesn’t like my app so she uninstalls my app. My app calls off to the SelfReg DLL to uninstall and suddenly your app doesn’t work anymore. That pretty much sucks for the user, eh? 4. I’m glad that your application is simple enough to be completely happy with the major upgrade functionality provided by the Windows Installer. That certainly the easiest way to do things. However even that simplicity does not solve the problem I pointed out in the scenario in #3 above. 5. “All I see is that the rules are changing and it's making things difficult.” The rules are not changing. These rules have been in place for almost a decade now and the rules really applied before that.. there just weren’t many people that were aware of them. Because many people weren’t aware of them bad things happened, DLL Hell being the most famous. 6. As I’ve noted in other threads, if you have a controlled environment and all of your stuff isolated from the rest of the world and you don’t do any sharing in your application then you can get away with pretty simple “code divination” rules. There are admittedly not good tools in the WiX toolset (yet) to do this simple code divination (because it doesn’t work at all in many cases). From: Scott Palmer [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 22, 2007 1:09 PM To: Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using heat.exe as part of an automated build process The problem here is that Microsoft tools are already in the habit of automatic code generation - and they all are designed to produce code for SELF REGISTRATION. The process of self registration is effectively encouraged by the development environment. Now if the development process has to change, fine. But then we are forced to throw out a great deal of the support in Visual Studio for building COM DLLs. What replaces what was taken away? Heat is the closest thing I've found so far and I fully understand that trying to extract the needed information from the final code like it does can be problematic. The point is it is a *huge* step backwards in productivity to go from SelfReg DLLs to needing every developer trained in WiX so they can manually tweak the installer every time they make a relevant change to their COM DLL, let alone that they must now remember that this is even necessary. Other processes could be put in place so the COM developer doesn't need to learn WiX but there will still be added steps and opportunity for things to go wrong. When you write: "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…" If you were talking install, uninstall and rollback, then that's an excellent argument for using SelfReg. Everything is nicely self-contained in the DLL and no installer-related tool needs to get too complex. Patching or anything else short of a complete uninstall followed by a re-install is something I'm not interested in. It's asking for trouble and simply not worth the effort. I've seen the writings discouraging CustomActions on the grounds that they are just to hard to get right if you need to account for all of those scenarios and I believe it. Anyway... I'm just looking for a build process, including creating the installer, that doesn't suck... Something as simple as a tool that wil
Re: [WiX-users] Using heat.exe as part of an automated build
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dyson, Peter Sent: 21 May 2007 10:58 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using heat.exe as part of an automated build Although Rob et al, don't recommend this approach we have been using Heat, and it's predecessor, as part of our automated build process for over a year with Wix3. The main things to be wary of are the spurious entries generated by Heat, for example VB6 entries which should not be there. However this is where XML shines, using both Xpath and tranforms, you can sanitise the output from heat directly into compilable code. We use Ant as our main build tool and xmltask a contributed package for ant works very well for the substitions and removal. I am unaware if Nant has a similar package. End Of Original Message- As of v0.85 NAnt provides and tasks that support for XPath expressions. I have been using them in a similar manner and they work very well. Colin - 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] Using heat.exe as part of an automated build process
0. Okay, so you're looking for "simplistic code divination". 1. I've never met a dev team that when presented with the option of doing more work accepted (unless it was some cool graphics work or something). Distributed development rarely happens because each developer says, "Ooh, I want to maintain the system how my files get installed" (although some do). It usually happens because someone that can see the big picture says, "Our processes and product would be better if we distributed the labor across all of our developers so that the people with the knowledge of how things work are responsible for making them work." I often compare this to the build process. Are the individual developers responsible for adding their new source files to the build system? In this day and age, the answer is almost always yes. I don't know why adding new files to the product is different. Note, I'm not being critical. I'm just trying to push conventional wisdom a little bit so that people at least entertain the idea that setup development should be distributed like all the rest of the development. The fact that the WiX toolset integrates into a build process makes this possible where (historically) other setup authoring tools tended to centralize the work. 2. Because you have such a controlled environment it may be possible to generate the portions of setup as you desire. Your strict rule of uninstalling before installing the next version makes this possible *as long as* you never have shared resources. If you share resources, you again have to worry about automagically generating the shared GUIDs. 3. Heat.exe is not the tool you're looking for (although it looks a lot like the one you need) because the WiX toolset is not tailored for any particular environment. Because the WiX toolset is intended to be used by anyone that needs to build Windows Installer packages we keep the tools following the widest array of best practices possible. In the distant past there was an "autogenerate" feature (like the one you describe) as part of the WiX toolset. A team used that tool to ship their product. When it came time to patch the product they were screwed because they had to install into far less controlled environments than the one you described and had to take into account some shared libraries. They were livid with me and the WiX toolset for not pointing them in the right direction. Since then, I've shied away from adding features that could silently hose a developer. 4. That said, I have a couple research projects going on to try to aid "code divination" tools. 5. So, bottom line, as long as you can control your environment then you can probably get away with a very simplistic "code divination" tool and since the WiX toolset operates in a great many uncontrolled environments we have not yet figured out how to write a "code divination" tool that works correctly in all cases. PS: Feel free to keep checking back here or my blog, http://robmensching.com/blog. If any of the code divination research bears fruit, I'm quite certain I'll be blogging about it. From: Yexley, Robert (LNG-CON) [mailto:[EMAIL PROTECTED] Sent: Monday, May 21, 2007 12:21 PM 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 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
Re: [WiX-users] Using heat.exe as part of an automated build process
Yes, as long as you have no other shared resources (registry keys? Common files folder?). Essentially, changing the path makes none of those files shared. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser Sent: Tuesday, May 22, 2007 12:23 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using heat.exe as part of an automated build process Thanks for the heads up. I'll bear that in mind. Presumably, changing the root folder for the files each time would solve this problem then. so sample-v1 sample-v2, etc would fix it as the root of the installed pieces. Anthony Wieser Wieser Software Ltd - Original Message - From: "Mike Dimmick" <[EMAIL PROTECTED]> To: "'Anthony Wieser'" <[EMAIL PROTECTED]>; Sent: Tuesday, May 22, 2007 12:17 AM Subject: RE: [WiX-users] Using heat.exe as part of an automated build process > 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 - 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
Re: [WiX-users] Using heat.exe as part of an automated build process
Well said, Dacian. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of fiordean dacian Sent: Wednesday, May 23, 2007 2:00 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using heat.exe as part of an automated build process Scott, Not everything that goes into the installer is COM and self registration. Imagine you have a folder containing hundreds of html and gif files for your product documentation. Now having a tool for automating the 'harvesting' process such that every time you add few gifs to that folder, the tool keeps the GUIDs for existing components and only creates new GUIDs for the gifs you added. It seems to me like the solution is a catalog component, which it's not that easy to implement (no component rules breaking). Dacian - 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] Using heat.exe as part of an automated build process
Also, people seem to forget that Wix is open/shared source. If something 'sucks' then 'fix it'. Or, feel free to lay down $5000 on something that sucks worse. -Matt _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Tuesday, May 22, 2007 8:34 PM To: Scott Palmer Cc: Rob Mensching; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using heat.exe as part of an automated build process Scott Palmer wrote: Anyway... I'm just looking for a build process, including creating the installer, that doesn't suck... Just FYI: Saying that something "sucks" is neither useful nor constructive. -- sig://boB http://joyofsetup.com/ - 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] Using heat.exe as part of an automated build process
Scott, Not everything that goes into the installer is COM and self registration. Imagine you have a folder containing hundreds of html and gif files for your product documentation. Now having a tool for automating the 'harvesting' process such that every time you add few gifs to that folder, the tool keeps the GUIDs for existing components and only creates new GUIDs for the gifs you added. It seems to me like the solution is a catalog component, which it's not that easy to implement (no component rules breaking). Dacian - Original Message From: Scott Palmer <[EMAIL PROTECTED]> To: Rob Mensching <[EMAIL PROTECTED]> Cc: "wix-users@lists.sourceforge.net" Sent: Tuesday, May 22, 2007 10:08:59 PM Subject: Re: [WiX-users] Using heat.exe as part of an automated build process The problem here is that Microsoft tools are already in the habit of automatic code generation - and they all are designed to produce code for SELF REGISTRATION. The process of self registration is effectively encouraged by the development environment. Now if the development process has to change, fine. But then we are forced to throw out a great deal of the support in Visual Studio for building COM DLLs. What replaces what was taken away? Heat is the closest thing I've found so far and I fully understand that trying to extract the needed information from the final code like it does can be problematic. The point is it is a *huge* step backwards in productivity to go from SelfReg DLLs to needing every developer trained in WiX so they can manually tweak the installer every time they make a relevant change to their COM DLL, let alone that they must now remember that this is even necessary. Other processes could be put in place so the COM developer doesn't need to learn WiX but there will still be added steps and opportunity for things to go wrong. When you write: "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…" If you were talking install, uninstall and rollback, then that's an excellent argument for using SelfReg. Everything is nicely self-contained in the DLL and no installer-related tool needs to get too complex. Patching or anything else short of a complete uninstall followed by a re-install is something I'm not interested in. It's asking for trouble and simply not worth the effort. I've seen the writings discouraging CustomActions on the grounds that they are just to hard to get right if you need to account for all of those scenarios and I believe it. Anyway... I'm just looking for a build process, including creating the installer, that doesn't suck... Something as simple as a tool that will take the .rgs files from my visual studio projects and convert them to the appropriate WiX code might work. I don't know yet. All I see is that the rules are changing and it's making things difficult. "Code Devination" is something that was already there when I used SelfReg... and it was working fine... but now we can't use it. The tools we have to use don't do the job they used to, because they only support SelfReg. We have the source for the ATL register and unregister code.. I wonder if a tool like Heat couldn't just find all the .rgs resources in a DLL and derive the WiX code from them? Perhaps I will write something like that to put in my automated build.. that way the ATL COM wizard could almost be used without any more manual tweaking. It turns out the wizards are buggy and screw up the .rgs files too... putting different GUIDs in the IDL and .rgs files when the GUID should have been matched, but that broke self registration as well, so the developers know to fix that already. Scott On 5/21/07, Rob Mensching <[EMAIL PROTECTED]> wrote: 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,
Re: [WiX-users] Using heat.exe as part of an automated build process
Scott Palmer wrote: Anyway... I'm just looking for a build process, including creating the installer, that doesn't suck... Just FYI: Saying that something "sucks" is neither useful nor constructive. -- sig://boB http://joyofsetup.com/ - 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] Using heat.exe as part of an automated build process
The problem here is that Microsoft tools are already in the habit of automatic code generation - and they all are designed to produce code for SELF REGISTRATION. The process of self registration is effectively encouraged by the development environment. Now if the development process has to change, fine. But then we are forced to throw out a great deal of the support in Visual Studio for building COM DLLs. What replaces what was taken away? Heat is the closest thing I've found so far and I fully understand that trying to extract the needed information from the final code like it does can be problematic. The point is it is a *huge* step backwards in productivity to go from SelfReg DLLs to needing every developer trained in WiX so they can manually tweak the installer every time they make a relevant change to their COM DLL, let alone that they must now remember that this is even necessary. Other processes could be put in place so the COM developer doesn't need to learn WiX but there will still be added steps and opportunity for things to go wrong. When you write: "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…" If you were talking install, uninstall and rollback, then that's an excellent argument for using SelfReg. Everything is nicely self-contained in the DLL and no installer-related tool needs to get too complex. Patching or anything else short of a complete uninstall followed by a re-install is something I'm not interested in. It's asking for trouble and simply not worth the effort. I've seen the writings discouraging CustomActions on the grounds that they are just to hard to get right if you need to account for all of those scenarios and I believe it. Anyway... I'm just looking for a build process, including creating the installer, that doesn't suck... Something as simple as a tool that will take the .rgs files from my visual studio projects and convert them to the appropriate WiX code might work. I don't know yet. All I see is that the rules are changing and it's making things difficult. "Code Devination" is something that was already there when I used SelfReg... and it was working fine... but now we can't use it. The tools we have to use don't do the job they used to, because they only support SelfReg. We have the source for the ATL register and unregister code.. I wonder if a tool like Heat couldn't just find all the .rgs resources in a DLL and derive the WiX code from them? Perhaps I will write something like that to put in my automated build.. that way the ATL COM wizard could almost be used without any more manual tweaking. It turns out the wizards are buggy and screw up the .rgs files too... putting different GUIDs in the IDL and .rgs files when the GUID should have been matched, but that broke self registration as well, so the developers know to fix that already. Scott On 5/21/07, Rob Mensching <[EMAIL PROTECTED]> wrote: 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
Re: [WiX-users] Using heat.exe as part of an automated build
Hi, I have a similar situation (where the list of files changes from release to release), and I use a perl script to generate wix include files for the components and features. Let me explain. We keep list files, split into what become components, containing simply the relative pathname of all files within that component (relative to the root install directory). There's another file that lists the features and the components they include. These are both simply text files. The perl script reads all of these files and keeps track of the features, components, files, and directories using %arrays, then spits out a features.wxi and components.wxi file that is included in a base .wxs file to fill out the feature and component sections. The perl script also keeps a list of known components and the GUIDs associated with them, so that the component GUIDs only change when we want. If you'd like a sanitized version of the perl script (with example files), let me know off-list and I'll send it to you. Lewis >>-Original Message- >>Date: Mon, 21 May 2007 15:21:29 -0400 >>From: "Yexley, Robert \(LNG-CON\)" <[EMAIL PROTECTED]> >>Subject: Re: [WiX-users] Using heat.exe as part of an automated build >> process >>To: "Rob Mensching" <[EMAIL PROTECTED]>, "Scott Palmer" >> <[EMAIL PROTECTED]> >>Cc: wix-users@lists.sourceforge.net >>Message-ID: >><[EMAIL PROTECTED] t> >> >>Content-Type: text/plain; charset="us-ascii" >> >>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 >&g
Re: [WiX-users] Using heat.exe as part of an automated build process
One of the teams in our company has it's own script for creating the WiX fragment for a large set of files. It doesn't use heat or tallow, it creates everything itself. The start of the file is always the same, as is the end. It's only the XML under the top directory that ever changes. The script traverses a directory and create either a new directory element, or a new component with a file element, depending on what it finds. One of the parameters to the script is a file containing a list of file paths and GUIDs. When a file is found whilst traversing the directory, the script checks the list of known files for an existing GUID. If it exists it uses that GUID, otherwise it creates a new GUID and creates a new entry for the file. Obviously the file->GUID list is quite important, so this is kept in source control. As a backup we have RemoveExistingProducts scheduled early in the install sequence. I have also rammed home many times that if they get the file->GUID stuff wrong they're going to screw the install. No, I can't fix it, you'll have to ask the user to manually uninstall the old version first. Rob Dyson, Peter wrote: > > After receiving emails from people on this subject asking about our > process, I will reply to all publicly here. > > Unfortunatly my employer 'owns' the code, getting OS in the door is hard > enough, getting it out is not an option I am afraid. > > However for those interested the general methodology used is as follows. > > Each file has an XML file which describes it, how it gets installed and > any required params which cannot be auto harvested. It also lists what > products this file gets used by ( we have a lot of code sharing among > products). > > This file is then read and generates wix source files for each product > using transforms and xpath. This pass also tell the products what > components they have. The component files are then built, tranforms are > done to generate the features using the information from pass 1 and then > the final generation of msms and then msis. > > This process currently manages our msi generation for 20+ installation > products from 240ish components built from source and a few hundred > ancillary files. > > It removes most of the tedium and mistakes made, but is still fully > extensible by careful use of include files. > > It's not quite the nirvana of fully automated code generation but it > does remove the tedium and potential mistakes from changing one > component which is used in all products. > > > > - > 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/ - 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] Using heat.exe as part of an automated build process
After receiving emails from people on this subject asking about our process, I will reply to all publicly here. Unfortunatly my employer 'owns' the code, getting OS in the door is hard enough, getting it out is not an option I am afraid. However for those interested the general methodology used is as follows. Each file has an XML file which describes it, how it gets installed and any required params which cannot be auto harvested. It also lists what products this file gets used by ( we have a lot of code sharing among products). This file is then read and generates wix source files for each product using transforms and xpath. This pass also tell the products what components they have. The component files are then built, tranforms are done to generate the features using the information from pass 1 and then the final generation of msms and then msis. This process currently manages our msi generation for 20+ installation products from 240ish components built from source and a few hundred ancillary files. It removes most of the tedium and mistakes made, but is still fully extensible by careful use of include files. It's not quite the nirvana of fully automated code generation but it does remove the tedium and potential mistakes from changing one component which is used in all products. - 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] Using heat.exe as part of an automated build process
Thanks for the heads up. I'll bear that in mind. Presumably, changing the root folder for the files each time would solve this problem then. so sample-v1 sample-v2, etc would fix it as the root of the installed pieces. Anthony Wieser Wieser Software Ltd - Original Message - From: "Mike Dimmick" <[EMAIL PROTECTED]> To: "'Anthony Wieser'" <[EMAIL PROTECTED]>; Sent: Tuesday, May 22, 2007 12:17 AM Subject: RE: [WiX-users] Using heat.exe as part of an automated build process > 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 - 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] Using heat.exe as part of an automated build
Apportioning blame where required: the spurious entries are generated by the VB6 DllRegisterServer code, not by Heat. Heat does not know what the DllRegisterServer code does, it simply captures the changes the DLL made to the registry. The sterile environment supplied by Heat for the DLL to inject its changes into sometimes does cause the DLL to do too much (or to fail to run outright). If you get weird output, crashes, unexplained message boxes, debug the DllRegisterServer function. The sterile environment does not include the registry entries needed for side-by-side DLLs to work (last I checked), so anything dynamically linked to the version 7.0 or later C runtime won't load and run. If you can avoid having to capture the output, you should do so. It *is* possible (though not fun) to work out what VB6 DLLs will do by studying the embedded type library; use the OLE/COM Object Viewer (oleview.exe) from Visual Studio (ships with all versions - VS6 adds a shortcut to the Start menu, VS7 and later in Common7\Tools\Bin - you may need to install some optional components). To reduce the amount of change required in your WiX script, use one of the COM compatibility options in VB - Project Compatibility or Binary Compatibility. That will keep GUIDs stable until you make a change to your interface. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dyson, Peter Sent: 21 May 2007 10:58 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using heat.exe as part of an automated build Although Rob et al, don't recommend this approach we have been using Heat, and it's predecessor, as part of our automated build process for over a year with Wix3. The main things to be wary of are the spurious entries generated by Heat, for example VB6 entries which should not be there. However this is where XML shines, using both Xpath and tranforms, you can sanitise the output from heat directly into compilable code. We use Ant as our main build tool and xmltask a contributed package for ant works very well for the substitions and removal. I am unaware if Nant has a similar package. - 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
Re: [WiX-users] Using heat.exe as part of an automated build process
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: http://schemas.microsoft.com/wix/2006/wi";> 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 t
Re: [WiX-users] Using heat.exe as part of an automated build process
We do something similar to this with a tool based on mallow, this is in turn based on tallow but it has one big advantage, it maintains the guids for files already added to the output wxs files. A quick Google should locate the mallow source if you are interested. Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED] -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: http://schemas.microsoft.com/wix/2006/wi";> 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 - 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] 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: http://schemas.microsoft.com/wix/2006/wi";> 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
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
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]<mailto:[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 recommende
Re: [WiX-users] Using heat.exe as part of an automated build process
Yexley, Robert (LNG-CON) wrote: Is WiX designed to be used in an automated build process? The WiX tools, of course. The subject of this thread is your setup *authoring*. The code based that it needs to be generated from is a moving target...changes on a ~weekly basis. Because the WiX tools can be part of your product's build process, everybody making changes can keep the setup current. -- sig://boB http://joyofsetup.com/ - 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] Using heat.exe as part of an automated build process
Scott stated "[Heat] obviously should be [usable in an automated build process]" To which I would reply, "Should it really?" From my point of view, using Heat (or its WiX V2 predecessor Tallow) is akin to using a radio controlled rifle from several hundred miles away without the benefit of a video feed as well. Sure, it can be made to work, but the consequences if something goes wrong could be fatal (to your end user's machine, or your ability to appropriately support your product). I know there are people out there who are using some form of automated WiX authoring. As long as you truly understand what you are doing (and are prepared for the consequences if you have messed up) that's fine. I, for one, strongly support Rob and the rest of the WiX developers in their decision to only supply the rope. Choosing to make a noose out of it should be entirely your own choice! Oh, and in response to Robert Yexley's question, I have used (and will continue to use) WiX as part of an automated build process, even though I have to go through the pain of re-authoring some of the installation source files when COM GUID's change. As to how appropriate a tool it is for your specific needs - that depends on what you want to use it for, and the "stability" of the files that make up your product. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Palmer Sent: Monday, May 21, 2007 9:49 AM To: Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using heat.exe as part of an automated build process But it obviously should be. I hope this can be fixed, since we are stuck with having to deal with all the problems of COM and for some silly reason (I haven't seen a good argument against it yet) SelfReg is not supported and officially broken for dynamically linked DLLs on Vista. Microsoft also has the option of supporting some other method of registering COM components in the tools that are used to create them (Visual Studio). Or they could just deprecate COM.. but I doubt they will admit what a blunder it is, so I'll settle for a build process that is usable in the real world. Excuse the rant, but having to put up with all these things (WiX, MSI, COM, Vista) that work so hard against me is frustrating. Scott On 5/18/07, Rob Mensching <[EMAIL PROTECTED]> wrote: Heat isn't designed to be used in an automated build process. * 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. - 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] Using heat.exe as part of an automated build process
But it obviously should be. I hope this can be fixed, since we are stuck with having to deal with all the problems of COM and for some silly reason (I haven't seen a good argument against it yet) SelfReg is not supported and officially broken for dynamically linked DLLs on Vista. Microsoft also has the option of supporting some other method of registering COM components in the tools that are used to create them (Visual Studio). Or they could just deprecate COM.. but I doubt they will admit what a blunder it is, so I'll settle for a build process that is usable in the real world. Excuse the rant, but having to put up with all these things (WiX, MSI, COM, Vista) that work so hard against me is frustrating. Scott On 5/18/07, Rob Mensching <[EMAIL PROTECTED]> wrote: Heat isn't designed to be used in an automated build process. - 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] 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
Re: [WiX-users] Using heat.exe as part of an automated build
Although Rob et al, don't recommend this approach we have been using Heat, and it's predecessor, as part of our automated build process for over a year with Wix3. The main things to be wary of are the spurious entries generated by Heat, for example VB6 entries which should not be there. However this is where XML shines, using both Xpath and tranforms, you can sanitise the output from heat directly into compilable code. We use Ant as our main build tool and xmltask a contributed package for ant works very well for the substitions and removal. I am unaware if Nant has a similar package. - 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] 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]<mailto:[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
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
