No, we haven't shipped yet. At this point, our build system doesn't (easily) support check-ins back to source control. So, our -gg script might as well be an -ag script. I have only checked in a simple stub component file for the project which gets over-written by a prebuild batch file that, among other things, runs heat using -gg.
We've never done patching the past, so I'm not too worried about our current implementation, or the limitations of heat. But, I'll probably take a look at parrafin at some point. On Fri, Oct 23, 2009 at 8:17 PM, Blair <os...@live.com> wrote: > With -ag, you don't necessarily need a checked in copy, although a reference > copy in your build dump couldn't hurt. > > -gg is only recommended if you run heat just one time on the involved file > and never ever run it again (you just maintain the authoring "manually" from > then on). Even if you never intend to patch, it is still not a good idea for > the same component with the same filename in the same directory to ever have > a different guid. > > Changing from -gg to -ag is just as bad. Once you have used -gg you need to > check that in and never change the guid again. > > I hope you haven't shipped yet. > > -----Original Message----- > From: Tony [mailto:yellowjacketl...@gmail.com] > Sent: Friday, October 23, 2009 9:45 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Build time Component.wxs generation... > > The would be output to changed if files were added/removed, which is > what I'm mostly concerned about. Web developer adds 5 more aspx pages > and the next build's websitecomponents.wxs file will now be different > than the previous version. But do I need a checked in copy of a build > time generated file?? > > On Fri, Oct 23, 2009 at 12:32 PM, Brian Rogers <rogers.br...@gmail.com> > wrote: >> Hey Tony, >> >> The GUID generation for -ag doesn't actually occur until Bind time. So, >> there would be no output for you to check in. Take a look at the Binder.cs >> and SetComponentGuids(Output output) method for more details. >> >> Thanks, >> >> Brian Rogers >> "Intelligence removes complexity." - Me >> http://blogs.msdn.com/icumove <-- NEW >> >> >> On Fri, Oct 23, 2009 at 8:26 AM, Tony <yellowjacketl...@gmail.com> wrote: >> >>> Yeah, I guess we give up the ability patch. Though we've never done >>> that before. Guess that's something for management to decide. >>> >>> We currently use the -gg option on one feature that would never be >>> patched. Though, I guess, -ag would accomplish the same behavior >>> since -gg generates new guids as well. >>> >>> Do you check-in the auto-generated component.wxs file? Or just >>> check-in an empty sub file? >>> >>> On Thu, Oct 22, 2009 at 4:46 PM, Blair <os...@live.com> wrote: >>> > Use heat.exe with "-ag" and always use Major Upgrade (Product Id='*'), >>> never >>> > patch. >>> > >>> > -----Original Message----- >>> > From: Tony [mailto:yellowjacketl...@gmail.com] >>> > Sent: Thursday, October 22, 2009 12:56 PM >>> > To: WiX Users >>> > Subject: [WiX-users] Build time Component.wxs generation... >>> > >>> > I'm aware of heat.exe and we have used to to seed our component.wxs >>> > files for our various wixlibs, but how do you deal with features like >>> > websites and help systems which often have dozens of files added at >>> > any time during development cycles? Re-running heat can work, sort >>> > of, it will change the component guids, but leaves the component Ids >>> > of existing components alone. Not sure how it deals with removed >>> > components. >>> > >>> > I stumbled across this 3rd party tool called Paraffin that appears to >>> > solve this issue, but have not attempted to put it to use in our build >>> > environment. >>> > >>> > What have others used to deal with features that often have an ever >>> > growing (and sometimes shrinking) list of components? >>> > -- >>> > Tony >>> > >>> > >>> > ---------------------------------------------------------------------------- >>> > -- >>> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>> > is the only developer event you need to attend this year. Jumpstart > your >>> > developing skills, take BlackBerry mobile applications to market and > stay >>> > ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>> > http://p.sf.net/sfu/devconference >>> > _______________________________________________ >>> > WiX-users mailing list >>> > WiX-users@lists.sourceforge.net >>> > https://lists.sourceforge.net/lists/listinfo/wix-users >>> > >>> > >>> > >>> > ---------------------------------------------------------------------------- > -- >>> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>> > is the only developer event you need to attend this year. Jumpstart > your >>> > developing skills, take BlackBerry mobile applications to market and > stay >>> > ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>> > http://p.sf.net/sfu/devconference >>> > _______________________________________________ >>> > WiX-users mailing list >>> > WiX-users@lists.sourceforge.net >>> > https://lists.sourceforge.net/lists/listinfo/wix-users >>> > >>> >>> >>> >>> -- >>> Tony >>> >>> >>> > ---------------------------------------------------------------------------- > -- >>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and stay >>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>> http://p.sf.net/sfu/devconference >>> _______________________________________________ >>> WiX-users mailing list >>> WiX-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/wix-users >>> >> > ---------------------------------------------------------------------------- > -- >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> > > > > -- > Tony > > ---------------------------------------------------------------------------- > -- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Tony ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
