Windows Installer XML (WiX) toolset › wix-users

Build time Component.wxs generation...

10 messages

Build time Component.wxs generation...

Reply Threaded

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Blair-2

Re: Build time Component.wxs generation...

Reply Threaded

Use heat.exe with "-ag" and always use Major Upgrade (Product Id='*'), never
patch.

-----Original Message-----
From: Tony [mailto:[hidden email]]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Tony-16

Re: Build time Component.wxs generation...

Reply Threaded

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 <[hidden email]> wrote:

> Use heat.exe with "-ag" and always use Major Upgrade (Product Id='*'), never
> patch.
>
> -----Original Message-----
> From: Tony [mailto:[hidden email]]
> 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
> [hidden email]
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

Brian Rogers

Re: Build time Component.wxs generation...

Reply Threaded

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 <[hidden email]> 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 <[hidden email]> wrote:
> > Use heat.exe with "-ag" and always use Major Upgrade (Product Id='*'),
> never
> > patch.
> >
> > -----Original Message-----
> > From: Tony [mailto:[hidden email]]
> > 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
> > [hidden email]
> > 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
> > [hidden email]
> > 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Tony-16

Re: Build time Component.wxs generation...

Reply Threaded

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> > Use heat.exe with "-ag" and always use Major Upgrade (Product Id='*'),
>> never
>> > patch.
>> >
>> > -----Original Message-----
>> > From: Tony [mailto:[hidden email]]
>> > 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
>> > [hidden email]
>> > 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
>> > [hidden email]
>> > 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
>> [hidden email]
>> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

Blair-2

Re: Build time Component.wxs generation...

Reply Threaded

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:[hidden email]]
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 <[hidden email]>
wrote:

----------------------------------------------------------------------------
>> > --
>> > 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
>> > [hidden email]
>> > 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

----------------------------------------------------------------------------
--

>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Tony-16

Re: Build time Component.wxs generation...

Reply Threaded

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 <[hidden email]> 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:[hidden email]]
> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>> > Use heat.exe with "-ag" and always use Major Upgrade (Product Id='*'),
>>> never
>>> > patch.
>>> >
>>> > -----Original Message-----
>>> > From: Tony [mailto:[hidden email]]
>>> > 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
>>> > [hidden email]
>>> > 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
>>> > [hidden email]
>>> > 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

Blair-2

Re: Build time Component.wxs generation...

Reply Threaded

I would recommend that the first change would be to update your prebuild
batch file and replace "-gg" with "-ag". The second would be to ensure that
the Id attribute of the Product element is "*" and ensure you have
functional Update authoring, and the third is to provide a way to have your
build system supply a version number (if it isn't already) where
build-to-build you alter something in the first three parts of the version
string (probably the third part).

-----Original Message-----
From: Tony [mailto:[hidden email]]
Sent: Monday, October 26, 2009 6:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Build time Component.wxs generation...

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 <[hidden email]> 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:[hidden email]]
> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>> > Use heat.exe with "-ag" and always use Major Upgrade (Product Id='*'),
>>> never
>>> > patch.
>>> >
>>> > -----Original Message-----
>>> > From: Tony [mailto:[hidden email]]
>>> > 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
>>> > [hidden email]
>>> > 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
>>> > [hidden email]
>>> > 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>

----------------------------------------------------------------------------
--

Tony-16

Re: Build time Component.wxs generation...

Reply Threaded

We do all of those things. Not to belabor the point, but in our
scenario (prebuild.bat generation of component.wxs using heat) is
there really a difference between -gg and -ag?

On Mon, Oct 26, 2009 at 11:18 AM, Blair <[hidden email]> wrote:

> I would recommend that the first change would be to update your prebuild
> batch file and replace "-gg" with "-ag". The second would be to ensure that
> the Id attribute of the Product element is "*" and ensure you have
> functional Update authoring, and the third is to provide a way to have your
> build system supply a version number (if it isn't already) where
> build-to-build you alter something in the first three parts of the version
> string (probably the third part).
>
> -----Original Message-----
> From: Tony [mailto:[hidden email]]
> Sent: Monday, October 26, 2009 6:50 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Build time Component.wxs generation...
>
> 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 <[hidden email]> 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:[hidden email]]
>> 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 <[hidden email]>
>> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>> > Use heat.exe with "-ag" and always use Major Upgrade (Product Id='*'),
>>>> never
>>>> > patch.
>>>> >
>>>> > -----Original Message-----
>>>> > From: Tony [mailto:[hidden email]]
>>>> > 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
>>>> > [hidden email]
>>>> > 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
>>>> > [hidden email]
>>>> > 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

Blair-2

Re: Build time Component.wxs generation...

Reply Threaded

Short answer:
-gg is intended for "run-heat-once-check-in-result" and manually tweak the
.wxs files later.
-ag is intended for "run-heat-each-build" where you may not be checking in
the .wxs files.

Intermediate answer:
-gg generates truly unique guids for each component that have no guarantee
of stability.
-ag allows the toolset to generate stable unique guids for each component.

Unstable guids in components force major upgrade sequence flows that limit
your flexibility by, among other things, preventing you from using either
Windows SxS registration (including the C++ runtime) and GAC deployments or
even deploy windows drivers. They also force those upgrades to be much less
efficient, taking much longer to carry out, and missing cases where
files-in-use should force some sort of restart to maintain/restore ecosystem
stability.

Even if you are not using any of these features (GAC, SxS, major upgrades of
running systems, drivers) today you probably don't want to rule out being
able to perform at least one of them in the future. You can't change the
upgrade sequence per-component or even per-feature, it can only be changed
per-package.

Search for "component-rule violations" for some examples of the problems
people have had and the hacky and/or costly workarounds they have had to
employ to continue shipping.

-----Original Message-----
From: Tony [mailto:[hidden email]]
Sent: Monday, October 26, 2009 4:33 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Build time Component.wxs generation...

We do all of those things. Not to belabor the point, but in our
scenario (prebuild.bat generation of component.wxs using heat) is
there really a difference between -gg and -ag?

On Mon, Oct 26, 2009 at 11:18 AM, Blair <[hidden email]> wrote:
> I would recommend that the first change would be to update your prebuild
> batch file and replace "-gg" with "-ag". The second would be to ensure
that
> the Id attribute of the Product element is "*" and ensure you have
> functional Update authoring, and the third is to provide a way to have
your

> build system supply a version number (if it isn't already) where
> build-to-build you alter something in the first three parts of the version
> string (probably the third part).
>
> -----Original Message-----
> From: Tony [mailto:[hidden email]]
> Sent: Monday, October 26, 2009 6:50 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Build time Component.wxs generation...
>
> 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 <[hidden email]> 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:[hidden email]]
>> 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 <[hidden email]>
>> 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 <[hidden email]>

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 <[hidden email]> wrote:
>>>> > Use heat.exe with "-ag" and always use Major Upgrade (Product

Id='*'),

>>>> never
>>>> > patch.
>>>> >
>>>> > -----Original Message-----
>>>> > From: Tony [mailto:[hidden email]]
>>>> > 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
>>>> > [hidden email]
>>>> > 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
>>>> > [hidden email]
>>>> > 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>>
>

----------------------------------------------------------------------------

----------------------------------------------------------------------------
--