Re: [WiX-users] Merge Module Help
Blair, you're right, it isn't "analysis paralysis" but the Component Rules are *fundamentally* broken. The fact that it is possible to mathematically demonstrate how simple developer behavior can create a paradox in the system (http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx) is just wrong. Of course, it's going to be hard for them to "fix" since their foundation is built on these Component Rules. So, building a system [to auto-generate GUIDs] that works perfectly within the Component Rules is one of the very hard problems that is still with us (and has been since the Windows Installer was written ). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Blair Murri Sent: Thursday, July 31, 2008 21:24 To: [EMAIL PROTECTED] Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Merge Module Help I just had to respond to this. Sorry for picking it back up. XCOPY simplicity in an MSI package is very easy to do. You use empty component guids and change your ProductCode on every single build. You don't ever patch, and removal doesn't do anything (files are left behind). For a complete solution, suppress the component and product registration actions and you won't show up in ARP or have any other side-effects of MSI installation. You can even use SelfReg for your DLLs! BINGO: XCOPY in an MSI package. And, you get a more user-friendly Files-In-Use as a bonus (xcopy never did that!). Now, you also don't get COM/Registry registration, Firewall registration, Shell integration, Web-Site registration, Application repair, or any of a thousand other things that xcopy never did either. And, if you share any binaries you are back in DLL hell. There's a reason we don't do xcopy deployments anymore for the past ten years, and that is because the platform doesn't support xcopy deployed products for much more than trivial platform integrations. Most developers want a lot of things made more simple, but we have learned to compromise and trade some complexity for some shared increased functionality. Most installations are not 7000 files, and most don't change their file lists daily, and for that majority, code-the-components-once-and-keep-them-in-source-code is absolutely the right way to go (it even gives you the benefit of a build exception/error if a file is missing). For those very few caught in the masses of constantly changing file lists, they need to ask what they really need from the platforms they deploy against and what level of effort is warranted. Last time I asked my developers, they didn't want to not think, they just don't know what to ask; and what they want is the simplest structure within which they can get the best deployment strategy they need for the parts of the platforms they write against. Since MSI is a platform for enabling just about any deployment strategy possible on a modern Microsoft Win dows platform, it has to enable support for all kinds of crap that xcopy could never do. While the architecture of Windows Installer doesn't lend itself to ease-of-correct-use, it does enable almost any scale deployment solution to be created in a correct fashion. It isn't that the analysis has paralyzed us, it is that no one has volunteered a better architecture that works as well with the admittedly too-complicated platform (Windows and all its "environments") we have. The best way out of this is to simplify those environments (COM/IIS/etc.) from a deployment perspective and we can then craft a replacement deployment platform that is simpler. But of course platforms haven't been required to think through most deployment scenarios when engineering their platforms (COM+, anyone?). In fact, platforms on Windows don't even have to come from Microsoft. Until then, you can simplify for some with a different platform, but at the cost of dropping support for others. There are enough of those others that an industry dedicated to deployment technologies is alive and well. Besides, if programming were really easy to do right, we wouldn't ask for college education for those entering the field, and we wouldn't be paid enough to support our families, since solutions involving not thinking can be employed by anyone, correct? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Wednesday, July 23, 2008 10:32 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Merge Module Help What feedback? All I saw was a childish quip/troll post. Personally I'm sick of the component rules and it's associated gotchas. These are artificial problem caused by an overly complicated design. Developers want xcopy simplicity. The features are nice from a platform presevatin
Re: [WiX-users] Merge Module Help
I just had to respond to this. Sorry for picking it back up. XCOPY simplicity in an MSI package is very easy to do. You use empty component guids and change your ProductCode on every single build. You don't ever patch, and removal doesn't do anything (files are left behind). For a complete solution, suppress the component and product registration actions and you won't show up in ARP or have any other side-effects of MSI installation. You can even use SelfReg for your DLLs! BINGO: XCOPY in an MSI package. And, you get a more user-friendly Files-In-Use as a bonus (xcopy never did that!). Now, you also don't get COM/Registry registration, Firewall registration, Shell integration, Web-Site registration, Application repair, or any of a thousand other things that xcopy never did either. And, if you share any binaries you are back in DLL hell. There's a reason we don't do xcopy deployments anymore for the past ten years, and that is because the platform doesn't support xcopy deployed products for much more than trivial platform integrations. Most developers want a lot of things made more simple, but we have learned to compromise and trade some complexity for some shared increased functionality. Most installations are not 7000 files, and most don't change their file lists daily, and for that majority, code-the-components-once-and-keep-them-in-source-code is absolutely the right way to go (it even gives you the benefit of a build exception/error if a file is missing). For those very few caught in the masses of constantly changing file lists, they need to ask what they really need from the platforms they deploy against and what level of effort is warranted. Last time I asked my developers, they didn't want to not think, they just don't know what to ask; and what they want is the simplest structure within which they can get the best deployment strategy they need for the parts of the platforms they write against. Since MSI is a platform for enabling just about any deployment strategy possible on a modern Microsoft Win dows platform, it has to enable support for all kinds of crap that xcopy could never do. While the architecture of Windows Installer doesn't lend itself to ease-of-correct-use, it does enable almost any scale deployment solution to be created in a correct fashion. It isn't that the analysis has paralyzed us, it is that no one has volunteered a better architecture that works as well with the admittedly too-complicated platform (Windows and all its "environments") we have. The best way out of this is to simplify those environments (COM/IIS/etc.) from a deployment perspective and we can then craft a replacement deployment platform that is simpler. But of course platforms haven't been required to think through most deployment scenarios when engineering their platforms (COM+, anyone?). In fact, platforms on Windows don't even have to come from Microsoft. Until then, you can simplify for some with a different platform, but at the cost of dropping support for others. There are enough of those others that an industry dedicated to deployment technologies is alive and well. Besides, if programming were really easy to do right, we wouldn't ask for college education for those entering the field, and we wouldn't be paid enough to support our families, since solutions involving not thinking can be employed by anyone, correct? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Wednesday, July 23, 2008 10:32 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Merge Module Help What feedback? All I saw was a childish quip/troll post. Personally I'm sick of the component rules and it's associated gotchas. These are artificial problem caused by an overly complicated design. Developers want xcopy simplicity. The features are nice from a platform presevatin perspective but nearly 10 years have gone by since it was invented and we are still sitting around a table scratching our head how to solve the authoring headaches that it created. Talk about analysis paralysis. --- On Wed, 7/23/08, Rob Mensching <[EMAIL PROTECTED]> wrote: > From: Rob Mensching <[EMAIL PROTECTED]> > Subject: Re: [WiX-users] Merge Module Help > To: "General discussion for Windows Installer XML toolset." > > Date: Wednesday, July 23, 2008, 11:39 AM > Hey, wait a minute here. > > First, Automating Component/@Guids requires a bullet-proof > solution. The side-effects of violating the Component Rules > are nasty on two fronts a) once violated there are no real > good ways out (something will get messed up on the > user's machine) and b) you don't usually realize > you've violated the rules until it is too late (like > wh
Re: [WiX-users] Merge Module Help
What feedback? All I saw was a childish quip/troll post. Personally I'm sick of the component rules and it's associated gotchas. These are artificial problem caused by an overly complicated design. Developers want xcopy simplicity. The features are nice from a platform presevatin perspective but nearly 10 years have gone by since it was invented and we are still sitting around a table scratching our head how to solve the authoring headaches that it created. Talk about analysis paralysis. --- On Wed, 7/23/08, Rob Mensching <[EMAIL PROTECTED]> wrote: > From: Rob Mensching <[EMAIL PROTECTED]> > Subject: Re: [WiX-users] Merge Module Help > To: "General discussion for Windows Installer XML toolset." > > Date: Wednesday, July 23, 2008, 11:39 AM > Hey, wait a minute here. > > First, Automating Component/@Guids requires a bullet-proof > solution. The side-effects of violating the Component Rules > are nasty on two fronts a) once violated there are no real > good ways out (something will get messed up on the > user's machine) and b) you don't usually realize > you've violated the rules until it is too late (like > when you need a critical security fix). If you're > going to suggest a solution to this problem then expect it > to be "pedantically picked through". From there > you should adapt your solution based on feedback or specify > how the feedback is actually addressed by the solution or > note that your solution doesn't work and try something > different. Partial success isn't an option here > because the "partial failures" are so horrible. > > > Second, please take the personal comments elsewhere. This > is where we talk about the WiX toolset. > > > Thank you. > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Bob Arnson > Sent: Wednesday, July 23, 2008 08:54 > To: [EMAIL PROTECTED] > Cc: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > Christopher Painter wrote: > > Once again you pedantically pick through my comment > without actually offering anything constructive yourself. > > Wow, I'm really put in my place, aren't I? > > -- > sig://boB > http://joyofsetup.com/ > > > - > This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge > Build the coolest Linux based applications with Moblin SDK > & win great prizes > Grand prize is a trip for two to an Open Source event > anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > - > This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge > Build the coolest Linux based applications with Moblin SDK > & win great prizes > Grand prize is a trip for two to an Open Source event > anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
> 1. How do you manage updates to the "database" in source > control? Do people update the file before building or does > the build machine checkout/checkin automatically? If the > latter, what source control systems does it support... (you > can see where I'm going )? We use cvsnt as our source control system, and my build/release script does an update before building. The custom build task currently just generates a build warning if it's had to update the database, and that's my cue to commit the file back into CVS. There's probably nothing stopping me from making the commit automatic, but it means I can keep an eye on what is going on. > 2. How is this better than using auto-generated-stable Guids? It's probably not. I'm not sure heat had that functionality when I implemented what I have implemented, and I wasn't aware that auto-generated GUIDs were possible. It's worth noting that I only use this method for parts of the installer where there are collections of simple files that need installing, with no other resources. These files are changed by other people on the team, sometimes people who are not developers, and so it makes my life easy to harvest them. I've got it working well enough for our environment and the constraints we operate under; it may not work so well for others. For example, I also have build tasks that generate wxs fragments for VB6 COM controls, stripping out some of the needless stuff that VB puts in the registry, which is duplicated across all controls, again using a similar scheme to store GUID state. Regards, John - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
IMHO, when you automate part of the process, you take responsibility for the automation always being correct. To me that means the automation needs to be able to handle all of the scenarios. Patching is one of the scenarios. Run the deduction to the end and you see what a difficult problem the Component/@Guid creates. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Wednesday, July 23, 2008 08:47 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Merge Module Help Christopher Karper wrote: > FWIW, I personally would rather manage the process by exception, instead of > *always*. > Yes, some help is usually better than none. It's all about managing expectations. If it's possible to automatically generate the original setups, not being able to generate patches might be surprising. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
1. How do you manage updates to the "database" in source control? Do people update the file before building or does the build machine checkout/checkin automatically? If the latter, what source control systems does it support... (you can see where I'm going )? 2. How is this better than using auto-generated-stable Guids? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hall Sent: Wednesday, July 23, 2008 01:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Merge Module Help > The case that gets really tricky is to have one build where a Resource > disappears (usually accidentally) then the next build where the > Resource comes back. It needs to get the same Component and GUID. I have written a tool that auto-generates .wxs files for some parts of my project - we ship a lot of example scripts. It only handles files and generates one component per file. The tool maintains a database (well, an XML file) that lists all the GUIDs ever allocated, and adds entries as it needs. That file is kept in source control. This seems to work well for me - have I missed something important? Regards, John - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
ClickThrough also ensures that there is no overlap between the versions. That's important to remember as well. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Wednesday, July 23, 2008 09:17 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Merge Module Help John Hall wrote: > Ah, we don't do patches, which is why it works for me :) > That's also an option. That's what ClickThrough does, using "early" major upgrades every time. In that case, you don't even need stable IDs. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
Hey, wait a minute here. First, Automating Component/@Guids requires a bullet-proof solution. The side-effects of violating the Component Rules are nasty on two fronts a) once violated there are no real good ways out (something will get messed up on the user's machine) and b) you don't usually realize you've violated the rules until it is too late (like when you need a critical security fix). If you're going to suggest a solution to this problem then expect it to be "pedantically picked through". From there you should adapt your solution based on feedback or specify how the feedback is actually addressed by the solution or note that your solution doesn't work and try something different. Partial success isn't an option here because the "partial failures" are so horrible. Second, please take the personal comments elsewhere. This is where we talk about the WiX toolset. Thank you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Wednesday, July 23, 2008 08:54 To: [EMAIL PROTECTED] Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Merge Module Help Christopher Painter wrote: > Once again you pedantically pick through my comment without actually offering > anything constructive yourself. Wow, I'm really put in my place, aren't I? -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
John Hall wrote: > Ah, we don't do patches, which is why it works for me :) > That's also an option. That's what ClickThrough does, using "early" major upgrades every time. In that case, you don't even need stable IDs. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
> John Hall wrote: > > I have written a tool that auto-generates .wxs files for some parts > > of my project - we ship a lot of example scripts. It only handles > > files and generates one component per file. The tool maintains a > > database (well, an XML file) that lists all the GUIDs ever > > allocated, and adds entries as it needs. That file is kept in source > > control. > > > > This seems to work well for me - have I missed something important? > > > > What happens when someone wants to remove a file? (You can't > remove a component in a patch.) Ah, we don't do patches, which is why it works for me :) John - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
Christopher Painter wrote: > Once again you pedantically pick through my comment without actually offering > anything constructive yourself. Wow, I'm really put in my place, aren't I? -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
I was thinking that the missing file would be the exception. Can you clarify what you have in mind? --- On Wed, 7/23/08, Christopher Karper <[EMAIL PROTECTED]> wrote: > From: Christopher Karper <[EMAIL PROTECTED]> > Subject: Re: [WiX-users] Merge Module Help > To: "General discussion for Windows Installer XML toolset." > > Date: Wednesday, July 23, 2008, 10:38 AM > FWIW, I personally would rather manage the process by > exception, instead of > *always*. > > Chris > > On Wed, Jul 23, 2008 at 11:33 AM, Bob Arnson > <[EMAIL PROTECTED]> wrote: > > > Christopher Painter wrote: > > > This would be a pretty easy scenario to handle. > Check the WXS against > > the XML and if a component is missing, throw an error > and suggest the > > puncture component pattern ( transitive=true > condition=false, 0 byte files > > for storage ) > > > > > > > "Throw an error" isn't the kind of > automation most people are looking for. > > > > -- > > sig://boB > > http://joyofsetup.com/ > > > > > > > > > - > > This SF.Net email is sponsored by the Moblin Your Move > Developer's > > challenge > > Build the coolest Linux based applications with Moblin > SDK & win great > > prizes > > Grand prize is a trip for two to an Open Source event > anywhere in the world > > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > - > This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge > Build the coolest Linux based applications with Moblin SDK > & win great prizes > Grand prize is a trip for two to an Open Source event > anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
Christopher Karper wrote: > FWIW, I personally would rather manage the process by exception, instead of > *always*. > Yes, some help is usually better than none. It's all about managing expectations. If it's possible to automatically generate the original setups, not being able to generate patches might be surprising. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
Once again you pedantically pick through my comment without actually offering anything constructive yourself. Do you feel better now? FWIW it would be nice if you applied your own comment to programs like HEAT because when I saw run a heat harvest command and get a JIT exception, that's certainly not the behavior that I'm looking for in a tool that's supposed to make life easier not harder. Information, Warning, Error... pick one. I pick error because if the installer consumed a file that is no longer there you need to know about it. You could have a configuration setting that declares the event as a warning and automatically implements the punctured components pattern but I think that assumes too much that the missing file is correctly missing. --- On Wed, 7/23/08, Bob Arnson <[EMAIL PROTECTED]> wrote: > From: Bob Arnson <[EMAIL PROTECTED]> > Subject: Re: [WiX-users] Merge Module Help > To: [EMAIL PROTECTED], "General discussion for Windows Installer XML > toolset." > Date: Wednesday, July 23, 2008, 10:33 AM > Christopher Painter wrote: > > This would be a pretty easy scenario to handle. Check > the WXS against the XML and if a component is missing, throw > an error and suggest the puncture component pattern ( > transitive=true condition=false, 0 byte files for storage > ) > > > > "Throw an error" isn't the kind of automation > most people are looking for. > > -- > sig://boB > http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
FWIW, I personally would rather manage the process by exception, instead of *always*. Chris On Wed, Jul 23, 2008 at 11:33 AM, Bob Arnson <[EMAIL PROTECTED]> wrote: > Christopher Painter wrote: > > This would be a pretty easy scenario to handle. Check the WXS against > the XML and if a component is missing, throw an error and suggest the > puncture component pattern ( transitive=true condition=false, 0 byte files > for storage ) > > > > "Throw an error" isn't the kind of automation most people are looking for. > > -- > sig://boB > http://joyofsetup.com/ > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
Christopher Painter wrote: > This would be a pretty easy scenario to handle. Check the WXS against the > XML and if a component is missing, throw an error and suggest the puncture > component pattern ( transitive=true condition=false, 0 byte files for > storage ) > "Throw an error" isn't the kind of automation most people are looking for. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
This would be a pretty easy scenario to handle. Check the WXS against the XML and if a component is missing, throw an error and suggest the puncture component pattern ( transitive=true condition=false, 0 byte files for storage ) --- On Wed, 7/23/08, Bob Arnson <[EMAIL PROTECTED]> wrote: > From: Bob Arnson <[EMAIL PROTECTED]> > Subject: Re: [WiX-users] Merge Module Help > To: "General discussion for Windows Installer XML toolset." > > Date: Wednesday, July 23, 2008, 9:32 AM > John Hall wrote: > > I have written a tool that auto-generates .wxs files > for some parts of > > my project - we ship a lot of example scripts. It only > handles files and > > generates one component per file. The tool maintains a > database (well, > > an XML file) that lists all the GUIDs ever allocated, > and adds entries > > as it needs. That file is kept in source control. > > > > This seems to work well for me - have I missed > something important? > > > > What happens when someone wants to remove a file? (You > can't remove a > component in a patch.) > > -- > sig://boB > http://joyofsetup.com/ > > > > - > This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge > Build the coolest Linux based applications with Moblin SDK > & win great prizes > Grand prize is a trip for two to an Open Source event > anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
John Hall wrote: > I have written a tool that auto-generates .wxs files for some parts of > my project - we ship a lot of example scripts. It only handles files and > generates one component per file. The tool maintains a database (well, > an XML file) that lists all the GUIDs ever allocated, and adds entries > as it needs. That file is kept in source control. > > This seems to work well for me - have I missed something important? > What happens when someone wants to remove a file? (You can't remove a component in a patch.) -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
> The case that gets really tricky is to have one build where a Resource > disappears (usually accidentally) then the next build where the > Resource comes back. It needs to get the same Component and GUID. I have written a tool that auto-generates .wxs files for some parts of my project - we ship a lot of example scripts. It only handles files and generates one component per file. The tool maintains a database (well, an XML file) that lists all the GUIDs ever allocated, and adds entries as it needs. That file is kept in source control. This seems to work well for me - have I missed something important? Regards, John - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
I also have the advantage (disadvantage?) of "scale" to "inform" my opinions. I routinely have to deal with projects the size of Office, SQL Server and Visual Studio so there is plenty of opportunity for "cosmic rays" (Murphy's law?) to sneak in and blow the "quick but incomplete" (hack?) solutions out of the water. Failure for multi-billion dollar (no exaggeration) projects also isn't an option so I usually feel compelled to look for the complete solution. I know it has frustrated people in the past that we don't just "make heat.exe work" but there are some tricky problems in there and, honestly, no one is working on them. I want to believe there is a good solution to the Component/@Guid problem out there... but I haven't seen it yet. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Minnis Sent: Saturday, July 19, 2008 17:49 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Merge Module Help That's an excellent point. The devil, as always, is in the details of when someone screws up. Since Murphy is looking out for us, it never manages to work ideally. :) -Jamey [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Rob Mensching > Sent: Saturday, July 19, 2008 1:15 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > I think you've over-simplified the Component Rules. Once a Component > contains a set of Resources, those Resources must ship in that Component > with that GUID forever. Resources are files, registry keys, shortcuts, > etc. (basically almost everything that can be a child of the Component > element). > > The case that gets really tricky is to have one build where a Resource > disappears (usually accidentally) then the next build where the Resource > comes back. It needs to get the same Component and GUID. > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of James Minnis > Sent: Saturday, July 19, 2008 13:08 > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] Merge Module Help > > I couldn't find a feature request for that with a couple of quick > searches, > but it is possible that I missed it. > > This is definitely not a trivial problem to solve, but I don't see why it > would be an intractable one. For a first pass, I'd generate a fragment > WXS > file where one element is a hash or CRC of the rest of the file. As long > as > the existing file generates the same hash/CRC, the file is unmodified and > you can safely import the existing autogenerated XML structures. You can > then do a diff with the existing file/folder structure and only modify > where > necessary. I'd make doing a merge with the existing file a new command > line > switch for Heat. > > Obviously, there are a lot of implementation details I'm sweeping under > the > rug, but conceptually I don't see why the problem is really hard, assuming > that the first pass can only work with unmodified output of the Harvester. > It wouldn't make everyone happy, but it is a method which most people > could > work with. > > -Jamey > ____________________ > [EMAIL PROTECTED] > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:wix-users- > > [EMAIL PROTECTED] On Behalf Of Rob Mensching > > Sent: Saturday, July 19, 2008 11:01 AM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Merge Module Help > > > > This is a constant feature request (I'm surprised there isn't a feature > > request already). Generating Component GUIDs that follow the Component > > Rules is an *extremely hard* problem to solve perfectly. The auto- > > generated Component GUIDs is pretty good (assuming it doesn't have any > > bugs) but has a number restrictions. Heat already supports those with > the > > "-ag" switch. > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:wix-users- > > [EMAIL PROTECTED] On Behalf Of James Minnis > > Sent: Saturday, July 19, 2008 09:15 > > To: 'General discussion for Windows Installer XML toolset.' > > Subject: Re: [WiX-users] Merge Module Help > > > > That's unfortunate. > > > > I could probably write something to keep the GUIDs standardized, but it > > woul
Re: [WiX-users] Merge Module Help
James I haven't been following this thread in detail but I read the "wixlib" bit and thought I might be able to help. I have been doing quite a lot with them recently and have found them to be an excellent replacement of merge modules (assuming the consumer is using WiX). Let me know if you need more details on how to create and use them - I am hoping to document this soon for the WiX help file. Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> From: [EMAIL PROTECTED] on behalf of James Minnis Sent: Sat 19/07/2008 21:11 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Merge Module Help Based on what people said in earlier messages, I'm migrating to using a wixlib with a fragment generated by Heat. A lack of samples or useful documentation had left me doing trial and error to figure how. If you think that there is a better method, please let me know what it is. :) -Jamey [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Bob Arnson > Sent: Saturday, July 19, 2008 10:22 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > James Minnis wrote: > > Right now, I'm generating a merge module > > Do you have a specific need for a merge module? (i.e., are you sharing > it with others so they can create installers?) If not, avoid merge > modules. They needlessly complicate things, as you're finding out with #1. > > > 1) I want to create shortcuts to several of the files in the merge > module. > > I'm doing this currently in a start menu shortcuts component in the main > > installer. However, I cannot figure out how to reference the > directories in > > the merge module in the main project (I get an empty string when I try > to > > reference them like I do the directories in the main installer project). > > How do I reference the directories? Or is there a better way to do > this? > > > > You can't. Merge modules are supposed to be self-contained, so if you > want shortcuts, define them in the merge module. Or don't use merge > modules. > > > 2) The components in the merge module are generated with GUIDs. If I > > regenerate the merge module WXS file using Heat (e.g. if I add files), > those > > GUIDs change. How will this affect patches? Will the patch recognize > the > > files as being the same, or will it consider all of the files changed > and > > overwrite everything? Will I need to add files manually to the merge > module > > WXS file to make patching work correctly? > > > > You won't be able to patch. The WiX approach is to use stable GUIDs > (heat's -ag switch). But with 7000 files, that's going to cause some > long pauses during costing. > > -- > sig://boB > http://joyofsetup.com/ > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
That's an excellent point. The devil, as always, is in the details of when someone screws up. Since Murphy is looking out for us, it never manages to work ideally. :) -Jamey [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Rob Mensching > Sent: Saturday, July 19, 2008 1:15 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > I think you've over-simplified the Component Rules. Once a Component > contains a set of Resources, those Resources must ship in that Component > with that GUID forever. Resources are files, registry keys, shortcuts, > etc. (basically almost everything that can be a child of the Component > element). > > The case that gets really tricky is to have one build where a Resource > disappears (usually accidentally) then the next build where the Resource > comes back. It needs to get the same Component and GUID. > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of James Minnis > Sent: Saturday, July 19, 2008 13:08 > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] Merge Module Help > > I couldn't find a feature request for that with a couple of quick > searches, > but it is possible that I missed it. > > This is definitely not a trivial problem to solve, but I don't see why it > would be an intractable one. For a first pass, I'd generate a fragment > WXS > file where one element is a hash or CRC of the rest of the file. As long > as > the existing file generates the same hash/CRC, the file is unmodified and > you can safely import the existing autogenerated XML structures. You can > then do a diff with the existing file/folder structure and only modify > where > necessary. I'd make doing a merge with the existing file a new command > line > switch for Heat. > > Obviously, there are a lot of implementation details I'm sweeping under > the > rug, but conceptually I don't see why the problem is really hard, assuming > that the first pass can only work with unmodified output of the Harvester. > It wouldn't make everyone happy, but it is a method which most people > could > work with. > > -Jamey > > [EMAIL PROTECTED] > > -Original Message----- > > From: [EMAIL PROTECTED] [mailto:wix-users- > > [EMAIL PROTECTED] On Behalf Of Rob Mensching > > Sent: Saturday, July 19, 2008 11:01 AM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Merge Module Help > > > > This is a constant feature request (I'm surprised there isn't a feature > > request already). Generating Component GUIDs that follow the Component > > Rules is an *extremely hard* problem to solve perfectly. The auto- > > generated Component GUIDs is pretty good (assuming it doesn't have any > > bugs) but has a number restrictions. Heat already supports those with > the > > "-ag" switch. > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:wix-users- > > [EMAIL PROTECTED] On Behalf Of James Minnis > > Sent: Saturday, July 19, 2008 09:15 > > To: 'General discussion for Windows Installer XML toolset.' > > Subject: Re: [WiX-users] Merge Module Help > > > > That's unfortunate. > > > > I could probably write something to keep the GUIDs standardized, but it > > would be more work than it's worth for a hobby project I'm doing in my > > spare > > time. > > > > Most of our updates will only involve changes to text files rather than > > adding or removing files. That implies a patch to me. If we have to > add > > or > > remove more than a small number of files, I guess we'll bite the bullet > > and > > do a major upgrade. It isn't ideal but it will work. > > > > I submitted a feature request (#2022259). Hopefully it will get some > > attention. > > > > -Jamey > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:wix-users- > > > [EMAIL PROTECTED] On Behalf Of Luke Bakken > > > Sent: Saturday, July 19, 2008 8:09 AM > > > To: General discussion for Windows Installer XML toolset. > > > Subject: Re: [WiX-users] Merge Module Help > > > > > > >> I'm surprised that Heat doesn't have the functionality of leav
Re: [WiX-users] Merge Module Help
I think you've over-simplified the Component Rules. Once a Component contains a set of Resources, those Resources must ship in that Component with that GUID forever. Resources are files, registry keys, shortcuts, etc. (basically almost everything that can be a child of the Component element). The case that gets really tricky is to have one build where a Resource disappears (usually accidentally) then the next build where the Resource comes back. It needs to get the same Component and GUID. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Minnis Sent: Saturday, July 19, 2008 13:08 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Merge Module Help I couldn't find a feature request for that with a couple of quick searches, but it is possible that I missed it. This is definitely not a trivial problem to solve, but I don't see why it would be an intractable one. For a first pass, I'd generate a fragment WXS file where one element is a hash or CRC of the rest of the file. As long as the existing file generates the same hash/CRC, the file is unmodified and you can safely import the existing autogenerated XML structures. You can then do a diff with the existing file/folder structure and only modify where necessary. I'd make doing a merge with the existing file a new command line switch for Heat. Obviously, there are a lot of implementation details I'm sweeping under the rug, but conceptually I don't see why the problem is really hard, assuming that the first pass can only work with unmodified output of the Harvester. It wouldn't make everyone happy, but it is a method which most people could work with. -Jamey [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Rob Mensching > Sent: Saturday, July 19, 2008 11:01 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > This is a constant feature request (I'm surprised there isn't a feature > request already). Generating Component GUIDs that follow the Component > Rules is an *extremely hard* problem to solve perfectly. The auto- > generated Component GUIDs is pretty good (assuming it doesn't have any > bugs) but has a number restrictions. Heat already supports those with the > "-ag" switch. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of James Minnis > Sent: Saturday, July 19, 2008 09:15 > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] Merge Module Help > > That's unfortunate. > > I could probably write something to keep the GUIDs standardized, but it > would be more work than it's worth for a hobby project I'm doing in my > spare > time. > > Most of our updates will only involve changes to text files rather than > adding or removing files. That implies a patch to me. If we have to add > or > remove more than a small number of files, I guess we'll bite the bullet > and > do a major upgrade. It isn't ideal but it will work. > > I submitted a feature request (#2022259). Hopefully it will get some > attention. > > -Jamey > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:wix-users- > > [EMAIL PROTECTED] On Behalf Of Luke Bakken > > Sent: Saturday, July 19, 2008 8:09 AM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Merge Module Help > > > > >> I'm surprised that Heat doesn't have the functionality of leaving the > > >> existing GUIDs in place. I just presumed I wasn't seeing how to do > it. > > > > > > There was (is?) a project called "Paraffin" (http://xrl.us/mnhwj) for > > > managing GUIDs. I've never used it so I can't vouch for it, but it may > > > be what you're looking for. > > > > > > > Hm. On re-reading that article it appears that Paraffin doesn't > > actually manage your GUIDs. You could accomplish something custom for > > your app using heat.exe and a database of some sort. It's definitely a > > missing part of the toolset. > > > > Where I work, teams that deal with large numbers of components just do > > major upgrades all the time. We figured that we would cross the GUID > > bridge when we had to for patches. > > > > > - > > This SF.Net email
Re: [WiX-users] Merge Module Help
Based on what people said in earlier messages, I'm migrating to using a wixlib with a fragment generated by Heat. A lack of samples or useful documentation had left me doing trial and error to figure how. If you think that there is a better method, please let me know what it is. :) -Jamey [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Bob Arnson > Sent: Saturday, July 19, 2008 10:22 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > James Minnis wrote: > > Right now, I'm generating a merge module > > Do you have a specific need for a merge module? (i.e., are you sharing > it with others so they can create installers?) If not, avoid merge > modules. They needlessly complicate things, as you're finding out with #1. > > > 1) I want to create shortcuts to several of the files in the merge > module. > > I'm doing this currently in a start menu shortcuts component in the main > > installer. However, I cannot figure out how to reference the > directories in > > the merge module in the main project (I get an empty string when I try > to > > reference them like I do the directories in the main installer project). > > How do I reference the directories? Or is there a better way to do > this? > > > > You can't. Merge modules are supposed to be self-contained, so if you > want shortcuts, define them in the merge module. Or don't use merge > modules. > > > 2) The components in the merge module are generated with GUIDs. If I > > regenerate the merge module WXS file using Heat (e.g. if I add files), > those > > GUIDs change. How will this affect patches? Will the patch recognize > the > > files as being the same, or will it consider all of the files changed > and > > overwrite everything? Will I need to add files manually to the merge > module > > WXS file to make patching work correctly? > > > > You won't be able to patch. The WiX approach is to use stable GUIDs > (heat's -ag switch). But with 7000 files, that's going to cause some > long pauses during costing. > > -- > sig://boB > http://joyofsetup.com/ > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
I couldn't find a feature request for that with a couple of quick searches, but it is possible that I missed it. This is definitely not a trivial problem to solve, but I don't see why it would be an intractable one. For a first pass, I'd generate a fragment WXS file where one element is a hash or CRC of the rest of the file. As long as the existing file generates the same hash/CRC, the file is unmodified and you can safely import the existing autogenerated XML structures. You can then do a diff with the existing file/folder structure and only modify where necessary. I'd make doing a merge with the existing file a new command line switch for Heat. Obviously, there are a lot of implementation details I'm sweeping under the rug, but conceptually I don't see why the problem is really hard, assuming that the first pass can only work with unmodified output of the Harvester. It wouldn't make everyone happy, but it is a method which most people could work with. -Jamey [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Rob Mensching > Sent: Saturday, July 19, 2008 11:01 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > This is a constant feature request (I'm surprised there isn't a feature > request already). Generating Component GUIDs that follow the Component > Rules is an *extremely hard* problem to solve perfectly. The auto- > generated Component GUIDs is pretty good (assuming it doesn't have any > bugs) but has a number restrictions. Heat already supports those with the > "-ag" switch. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of James Minnis > Sent: Saturday, July 19, 2008 09:15 > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] Merge Module Help > > That's unfortunate. > > I could probably write something to keep the GUIDs standardized, but it > would be more work than it's worth for a hobby project I'm doing in my > spare > time. > > Most of our updates will only involve changes to text files rather than > adding or removing files. That implies a patch to me. If we have to add > or > remove more than a small number of files, I guess we'll bite the bullet > and > do a major upgrade. It isn't ideal but it will work. > > I submitted a feature request (#2022259). Hopefully it will get some > attention. > > -Jamey > > > -Original Message----- > > From: [EMAIL PROTECTED] [mailto:wix-users- > > [EMAIL PROTECTED] On Behalf Of Luke Bakken > > Sent: Saturday, July 19, 2008 8:09 AM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Merge Module Help > > > > >> I'm surprised that Heat doesn't have the functionality of leaving the > > >> existing GUIDs in place. I just presumed I wasn't seeing how to do > it. > > > > > > There was (is?) a project called "Paraffin" (http://xrl.us/mnhwj) for > > > managing GUIDs. I've never used it so I can't vouch for it, but it may > > > be what you're looking for. > > > > > > > Hm. On re-reading that article it appears that Paraffin doesn't > > actually manage your GUIDs. You could accomplish something custom for > > your app using heat.exe and a database of some sort. It's definitely a > > missing part of the toolset. > > > > Where I work, teams that deal with large numbers of components just do > > major upgrades all the time. We figured that we would cross the GUID > > bridge when we had to for patches. > > > > > - > > This SF.Net email is sponsored by the Moblin Your Move Developer's > > challenge > > Build the coolest Linux based applications with Moblin SDK & win great > > prizes > > Grand prize is a trip for two to an Open Source event anywhere in the > > world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with M
Re: [WiX-users] Merge Module Help
This is a constant feature request (I'm surprised there isn't a feature request already). Generating Component GUIDs that follow the Component Rules is an *extremely hard* problem to solve perfectly. The auto-generated Component GUIDs is pretty good (assuming it doesn't have any bugs) but has a number restrictions. Heat already supports those with the "-ag" switch. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Minnis Sent: Saturday, July 19, 2008 09:15 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Merge Module Help That's unfortunate. I could probably write something to keep the GUIDs standardized, but it would be more work than it's worth for a hobby project I'm doing in my spare time. Most of our updates will only involve changes to text files rather than adding or removing files. That implies a patch to me. If we have to add or remove more than a small number of files, I guess we'll bite the bullet and do a major upgrade. It isn't ideal but it will work. I submitted a feature request (#2022259). Hopefully it will get some attention. -Jamey > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Luke Bakken > Sent: Saturday, July 19, 2008 8:09 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > >> I'm surprised that Heat doesn't have the functionality of leaving the > >> existing GUIDs in place. I just presumed I wasn't seeing how to do it. > > > > There was (is?) a project called "Paraffin" (http://xrl.us/mnhwj) for > > managing GUIDs. I've never used it so I can't vouch for it, but it may > > be what you're looking for. > > > > Hm. On re-reading that article it appears that Paraffin doesn't > actually manage your GUIDs. You could accomplish something custom for > your app using heat.exe and a database of some sort. It's definitely a > missing part of the toolset. > > Where I work, teams that deal with large numbers of components just do > major upgrades all the time. We figured that we would cross the GUID > bridge when we had to for patches. > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
James Minnis wrote: > Right now, I'm generating a merge module Do you have a specific need for a merge module? (i.e., are you sharing it with others so they can create installers?) If not, avoid merge modules. They needlessly complicate things, as you're finding out with #1. > 1) I want to create shortcuts to several of the files in the merge module. > I'm doing this currently in a start menu shortcuts component in the main > installer. However, I cannot figure out how to reference the directories in > the merge module in the main project (I get an empty string when I try to > reference them like I do the directories in the main installer project). > How do I reference the directories? Or is there a better way to do this? > You can't. Merge modules are supposed to be self-contained, so if you want shortcuts, define them in the merge module. Or don't use merge modules. > 2) The components in the merge module are generated with GUIDs. If I > regenerate the merge module WXS file using Heat (e.g. if I add files), those > GUIDs change. How will this affect patches? Will the patch recognize the > files as being the same, or will it consider all of the files changed and > overwrite everything? Will I need to add files manually to the merge module > WXS file to make patching work correctly? > You won't be able to patch. The WiX approach is to use stable GUIDs (heat's -ag switch). But with 7000 files, that's going to cause some long pauses during costing. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
That's unfortunate. I could probably write something to keep the GUIDs standardized, but it would be more work than it's worth for a hobby project I'm doing in my spare time. Most of our updates will only involve changes to text files rather than adding or removing files. That implies a patch to me. If we have to add or remove more than a small number of files, I guess we'll bite the bullet and do a major upgrade. It isn't ideal but it will work. I submitted a feature request (#2022259). Hopefully it will get some attention. -Jamey > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Luke Bakken > Sent: Saturday, July 19, 2008 8:09 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > >> I'm surprised that Heat doesn't have the functionality of leaving the > >> existing GUIDs in place. I just presumed I wasn't seeing how to do it. > > > > There was (is?) a project called "Paraffin" (http://xrl.us/mnhwj) for > > managing GUIDs. I've never used it so I can't vouch for it, but it may > > be what you're looking for. > > > > Hm. On re-reading that article it appears that Paraffin doesn't > actually manage your GUIDs. You could accomplish something custom for > your app using heat.exe and a database of some sort. It's definitely a > missing part of the toolset. > > Where I work, teams that deal with large numbers of components just do > major upgrades all the time. We figured that we would cross the GUID > bridge when we had to for patches. > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
>> I'm surprised that Heat doesn't have the functionality of leaving the >> existing GUIDs in place. I just presumed I wasn't seeing how to do it. > > There was (is?) a project called "Paraffin" (http://xrl.us/mnhwj) for > managing GUIDs. I've never used it so I can't vouch for it, but it may > be what you're looking for. > Hm. On re-reading that article it appears that Paraffin doesn't actually manage your GUIDs. You could accomplish something custom for your app using heat.exe and a database of some sort. It's definitely a missing part of the toolset. Where I work, teams that deal with large numbers of components just do major upgrades all the time. We figured that we would cross the GUID bridge when we had to for patches. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
> updates, but it is very much not ideal. The biggest problem with this is > the lag in the Visual Studio IDE when dealing with a roughly 3 MB XML file > for the merge module. Don't use VS to edit your XML. Something like Notepad2 or Vim or any modern text editor should work great. > I'm surprised that Heat doesn't have the functionality of leaving the > existing GUIDs in place. I just presumed I wasn't seeing how to do it. There was (is?) a project called "Paraffin" (http://xrl.us/mnhwj) for managing GUIDs. I've never used it so I can't vouch for it, but it may be what you're looking for. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
If you're using Votive, you can just create a .wixlib project. That will set up everything you need. I don't have a lot of experience with them, as I can't use them. Chris On Sat, Jul 19, 2008 at 2:51 AM, James Minnis <[EMAIL PROTECTED]> wrote: > For major updates, changing the GUIDs should not matter as it does an > uninstall of the old version then an install of the new version. I just > won't provide a patch to make that leap. This should be acceptable because > it will be infrequent. > > For smaller changes, a minor upgrade via patch should be doable with hand > updates, but it is very much not ideal. The biggest problem with this is > the lag in the Visual Studio IDE when dealing with a roughly 3 MB XML file > for the merge module. I can mitigate this to some extent by breaking it > into several smaller projects by subdirectory, but I'm unfortunately > dealing > with a directory and file structure that cannot be changed (this installer > is for a mod for a video game). > > I'm surprised that Heat doesn't have the functionality of leaving the > existing GUIDs in place. I just presumed I wasn't seeing how to do it. > > I'm familiar with merge modules from developing MSIs for work, so that was > my first thought when looking at Heat's options. I haven't been able to > find any documentation on how to create a wixlib with Heat or how to > include > a wixlib in a primary project. A sample project featuring a wixlib would > be > even better. Do either documentation or a sample project exist somewhere? > > -Jamey > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:wix-users- > > [EMAIL PROTECTED] On Behalf Of Christopher Karper > > Sent: Friday, July 18, 2008 5:52 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Merge Module Help > > > > I can't really answer intelligently to question #1, as to question #2, > > I'll > > do my best. > > > > Heat is really built for initial import functionality, not continual > > maintenance. You do not want your GUIDs changing on your components with > > each build, it will turn upgrades into a nightmare, and will make > patching > > just about impossible, IMO. The "suggested" method, is to use heat.exe > > to > > build your .wxs up front, then manually maintain the .wxs file as part of > > your development process from there on out. If someone adds an artifact > > to > > a project in a future version, they need to add it to the installer > > definition as well. > > > > If you have the ability to go pure Wix with your installers, then you can > > break this into manageable chunks using a .wixlib project for each major > > subsystem, and having one parent .msi project link them all together. > > This > > is similar, but superior, to building .msm files and importing those in. > > If your "parent" project is not Wix, then you're stuck in the same boat I > > am, building .msm's. > > > > Either way you're stuck making manual changes to the .wxs files to keep > > them > > in sync with your project's outputs and required support files. I > > *really* > > wish this wasn't the case, as the whole point of using an IDE (for me) is > > to > > manage all the grunt work like that, but there are some pretty > substantial > > complexities making it a pretty large undertaking that the team just > > hasn't > > gotten to yet. > > > > Chris > > > > On Fri, Jul 18, 2008 at 7:53 PM, James Minnis <[EMAIL PROTECTED]> > > wrote: > > > > > I'm working on a fairly large installer. It contains roughly 7000 > files > > in > > > 165 folders and a total of 670 MB of uncompressed data. Needless to > > say, > > > I'm generating the files, components, and directories using Heat. > > > > > > Right now, I'm generating a merge module WXS file using Heat and then > > using > > > the Merge and MergeRef elements in my main installer. This is all > > working > > > correctly. I have several questions related to this: > > > > > > 1) I want to create shortcuts to several of the files in the merge > > module. > > > I'm doing this currently in a start menu shortcuts component in the > main > > > installer. However, I cannot figure out how to reference the > > directories > > > in > > > the merge module in the main project (I get an empty string when I tr
Re: [WiX-users] Merge Module Help
For major updates, changing the GUIDs should not matter as it does an uninstall of the old version then an install of the new version. I just won't provide a patch to make that leap. This should be acceptable because it will be infrequent. For smaller changes, a minor upgrade via patch should be doable with hand updates, but it is very much not ideal. The biggest problem with this is the lag in the Visual Studio IDE when dealing with a roughly 3 MB XML file for the merge module. I can mitigate this to some extent by breaking it into several smaller projects by subdirectory, but I'm unfortunately dealing with a directory and file structure that cannot be changed (this installer is for a mod for a video game). I'm surprised that Heat doesn't have the functionality of leaving the existing GUIDs in place. I just presumed I wasn't seeing how to do it. I'm familiar with merge modules from developing MSIs for work, so that was my first thought when looking at Heat's options. I haven't been able to find any documentation on how to create a wixlib with Heat or how to include a wixlib in a primary project. A sample project featuring a wixlib would be even better. Do either documentation or a sample project exist somewhere? -Jamey > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Christopher Karper > Sent: Friday, July 18, 2008 5:52 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > I can't really answer intelligently to question #1, as to question #2, > I'll > do my best. > > Heat is really built for initial import functionality, not continual > maintenance. You do not want your GUIDs changing on your components with > each build, it will turn upgrades into a nightmare, and will make patching > just about impossible, IMO. The "suggested" method, is to use heat.exe > to > build your .wxs up front, then manually maintain the .wxs file as part of > your development process from there on out. If someone adds an artifact > to > a project in a future version, they need to add it to the installer > definition as well. > > If you have the ability to go pure Wix with your installers, then you can > break this into manageable chunks using a .wixlib project for each major > subsystem, and having one parent .msi project link them all together. > This > is similar, but superior, to building .msm files and importing those in. > If your "parent" project is not Wix, then you're stuck in the same boat I > am, building .msm's. > > Either way you're stuck making manual changes to the .wxs files to keep > them > in sync with your project's outputs and required support files. I > *really* > wish this wasn't the case, as the whole point of using an IDE (for me) is > to > manage all the grunt work like that, but there are some pretty substantial > complexities making it a pretty large undertaking that the team just > hasn't > gotten to yet. > > Chris > > On Fri, Jul 18, 2008 at 7:53 PM, James Minnis <[EMAIL PROTECTED]> > wrote: > > > I'm working on a fairly large installer. It contains roughly 7000 files > in > > 165 folders and a total of 670 MB of uncompressed data. Needless to > say, > > I'm generating the files, components, and directories using Heat. > > > > Right now, I'm generating a merge module WXS file using Heat and then > using > > the Merge and MergeRef elements in my main installer. This is all > working > > correctly. I have several questions related to this: > > > > 1) I want to create shortcuts to several of the files in the merge > module. > > I'm doing this currently in a start menu shortcuts component in the main > > installer. However, I cannot figure out how to reference the > directories > > in > > the merge module in the main project (I get an empty string when I try > to > > reference them like I do the directories in the main installer project). > > How do I reference the directories? Or is there a better way to do > this? > > > > 2) The components in the merge module are generated with GUIDs. If I > > regenerate the merge module WXS file using Heat (e.g. if I add files), > > those > > GUIDs change. How will this affect patches? Will the patch recognize > the > > files as being the same, or will it consider all of the files changed > and > > overwrite everything? Will I need to add files manually to the merge > > module > > WXS file to make patching work correctly? > > > > -Jamey > > > > > > ---
Re: [WiX-users] Merge Module Help
I can't really answer intelligently to question #1, as to question #2, I'll do my best. Heat is really built for initial import functionality, not continual maintenance. You do not want your GUIDs changing on your components with each build, it will turn upgrades into a nightmare, and will make patching just about impossible, IMO. The "suggested" method, is to use heat.exe to build your .wxs up front, then manually maintain the .wxs file as part of your development process from there on out. If someone adds an artifact to a project in a future version, they need to add it to the installer definition as well. If you have the ability to go pure Wix with your installers, then you can break this into manageable chunks using a .wixlib project for each major subsystem, and having one parent .msi project link them all together. This is similar, but superior, to building .msm files and importing those in. If your "parent" project is not Wix, then you're stuck in the same boat I am, building .msm's. Either way you're stuck making manual changes to the .wxs files to keep them in sync with your project's outputs and required support files. I *really* wish this wasn't the case, as the whole point of using an IDE (for me) is to manage all the grunt work like that, but there are some pretty substantial complexities making it a pretty large undertaking that the team just hasn't gotten to yet. Chris On Fri, Jul 18, 2008 at 7:53 PM, James Minnis <[EMAIL PROTECTED]> wrote: > I'm working on a fairly large installer. It contains roughly 7000 files in > 165 folders and a total of 670 MB of uncompressed data. Needless to say, > I'm generating the files, components, and directories using Heat. > > Right now, I'm generating a merge module WXS file using Heat and then using > the Merge and MergeRef elements in my main installer. This is all working > correctly. I have several questions related to this: > > 1) I want to create shortcuts to several of the files in the merge module. > I'm doing this currently in a start menu shortcuts component in the main > installer. However, I cannot figure out how to reference the directories > in > the merge module in the main project (I get an empty string when I try to > reference them like I do the directories in the main installer project). > How do I reference the directories? Or is there a better way to do this? > > 2) The components in the merge module are generated with GUIDs. If I > regenerate the merge module WXS file using Heat (e.g. if I add files), > those > GUIDs change. How will this affect patches? Will the patch recognize the > files as being the same, or will it consider all of the files changed and > overwrite everything? Will I need to add files manually to the merge > module > WXS file to make patching work correctly? > > -Jamey > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
