Re: [WiX-users] unsubscribe

[Robert O'Brien]

...previously tried both temporary (preferred) and permanent options and both 
are not working.   

-Original Message-
From: Christopher Karper [mailto:christopher.kar...@gmail.com] 
Sent: Wednesday, November 18, 2009 7:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] unsubscribe

The footer of each message sent has a link to
https://lists.sourceforge.net/lists/listinfo/wix-users which has the
unsubscribe method.

Chris

On Wed, Nov 18, 2009 at 10:22 AM, Robert O'Brien <
robert.obr...@microsoft.com> wrote:

> Been trying various supported subscription configuration options, and this
> alternative attempt, to get temporarily unsubscribed from mailing list but
> those haven't been taking . . . going to escalate to
> sitel...@lists.sourceforge.net to see what's up.
>
> -Original Message-
> From: Matti Hägerlund [mailto:matti.hagerl...@gmail.com]
> Sent: Wednesday, November 18, 2009 7:17 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] unsubscribe
>
> Eh?
> /M4tti
>
> 2009/11/18 Robert O'Brien :
> > unsubscribe
> >
> --
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> > trial. Simplify your report design, integration and deployment - and
> focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
>
>
> --
>__o__o__o
>  _`\<,_ _`\<,_ _`\<,_
>  (_)/ (_)   (_)/ (_)   (_)/ (_)
>
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] unsubscribe

[Robert O'Brien]

Been trying various supported subscription configuration options, and this 
alternative attempt, to get temporarily unsubscribed from mailing list but 
those haven't been taking . . . going to escalate to 
sitel...@lists.sourceforge.net to see what's up.

-Original Message-
From: Matti Hägerlund [mailto:matti.hagerl...@gmail.com] 
Sent: Wednesday, November 18, 2009 7:17 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] unsubscribe

Eh?
/M4tti

2009/11/18 Robert O'Brien :
> unsubscribe
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
__o__o__o
  _`\<,_ _`\<,_ _`\<,_
 (_)/ (_)   (_)/ (_)   (_)/ (_)

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] unsubscribe

[Robert O'Brien]

unsubscribe
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] my wix-users@lists.sourceforge.net subscription settings configured with Mail Delivery = disabled . . . and yet I'm still getting list emails

[Robert O'Brien]

My wix-users@lists.sourceforge.net subscription settings configured with Mail 
Delivery = disabled . . . and yet I'm still getting list emails.   Am I missing 
something about how to make this subscription setting take effect?



--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] in the wix 3.5 release work is a file | new | project | wix | patch project template going to eventually get included?

[Robert O'Brien]

in the wix 3.5 release work is a file | new | project | wix | patch project 
template going to eventually get included?
--
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

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings?

[Robert O'Brien]

So it sounds like you are saying the following would not in fact work because 
the hashing of the Description attribute value would not come out to 1.




Therefore the caveat your are trying to clarify is that for sites where you 
know the siteid was not produced using the iis6 published hash algorithm of the 
site name in those cases you'd need to be explicit with the SiteId value for 
the search for the existing web site (not involving use of iis:WebAddress 
settings) to get you the desired result, e.g. specifically in case of Default 
Web Site we had better use SiteId="1" and not SiteId="*".





-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Thursday, April 09, 2009 10:13 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

I mentioned this because it may catch you out and SiteId="*" would fail. For 
example, if you created a site that set the site id to a fixed value, something 
that is perfectly valid to do (adsutil.vbs does this), the hash matching 
wouldn't would. You have found this I believe when trying to find the "Default 
Web Site" and find its site id is 1. This also explains why the name is case 
sensitive, the hash algorithm generates a different site id depending on the 
case. By setting SiteId="*" you are not searching for a name you are searching 
for the site id based on the hash of the name. Looking at the code in 
scaweb.cpp function ScaWebFindBase() I think site id takes precedence over 
name, so you could set the name to anything but as long as the site id is set 
correctly it will find the site.

I hope this helps.

Neil

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com]
Sent: 09 April 2009 17:50
To: 'General discussion for Windows Installer XML toolset.'; 
'tomtr...@artizan.com'; Neil Sleightholm
Cc: Dmitry Frenkel; Kiran Challa
Subject: RE: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

In our case we are not so concerned about what SiteId="*" will result in wrt 
the actual SiteId value that gets generated and used when the msi determines 
its necessary to create the iis:WebSite.

What we are really interested in is the fact that including the SiteId="*" 
attribute, based on discussions in this thread and our test results over the 
course of the past day, results in the iis extension searching the host for 
whether or not the web site already exists using a case sensitive name that 
matches the Description attribute value specified.

This is important behavior to us because w/o SiteId="*" attribute value in 
place what we found is that the iis extension would search the host for whether 
or not the web site already exists using the iis:WebAddress settings and this 
was undersirable because this is something that is not always predictable ad 
design time for all environments.  Example being cases where ops 
creates/configures the web site in advance of the msi having every been run.   
Or we have cases where ops configures the web site left behind after an 
uninstall where iis:WebSite associated component has Permanent="yes" and then 
on next install we want to be able to find that site by name because the port 
settings lookup won't produce an accurate result.

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Thursday, April 09, 2009 9:21 AM
To: General discussion for Windows Installer XML toolset.; tomtr...@artizan.com
Cc: Dmitry Frenkel
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

I think this thread may be misunderstanding what SiteId="*" means. I means use 
the IIS6 default of setting the site id to the hash of the name, I don't 
believe it is triggering a search of the description. A site id of 1 is the 
default of the "Default Web Site" created when IIS is installed. The hashing 
algorithm can generate a duplicate site id in which case IIS adds one until it 
finds a free number. See here for more details: 
http://blogs.msdn.com/mpoulson/archive/2006/03/06/544893.aspx

Neil

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com]
Sent: 09 April 2009 16:51
To: 'tomtr...@artizan.com'
Cc: Dmitry Frenkel; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Descri

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings?

[Robert O'Brien]

In our case we are not so concerned about what SiteId="*" will result in wrt 
the actual SiteId value that gets generated and used when the msi determines 
its necessary to create the iis:WebSite.

What we are really interested in is the fact that including the SiteId="*" 
attribute, based on discussions in this thread and our test results over the 
course of the past day, results in the iis extension searching the host for 
whether or not the web site already exists using a case sensitive name that 
matches the Description attribute value specified.

This is important behavior to us because w/o SiteId="*" attribute value in 
place what we found is that the iis extension would search the host for whether 
or not the web site already exists using the iis:WebAddress settings and this 
was undersirable because this is something that is not always predictable ad 
design time for all environments.  Example being cases where ops 
creates/configures the web site in advance of the msi having every been run.   
Or we have cases where ops configures the web site left behind after an 
uninstall where iis:WebSite associated component has Permanent="yes" and then 
on next install we want to be able to find that site by name because the port 
settings lookup won't produce an accurate result.

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Thursday, April 09, 2009 9:21 AM
To: General discussion for Windows Installer XML toolset.; tomtr...@artizan.com
Cc: Dmitry Frenkel
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

I think this thread may be misunderstanding what SiteId="*" means. I means use 
the IIS6 default of setting the site id to the hash of the name, I don't 
believe it is triggering a search of the description. A site id of 1 is the 
default of the "Default Web Site" created when IIS is installed. The hashing 
algorithm can generate a duplicate site id in which case IIS adds one until it 
finds a free number. See here for more details: 
http://blogs.msdn.com/mpoulson/archive/2006/03/06/544893.aspx

Neil

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com]
Sent: 09 April 2009 16:51
To: 'tomtr...@artizan.com'
Cc: Dmitry Frenkel; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

Thanks for the additional details and answers to questions.

I think given iis supports to two web sites using the same name and differing 
only in case then it's the right thing to do to have SiteId="*" triggered 
searching for Description attribute value matches to also be case sensitive.

Wrt our properties.wix entries to create references to existing web sites like 
the "Default Web Site" I think even there we will use SiteId="*" vs SiteId="1" 
because we really don't care what site id its living on (given that could 
change if you deleted it, added a different non default web site, and then 
recreated the default web site manually).   We really just care about being 
able to get a reference to the well known and understood "Default Web Site" for 
things that we'd like the installer to stick under it versus our things we want 
going under our " Web Site".

We tested in our properties.wix using the following so that we'd setup our 
reference to the Default Web Site w/o any suggestion of us caring what 
iis:WebAddress settings it had in place and got a compiler error as it seems it 
is a requirement to a sub-element to a iis:WebSite element.


Switching it to the following works but then we have the iis:WebAddress port 80 
setting/expectation.




q1 - is the above iis:WebSite sub-elemented requirement expected?

q2 - if so in this particular case since we have SiteId="*" in place to trigger 
the metabase search using the Description attribute value AND the fact that 
it's an iis:WebSite reference vs being part of a component can we expect that 
the iis:WebAddress element requirement in order to compile will really have no 
effect, e.g. it shouldn't matter whether or not at install time the default web 
site is configured with a port 80 binding.


From: Thomas S. Trias [mailto:tomtr...@artizan.com]
Sent: Wednesday, April 08, 2009 6:33 PM
To: Robert O'Brien
Cc: 'General discussion for Windows Installer XML toolset.'; Dmitry Frenkel; 
Kiran Challa
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings?

[Robert O'Brien]

Thanks for the additional details and answers to questions.

I think given iis supports to two web sites using the same name and differing 
only in case then it's the right thing to do to have SiteId="*" triggered 
searching for Description attribute value matches to also be case sensitive.

Wrt our properties.wix entries to create references to existing web sites like 
the "Default Web Site" I think even there we will use SiteId="*" vs SiteId="1" 
because we really don't care what site id its living on (given that could 
change if you deleted it, added a different non default web site, and then 
recreated the default web site manually).   We really just care about being 
able to get a reference to the well known and understood "Default Web Site" for 
things that we'd like the installer to stick under it versus our things we want 
going under our " Web Site".

We tested in our properties.wix using the following so that we'd setup our 
reference to the Default Web Site w/o any suggestion of us caring what 
iis:WebAddress settings it had in place and got a compiler error as it seems it 
is a requirement to a sub-element to a iis:WebSite element.


Switching it to the following works but then we have the iis:WebAddress port 80 
setting/expectation.




q1 - is the above iis:WebSite sub-elemented requirement expected?

q2 - if so in this particular case since we have SiteId="*" in place to trigger 
the metabase search using the Description attribute value AND the fact that 
it's an iis:WebSite reference vs being part of a component can we expect that 
the iis:WebAddress element requirement in order to compile will really have no 
effect, e.g. it shouldn't matter whether or not at install time the default web 
site is configured with a port 80 binding.


From: Thomas S. Trias [mailto:tomtr...@artizan.com]
Sent: Wednesday, April 08, 2009 6:33 PM
To: Robert O'Brien
Cc: 'General discussion for Windows Installer XML toolset.'; Dmitry Frenkel; 
Kiran Challa
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

I was pretty surprised to see the lstrcmpW there myself; however, it is 
entirely possible to have two sites where the MD_SERVER_COMMENT values differ 
only by case (or are even the same; hopefully the IIS Manager is keying sites 
by SiteId / metabase path and not by description).  Providing more control over 
the comparison would require either overloading the SiteId further or 
introducing additional attributes.  Of course, the default should be to behave 
as WiX does currently.  Note that host header comparisons are also case 
sensitive, so an additional attribute sounds like the most feasible solution.

1.  Correct

2.  Correct.  It's also nice if you configure the SiteId at installation time 
(perhaps by letting someone pick an existing site, or if you are upgrading an 
existing site.

3.  What can I say; for my particular needs, I'm living as close to the 
bleeding edge as I can.


Thomas S. Trias

Senior Developer

Artizan Internet Services

http://www.artizan.com/


 Original Message  
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?
From: Robert O'Brien 
<mailto:robert.obr...@microsoft.com>
To: 'tomtr...@artizan.com<mailto:tomtr...@artizan.com>' 
<mailto:tomtr...@artizan.com>, 'General discussion for 
Windows Installer XML toolset.' 
<mailto:wix-users@lists.sourceforge.net>
Cc: Dmitry Frenkel 
<mailto:dmitry.fren...@microsoft.com>, Kiran 
Challa <mailto:kicha...@microsoft.com>
Date: 4/8/2009 8:15 PM


Thanks for the additional clarification.  This is pretty much exactly what we 
want and need. The case sensitive Description attribute search would preferably 
be case insensitive but this we can live with or file a bug or feature request 
against to have changed to be case insensitive



To playback what I'm hearing and what Kiran is finding in tests so far using 
this information:

1. if we specify a SiteId="*" then the iis:WebSite Description attribute value 
gets used in a case sensitive search to see if a match exists before deciding 
to create a the site.  Any child iis:WebAddress settings of iis:WebSite entries 
where SiteId="*" attribute is included will not affect the search to see if an 
existing instance of the web site is present before deciding to create a the 
site.



2. if we specify a SiteId="#" then the iis:WebSite syntax will look for 
explicitly for that SiteId to see if a match exists before deciding to create a 
new site.  This is particularly useful in case where you&#x

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings?

[Robert O'Brien]

Thanks for the additional clarification.  This is pretty much exactly what we 
want and need. The case sensitive Description attribute search would preferably 
be case insensitive but this we can live with or file a bug or feature request 
against to have changed to be case insensitive

To playback what I'm hearing and what Kiran is finding in tests so far using 
this information:
1. if we specify a SiteId="*" then the iis:WebSite Description attribute value 
gets used in a case sensitive search to see if a match exists before deciding 
to create a the site.  Any child iis:WebAddress settings of iis:WebSite entries 
where SiteId="*" attribute is included will not affect the search to see if an 
existing instance of the web site is present before deciding to create a the 
site.

2. if we specify a SiteId="#" then the iis:WebSite syntax will look for 
explicitly for that SiteId to see if a match exists before deciding to create a 
new site.  This is particularly useful in case where you'd like to creating 
iis:WebSite references to well known "Default Web Site" where SiteId="1" 
attribute setting can be used so that in the case of a w08 or w08r2 default web 
server role installation you end up referencing the "Default Web Site" as 
confirmed by executing either of the following commands:
   %windir%\system32\inetsrv\appcmd.exe list sites
   %windir%\system32\inetsrv\appcmd.exe list site "Default Web Site" /config:*
Any child iis:WebAddress settings of iis:WebSite entries where SiteId="#" 
attribute is included will not affect the search to see if an existing instance 
of the web site is present before deciding to create a the site.

3. based on kiran's tests today the SiteId attribute processing doesn't appear 
to work in wix 3 official beta release 4805 but does work in newer builds such 
as 4923.

-Original Message-
From: Thomas S. Trias [mailto:tomtr...@artizan.com] 
Sent: Wednesday, April 08, 2009 5:57 PM
To: General discussion for Windows Installer XML toolset.
Cc: Dmitry Frenkel
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name attribute value versus port settings?

You are correct; "Default Web Site" is handled specially, and if you 
always want Site Id 0, that is what you should use.

However, the effect of SiteId="*" is not exactly as advertised in the 
documentation.
candle and light generate a -1 in the Id field of the IIsWebSite record 
within the MSI if the SiteId is "*".
This causes ConfigureIIsExec to use the following search criteria when 
looking for the site in the metabase:

mrCompare.dwMDIdentifier = MD_SERVER_COMMENT;
mrCompare.dwMDAttributes = METADATA_INHERIT;
mrCompare.dwMDUserType = IIS_MD_UT_SERVER;
mrCompare.dwMDDataType = ALL_METADATA;
mrCompare.dwMDDataLen = 0;
mrCompare.pbMDData = NULL;

where mrCompare is a METADATA_RECORD structure that gets passed to 
MetaGetValue in order to get the data with with which to compare the 
IIsWebSite record.
The Id of -1 also causes the comparison of mrCompare.pbMDData to take 
place as a case sensitive Unicode comparison against the Description field.

So, a hash of the description is not actually being used.

Thanks,

Thomas S. Trias
Senior Developer
Artizan Internet Services
http://www.artizan.com/



 Original Message  
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate   
 presence ofexisting website using just the Name attribute value 
versusportsettings?
From: Robert O'Brien 
To: 'General discussion for Windows Installer XML toolset.'   
 , 'tomtr...@artizan.com'   
 , Kiran Challa 
Cc: Dmitry Frenkel 
Date: 4/8/2009 6:31 PM
> + in case of a properties.wix declaration of a "Default Web Site" so that we 
> have a way to do things against that well known iis7x site if/when we need to 
> I'm guessing that we must use SiteId="0" in that case, vs SiteId="*", so that 
> we always find use the site with name "Default Web Site" known to be site 0 
> regardless of what port and/or host header and/or ip bindings an operator has 
> created on it for a given environment, e.g.
>
>  Id="http" Port="80" />
>  
> becomes just the following without the iis:WebAddress specifics?
>
> 
>  
> -Original Message-
> From: Robert O'Brien [mailto:robert.obr...@microsoft.com] 
> Sent: Wednesday, April 08, 2009 4:19 PM
> To: 'tomtr...@artizan.com'; 'General discussion for Windows Installer XML 
> toolset.'; Kiran Challa
> Cc: Dmitry Frenkel
> Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
> of existing website using just the Name attribute value versus port settings?
>
> Thanks

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name attribute value versus port settings?

[Robert O'Brien]

+ in case of a properties.wix declaration of a "Default Web Site" so that we 
have a way to do things against that well known iis7x site if/when we need to 
I'm guessing that we must use SiteId="0" in that case, vs SiteId="*", so that 
we always find use the site with name "Default Web Site" known to be site 0 
regardless of what port and/or host header and/or ip bindings an operator has 
created on it for a given environment, e.g.


 
becomes just the following without the iis:WebAddress specifics?


 
-----Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com] 
Sent: Wednesday, April 08, 2009 4:19 PM
To: 'tomtr...@artizan.com'; 'General discussion for Windows Installer XML 
toolset.'; Kiran Challa
Cc: Dmitry Frenkel
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name attribute value versus port settings?

Thanks this helps.  Currently Kiran is testing this out to see if it provides 
the iis:WebSite behavior outlined below that we are looking for.   

Is there an current lkg build newer than the public wix 3 beta1 release 4805 
that folks can switch to in order to ensure they have all the latest and 
greatest fixes that have gone in since 4805 but still be on a known to be good 
install?

 
-Original Message-
From: Thomas S. Trias [mailto:tomtr...@artizan.com] 
Sent: Wednesday, April 08, 2009 11:20 AM
To: General discussion for Windows Installer XML toolset.
Cc: Dmitry Frenkel
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name attribute value versus port settings?

Robert,

Add  SiteId="*" as an attribute to iis:WebSite.

SiteId  String  Optional attribute to directly specify the site id of 
the WebSite. Use this to ensure all web sites in a web garden get the 
same site id. If a number is provided, the site id must be unique on all 
target machines. If "*" is used, the Description attribute will be 
hashed to create a unique value for the site id. This value must be a 
positive number or a "*" or a formatted value that resolves to "-1" (for 
the same behavior as "*") or a positive number or blank. If this 
attribute is absent then the web site will be located using the 
WebAddress element associated with the web site.


Thanks,

Thomas S. Trias
Senior Developer
Artizan Internet Services
http://www.artizan.com/


 Original Message  
Subject: [WiX-users] is it a bug that iis:WebSite doesn't locate 
presence ofexisting website using just the Name attribute value 
versus portsettings?
From: Robert O'Brien 
To: 'wix-users@lists.sourceforge.net' 
Cc: Dmitry Frenkel 
Date: 4/7/2009 7:14 PM
> We have a service deliverable msi where optionally have some w08/iis70 
> "Default Web Site" vdir settings we want to apply and some "Site1 Web Site" 
> and "Site2 Web Site" settings we want to apply (see relevant excerpt below).  
>  We need to allow for deployments where "Site1 Web Site" and "Site2 Web Site" 
> already exist as a result of OPS having set them up in advance.   This is to 
> enable scenarios where all web sites are advertised on tcp/80 and tcp/443 and 
> OPS uses environment specific IP or host header name settings to 
> differentiate incoming requests.In our installer we won't know what those 
> environment specific IP or host header name settings are.
>
> What we are finding  is that the iis:WebSite extension uses iis:WebAddress 
> port settings to determine if the site is already present.   So in cases 
> where all three iis:WebSite details in our code of iis:WebAddress portEUR 
> defined, and no other unique setting such as ip or host header, they always 
> end up latching onto and modifying the "Default Web Site".
>
> q1 - is this expected behavior for the iis:WebSite extension?
> q2 - if this is expected behavior is there some way to work around this so 
> that we can get it looking for an existing install of the iis:WebSite using 
> just the Name attribute value instead?
> q3 - if this is expected behavior is this something that has not previously 
> had a bug filed against it to get fixed in some post wix3 official beta 
> 3.0.4805.0 release since having iis:WebSite look for existing install of the 
> site using just the Name attribute value presents a much more powerful story 
> in terms of service deliverable msi's where you have to be able to install 
> against cases where the only unique website thing you can know, want to have 
> to know, at development time is the Name.
>
> 
> 
> 
> 
>
>  KeyPath="yes" Permanent="yes">
> Identity="networkService&

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name attribute value versus port settings?

[Robert O'Brien]

Thanks this helps.  Currently Kiran is testing this out to see if it provides 
the iis:WebSite behavior outlined below that we are looking for.   

Is there an current lkg build newer than the public wix 3 beta1 release 4805 
that folks can switch to in order to ensure they have all the latest and 
greatest fixes that have gone in since 4805 but still be on a known to be good 
install?

 
-Original Message-
From: Thomas S. Trias [mailto:tomtr...@artizan.com] 
Sent: Wednesday, April 08, 2009 11:20 AM
To: General discussion for Windows Installer XML toolset.
Cc: Dmitry Frenkel
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name attribute value versus port settings?

Robert,

Add  SiteId="*" as an attribute to iis:WebSite.

SiteId  String  Optional attribute to directly specify the site id of 
the WebSite. Use this to ensure all web sites in a web garden get the 
same site id. If a number is provided, the site id must be unique on all 
target machines. If "*" is used, the Description attribute will be 
hashed to create a unique value for the site id. This value must be a 
positive number or a "*" or a formatted value that resolves to "-1" (for 
the same behavior as "*") or a positive number or blank. If this 
attribute is absent then the web site will be located using the 
WebAddress element associated with the web site.


Thanks,

Thomas S. Trias
Senior Developer
Artizan Internet Services
http://www.artizan.com/


 Original Message  
Subject: [WiX-users] is it a bug that iis:WebSite doesn't locate 
presence ofexisting website using just the Name attribute value 
versus portsettings?
From: Robert O'Brien 
To: 'wix-users@lists.sourceforge.net' 
Cc: Dmitry Frenkel 
Date: 4/7/2009 7:14 PM
> We have a service deliverable msi where optionally have some w08/iis70 
> "Default Web Site" vdir settings we want to apply and some "Site1 Web Site" 
> and "Site2 Web Site" settings we want to apply (see relevant excerpt below).  
>  We need to allow for deployments where "Site1 Web Site" and "Site2 Web Site" 
> already exist as a result of OPS having set them up in advance.   This is to 
> enable scenarios where all web sites are advertised on tcp/80 and tcp/443 and 
> OPS uses environment specific IP or host header name settings to 
> differentiate incoming requests.In our installer we won't know what those 
> environment specific IP or host header name settings are.
>
> What we are finding  is that the iis:WebSite extension uses iis:WebAddress 
> port settings to determine if the site is already present.   So in cases 
> where all three iis:WebSite details in our code of iis:WebAddress portEUR 
> defined, and no other unique setting such as ip or host header, they always 
> end up latching onto and modifying the "Default Web Site".
>
> q1 - is this expected behavior for the iis:WebSite extension?
> q2 - if this is expected behavior is there some way to work around this so 
> that we can get it looking for an existing install of the iis:WebSite using 
> just the Name attribute value instead?
> q3 - if this is expected behavior is this something that has not previously 
> had a bug filed against it to get fixed in some post wix3 official beta 
> 3.0.4805.0 release since having iis:WebSite look for existing install of the 
> site using just the Name attribute value presents a much more powerful story 
> in terms of service deliverable msi's where you have to be able to install 
> against cases where the only unique website thing you can know, want to have 
> to know, at development time is the Name.
>
> 
> 
> 
> 
>
>  KeyPath="yes" Permanent="yes">
> Identity="networkService" />
> 
>  Permanent="yes">
> Source="Resources\InstalledComponent.txt" KeyPath="yes" />
>
> Directory="Site1Dir">
> WebAppPool="Site1AppPool" Isolation="medium" />
>
>
>
> 
>
>  KeyPath="yes" Permanent="yes">
> Identity="networkService" />
> 
>  Permanent="yes">
> Source="Resources\InstalledComponent.txt" KeyPath="yes" />
>
> Directory="Site2Dir">
> WebAppPool="Site2AppPool" Isolation="medium" />
>
>
>
> 
> 
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Compose

Re: [WiX-users] is setting sql:Database ConfirmOverwrite="no" expected cause the db not being created if it already exists?

[Robert O'Brien]

Umm so in an msiexec /qb processing case this attribute becomes an assume user 
said no to overwrite? 

That's what we are experiencing which fortunately for us is the exact behavior 
we want from this attribute or one like it, i.e. in unattended mode if db is 
found to already exists don't recreate it.   This thread was really to try and 
get clarification on that.

-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com] 
Sent: Monday, February 09, 2009 9:30 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] is setting sql:Database ConfirmOverwrite="no" expected 
cause the db not being created if it already exists?

No. It removes the prompt when an overwrite will occur.

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com] 
Sent: Monday, February 09, 2009 08:39
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] is setting sql:Database ConfirmOverwrite="no" expected 
cause the db not being created if it already exists?

is setting sql:Database ConfirmOverwrite="no" expected cause the db not being 
created if it already exists?
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] is customaction impersonate attribute default when attribute is not specified "yes" or "no" . . . the current chm details does not say which

[Robert O'Brien]

Done.  2742593 "update docs to more specific wrt default impersonate value"

-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com] 
Sent: Friday, January 30, 2009 12:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] is customaction impersonate attribute default when 
attribute is not specified "yes" or "no" . . . the current chm details does not 
say which

That's a good point. In most cases, the default is "absent" == "no". Except in 
this case.  

The hint is here: "Typically the value should be 'yes', except when the custom 
action needs elevated privileges to apply changes to the machine."

Be great if you could open a documentation bug to suggest that this be more 
specific.

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com]
Sent: Friday, January 30, 2009 11:47
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] is customaction impersonate attribute default when 
attribute is not specified "yes" or "no" . . . the current chm details does not 
say which

is customaction impersonate attribute default when attribute is not specified 
"yes" or "no"  . . . the current chm details does not say which
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] using torch.exe -ax to enable use of admin install msi target and update input parameter values

[Robert O'Brien]

Was probably using wix 3.0.4004.0 back when this thread was sent.
 
-Original Message-
From: Heath Stewart [mailto:clubs...@gmail.com] 
Sent: Friday, April 03, 2009 12:07 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] using torch.exe -ax to enable use of admin install msi 
target and update input parameter values

What version of WiX v3 are you using. A while back I made a change to
support the actual database schema so if your MSIs don't match the schema
WiX expects it shouldn't be a problem. Now, if your target and upgrade
database schemas different the error is there because Windows Installer will
fail to install such a patch and it's really hard to diagnose. Rather than
failing with an error message stating something like, "The transform is
invalid", the database will be garbled within the transform and the failure
code could be almost anything depending on what data is garbled and when
it's used.

Transforms - and by extension patches, since they just contain a bunch of
transforms - cannot change the database schemas except to add a new column
or a new table. See
https://blogs.msdn.com/heaths/archive/2007/09/01/column-types-cannot-be-changed-in-a-patch-or-transform.aspxfor
more information.

On Sun, Sep 14, 2008 at 1:28 PM, Robert O'Brien  wrote:

> Thanks that appears to be exactly what my issue was with my adminInstall
> output.  I used orca to reconfigure the feature level settings in my v1.0
> msi so I could generate a useable adminInstall of it and configured my in
> progress v1.1 sources to instead use the following feature install condition
> logic so its build output will directly support generation of a useable
> adminInstall.
>
>DATABASES=0
> versus what I had
>
>DATABASES=1
>
> At this point using new wix3 way for patch generation is spitting out the
> following torch.exe processing command error.   If I switch to the old
> msimsp way for patch generation it doesn't seem to have that same issue.  I
> even tried rebuilding my v1.0 msi output using the same wix framework
> release as I'm using for my v1.1 work and it didn't make the torch.exe
> RadioButton error go away.
>
> Error   2   The table definition of 'RadioButton' in the target
> database does not match the table definition in the updated database. A
> transform requires that the target database schema match the updated
> database schema.   D:\tfswf\ws0\RXD_RXG_PTF\RXP
> Eventing\Main\Setup\Patch\obj\Debug\v1.0adminInstall\RP Event Notification
> Service.msi 0   1   Patch
>
> 
> Manufacturer="!(loc.ProductName)" MoreInfoURL="!(loc.ProductUrl)"
> Classification="Update" DisplayName="!(loc.ProductName)">
>
>
>
>
>
>
>
>
>
> Supersede="yes">
>
>
>
>
> Patch.wixproj | postBuild event
> move /y "$(TargetDir)en-us\$(TargetName).msi"
> "$(ProjectDir)obj\$(Configuration)\$(TargetName).wixmsp"
> robocopy "\\rpbuildagent03\builds\RXP Eventing\v1.0adminInstallAlt"
> "$(ProjectDir)obj\$(Configuration)\v1.0adminInstallAlt" /mir /r:0
> if not exist "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" md
> "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall"
> rem msiexec.exe /a "$(Setup.TargetDir)en-us\$(Setup.TargetFileName)" /qn
> TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l*
> "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification
> Service.log"
> if "$(IsDesktopBuild)" == "" msiexec.exe /a
> "$(SolutionDir)Setup\Setup\bin\$(Configuration)\en-us\RP Event Notification
> Service.msi" /qn
> TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l*
> "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification
> Service.log"
> if "$(IsDesktopBuild)" == "false" msiexec.exe /a "$(OutDir)en-us\RP Event
> Notification Service.msi" /qn
> TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l*
> "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification
> Service.log"
> "$(MSBuildExtensionsPath)\..\Windows Installer XML v3\bin\torch.exe" -p -ax
> "$(ProjectDir)obj\$(Configuration)\extractedAdminInstallBinaries"
> "$(ProjectDir)obj\$(Configuration)\v1.0adminInstall\RP Event Notification
> Service.msi" "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event
> Notification Service.msi" -out
> "$(ProjectDir)obj\$(Configuration)\$(TargetName).

[WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name attribute value versus port settings?

[Robert O'Brien]

We have a service deliverable msi where optionally have some w08/iis70 "Default 
Web Site" vdir settings we want to apply and some "Site1 Web Site" and "Site2 
Web Site" settings we want to apply (see relevant excerpt below).   We need to 
allow for deployments where "Site1 Web Site" and "Site2 Web Site" already exist 
as a result of OPS having set them up in advance.   This is to enable scenarios 
where all web sites are advertised on tcp/80 and tcp/443 and OPS uses 
environment specific IP or host header name settings to differentiate incoming 
requests.In our installer we won't know what those environment specific IP 
or host header name settings are.

What we are finding  is that the iis:WebSite extension uses iis:WebAddress port 
settings to determine if the site is already present.   So in cases where all 
three iis:WebSite details in our code of iis:WebAddress port=80 defined, and no 
other unique setting such as ip or host header, they always end up latching 
onto and modifying the "Default Web Site".

q1 - is this expected behavior for the iis:WebSite extension?
q2 - if this is expected behavior is there some way to work around this so that 
we can get it looking for an existing install of the iis:WebSite using just the 
Name attribute value instead?
q3 - if this is expected behavior is this something that has not previously had 
a bug filed against it to get fixed in some post wix3 official beta 3.0.4805.0 
release since having iis:WebSite look for existing install of the site using 
just the Name attribute value presents a much more powerful story in terms of 
service deliverable msi's where you have to be able to install against cases 
where the only unique website thing you can know, want to have to know, at 
development time is the Name.







   


   
   
   
   
   
   
   



   


   
   
   
   
   
   
   

Asdf

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] We are getting some unexpected and undesirable behavior from iis:WebAppPool and iis:WebSite extensions, just checking to see if we are doing something wrong.

[Robert O'Brien]

Thanks for responses.   

1.  setting the SKIPCONFIGUREIIS property via an immediate CA (scheduled prior 
to ConfigureIIs of course) to simply skip IIS configuration when the target 
host already has the website installed would require us having some way to 
determine if the target host already has the website installed wouldn't it?  Is 
there some wix syntax supporting that check?  Also wouldn't doing this actually 
cause not only our AppPool and WebSite settings from not being applied but also 
all of our iis:WebVirtualDir and iis:WebApplication settings that we do want to 
recreate every time as we do remove those components during uninstall.
 
2.  the addition of the ConfigureIfExists="no" option to our iis:WebSite 
element sounds promising since it sounds like it may prevent the activity that 
is traversing any of the child vdirs that someone may have added to the 
website, outside of what our installer creates, and resetting their appPool 
setting to whatever is defined for the iis:WebSite.  Presumably setting this 
iis:WebSite attribute doesn't preclude processing of our iis:WebVirtualDir and 
iis:WebApplication settings that we do want to recreate every time as we do 
remove those components during uninstall.

-Original Message-
From: Rob Mensching [mailto:r...@wixtoolset.org] 
Sent: Thursday, April 02, 2009 10:46 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] We are getting some unexpected and undesirable 
behavior from iis:WebAppPool and iis:WebSite extensions, just checking to see 
if we are doing something wrong.

Also, WebSite has a ConfigureIfExists property. AppPool though probably 
always sets its settings so Alex's suggestion below may be the nuke you 
need.

Alex Cater wrote:
> The condition for ConfigureIIs (the scheduling CA) is:
>
> NOT SKIPCONFIGUREIIS AND VersionNT > 400
>
> You could set the SKIPCONFIGUREIIS property via an immediate CA (scheduled 
> prior to ConfigureIIs of course) to simply skip IIS configuration when the 
> target host already has the website installed.
>
>
> --
> View this message in context: 
> http://n2.nabble.com/We-are-getting-some-unexpected-and-undesirable-behavior-from-iis%3AWebAppPool-and-iis%3AWebSite-extensions%2C-just-checking-to-see-if-we-are-doing-something-wrong.-tp2577603p2578018.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>   

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] We are getting some unexpected and undesirable behavior from iis:WebAppPool and iis:WebSite extensions, just checking to see if we are doing something wrong.

[Robert O'Brien]

We are getting some unexpected and undesirable behavior from iis:WebAppPool and 
iis:WebSite extensions, just checking to see if we are doing something wrong.

background
Specifically we have the following relevant snippet of wix that defines our 
appPool setting and the WebSite we want created to use it.Everything works 
as expected when installing against a box where none of this is present.   We 
do not remove the appPool and the WebSite on uninstall because we don't want 
ops to have to redo ssl binding certificate associates and other environment 
specific stuff after each uninstall / reinstall of a new build.

What we are finding is installing against a host where the appPool and website 
is already in place appears to reapply the appPool setting.   Specifically if 
some non-deliverable specific vdir application has been manually created under 
the website and granted an appPool setting other than our deliverable specific 
appPool then when we reinstall that vdir application ends up getting its 
appPool changed.   Similarly if ops has changed the appPool we provisioned on 
first installer pass to use a different identity when we reinstall it gets set 
back to the identity defined in our wix.

question
is this behavior expected and is there any way we can leave appPool and website 
in place after first install attempt and not have an custom tweaks made by ops 
reverted during subsequent installer passes?




























--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] any insights as to why sql extension commands containing public property references are not working

[Robert O'Brien]

Ok.  I just submitted the following wix feature request which hopefully 
outlines clearly what we are seeing and what we would prefer to see.

https://sourceforge.net/tracker/index.php?func=detail&aid=2655321&group_id=105970&atid=642717

Subject = support defining multiple sql:String sequence attributes

Description = 
For sql:String statements currently what we find is that you must define just 
one attribute setting specifying the installer sequence you want it to be 
applicable for, e.g. 
  ExecuteOnInstall="yes" or RollbackOnUninstall="yes" or 
ExecuteOnUninstall="yes" or RollbackOnInstall="yes"

What we find if you define more that one sql:String statement attribute setting 
specifying the installer sequence you want it to be applicable for then only 
the last attribute setting gets used, e.g.
  ExecuteOnInstall="yes" RollbackOnUninstall="yes" only executes the specified 
sql:String during RollbackOnUninstall
  ExecuteOnUninstall="yes" RollbackOnInstall="yes" only executes the specified 
sql:String during RollbackOnInstall

This can be confusing to the wix developer many might expect, since it 
compiles, to be able to define more that one sql:String statement attribute 
setting specifying the installer sequence you want it to be applicable for.

What we would prefer is that you can define multiple sql:String statement 
attribute settings specifying the installer sequence you want it to be 
applicable for and have them all get used because it is common to want whatever 
sql:String statement that is used during install to also be executed during 
rollback of an uninstall.  Likewise it is common to want whatever sql:String 
statement that is used during uninstall to also be executed during rollback of 
an install, e.g. 
  ExecuteOnInstall="yes" RollbackOnUninstall="yes" executes the specified 
sql:String during Install and Rollback of Uninstall
  ExecuteOnUninstall="yes" RollbackOnInstall="yes" executes the specified 
sql:String during Uninstall and Rollback of Install


-Original Message-
From: Rob Mensching [mailto:r...@wixtoolset.org] 
Sent: Tuesday, February 24, 2009 10:17 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] any insights as to why sql extension commands 
containing public property references are not working

What you are seeing is a limitation in the code. I'm not sure that there 
is a real requirement behind the limitation but the code does expect 
things to behave the way you list. If you think it should be different, 
feel free to file a feature request with a clear statement of what you 
see and what you would prefer.

Robert O'Brien wrote:
> I agree getting the exec wrapped statements correct, required so we could 
> incorporate use of installer public properties in the sql statements, 
> required a couple of passes.
>
> What we've found in testing of this build output is that everything worked 
> once I limited the sql:String statements to having just 
> ExecuteOnInstall="yes" in the one and just ExecuteOnUninstall="yes" in the 
> other, vs ExecuteOnInstall="yes" RollbackOnUninstall="yes" in the one and 
> ExecuteOnUninstall="yes" RollbackOnInstall="yes"in the other.
>
> So now it seems that if I want to cover RollbackOnUninstall and 
> RollbackOnInstall cases I'll have to add additional duplicate sql:String 
> statements for those cases vs being able to make single statements be dual 
> role statements like we were originally trying to make work.  Is that how 
> things are intended to work or might this be a sql:String statement 
> processing bug?
>
> -Original Message-
> From: Michael Osmond [mailto:mosm...@baytech.com.au]
> Sent: Wednesday, February 11, 2009 2:29 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] any insights as to why sql extension commands 
> containing public property references are not working
>
> Robert,
>
> Just one observation, are you sure that the difference in between using
> create (in the exampel that works) and wrapping the create inside an
> exec command (in the example that fails) is not the problem.  Both look
> okay to me, but I have had fun in the past with getting exec('strings')
> to do what I wanted.
>
> Michael
>
> -Original Message-
> From: Robert O'Brien [mailto:robert.obr...@microsoft.com]
> Sent: Thursday, 12 February 2009 5:48 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] any insights as to why sql extension commands
> containing public property references are not working
>
> p.s.   looking at my verbose logs searching for "Execu

[WiX-users] Can I expect that a ServiceControl entry without the Remove attribute specified just handles start/stop behavior of an existing service . . .

[Robert O'Brien]

Can I expect that a  
entry without the Remove attribute specified just handles start/stop behavior 
of an existing service and does not try and remove and/or install it?
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] can I expect that a entry without the Remove attribte specified just handles start/stop behavior of an existing service and does not try and install and/or remove it

[Robert O'Brien]

can I expect that a  
entry without the Remove attribte specified just handles start/stop behavior of 
an existing service and does not try and install and/or remove it?

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] is there a way to get a dll.config file deployed along side a gac destined file, e.g. a entry with Assembly=".net" defined?

[Robert O'Brien]

Our service deliverable msi is installing a biztalk 2009 application.  As is 
the case with all things bts everything it uses needs to get deployed to the 
gac.   

One of those bts resource dll's makes use of the vs08 settings designer/api for 
externally exposing runtime settings you want to be able to tweak w/o having to 
rebuild, i.e. 
settings designer ==  | properties | Settings | 
Settings.Default.MySettingsDesignerCreatedAndMaintainedRunTimeValue = 12345
settings api == .cs | int 
someExternallyConfigurableRuntimeSetting = 
Settings.Default.MySettingsDesignerCreatedAndMaintainedRunTimeValue;

For that gac deployed dll to have its settings api calls able to retrieve the 
dll.config stored runtime settings the dll.config has to be placed in the same 
directory as the dll.

I tried the following two options and the first doesn't work because it seems 
the file copy to the gac of the dll.config gets cleared when 
MsiPublishAssemblies processing of the Assembly=".net" dll file setting is 
processed.  I tried the second option I could think of which was to add the 
custom action sequenced to happen after MsiPublishAssemblies and even though 
the verbose logs show it successfully copying the dll.config to the right path 
it is not there after setup competes.   Not sure what process is deleting that 
file copy.   I can copy the custom action statement out of the verbose log and 
run it after setup completes and it does what I'd expect.  Any thoughts on why 
that's happening and more importantly how I can get this dll.config file 
deployed along side its parent gac deployed dll as part of my wix sources would 
be very much appreciated.


 














 


!Sdk1=2 And 
&Sdk1=3 And ?Sdk1Gac14=2 And $Sdk1Gac14=3
!Sdk1=2 And 
&Sdk1=3 And ?Sdk1Gac14=2 And $Sdk1Gac14=3


-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com] 
Sent: Friday, February 27, 2009 10:11 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] is there a way to get a dll.config file deployed along 
side a gac destined file, e.g. a  entry with Assembly=".net" defined?

I don't believe there is any supported way, WiX or otherwise, to put a
config file in the GAC. I am curious why you would want to?

Neil

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com] 
Sent: 27 February 2009 17:15
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] is there a way to get a dll.config file deployed
along side a gac destined file, e.g. a  entry with
Assembly=".net" defined?

is there a way to get a dll.config file deployed along side a gac
destined file, e.g. a  entry with Assembly=".net" defined?

--
Open Source Business Conference (OSBC), March 24-25, 2009, San
Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the
Enterprise
-Strategies to boost innovation and cut costs with open source
participation
-Receive a $600 discount off the registration fee with the source code:
SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] is there a way to get a dll.config file deployed along side a gac destined file, e.g. a entry with Assembly=".net" defined?

[Robert O'Brien]

is there a way to get a dll.config file deployed along side a gac destined 
file, e.g. a  entry with Assembly=".net" defined?
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] any insights as to why sql extension commands containing public property references are not working

[Robert O'Brien]

I agree getting the exec wrapped statements correct, required so we could 
incorporate use of installer public properties in the sql statements, required 
a couple of passes.

What we've found in testing of this build output is that everything worked once 
I limited the sql:String statements to having just ExecuteOnInstall="yes" in 
the one and just ExecuteOnUninstall="yes" in the other, vs 
ExecuteOnInstall="yes" RollbackOnUninstall="yes" in the one and 
ExecuteOnUninstall="yes" RollbackOnInstall="yes"in the other.   

So now it seems that if I want to cover RollbackOnUninstall and 
RollbackOnInstall cases I'll have to add additional duplicate sql:String 
statements for those cases vs being able to make single statements be dual role 
statements like we were originally trying to make work.  Is that how things are 
intended to work or might this be a sql:String statement processing bug?
 
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au] 
Sent: Wednesday, February 11, 2009 2:29 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] any insights as to why sql extension commands 
containing public property references are not working

Robert,

Just one observation, are you sure that the difference in between using
create (in the exampel that works) and wrapping the create inside an
exec command (in the example that fails) is not the problem.  Both look
okay to me, but I have had fun in the past with getting exec('strings')
to do what I wanted.  

Michael

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com] 
Sent: Thursday, 12 February 2009 5:48 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] any insights as to why sql extension commands
containing public property references are not working

p.s.   looking at my verbose logs searching for "ExecuteSqlStrings" hits
I only see "RollbackExecuteSqlStrings" hits containing both the sql
login and db user settings I want applied during install ( and during
component uninstall rollbacks) as well as the settings I want applied
during uninstall ( and during component install rollbacks ).


q1 - is having the sql:String attribute pair ExecuteOnInstall="yes"
RollbackOnUninstall="yes" correct to control having the specific setting
applied during installs and also during component uninstall rollbacks?

q2 - is having the sql:String attribute pair ExecuteOnUninstall="yes"
RollbackOnInstall="yes" correct to control having the specific setting
applied during uninstalls and also during component install rollbacks?

From: Robert O'Brien
Sent: Wednesday, February 11, 2009 11:28 AM
To: General discussion for Windows Installer XML toolset.
Subject: any insights as to why sql extension commands containing public
property references are not working

Any insights as to why the following sql extensions commands that create
a sql login and db user setting work













but the following similar sql extensions calls where I have the sql
login and db user statements making use of a public property value + the
statements configured to also execute on uninstall rollback, do not
work?













/eom


--
Create and Deploy Rich Internet Apps outside the browser with
Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use
existing skills and code to build responsive, highly engaging
applications that combine the power of local resources and data with the
reach of the web. Download the Adobe AIR SDK and Ajax docs to start
building applications today-http://p.sf.net/sfu/adobe-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with

[WiX-users] Any pointers on the syntax i should one use to enable deployment of a gac dll required dll.config file, e.g. gac dll's that make use of the setting designer/api runtime settings?

[Robert O'Brien]

Any pointers on the syntax i should one use to enable deployment of a gac dll 
required dll.config file, e.g. gac dll's that make use of the setting 
designer/api runtime settings?

I tried the following two options and the first doesn't work because it seems 
the file copy to the gac of the dll.config gets cleared when 
MsiPublishAssemblies processing of the Assembly=".net" dll file setting is 
processed.   I tried adding the custom action sequenced to happen after 
MsiPublishAssemblies and even though the verbose logs show it successfully 
copying the dll.config to the right path it is not there after setup competes.  
 Not sure what process is deleting that file copy.   I can copy the custom 
action statement out of the verbose log and run it after setup completes and it 
does what I'd expect.   Any thoughts on why that's happening and more 
importantly how I can get this dll.config file deployed along side its parent 
gac deployed dll as part of my wix sources would be very much appreciated.


 

















!Sdk1=2 And 
&Sdk1=3 And ?Sdk1Gac14=2 And $Sdk1Gac14=3
!Sdk1=2 And 
&Sdk1=3 And ?Sdk1Gac14=2 And $Sdk1Gac14=3



--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] any pointers on the syntax i should one use to enable deployment of a gac dll required dll.config file, e.g. gac dll's that make use if setting designer/api runtime settings?

[Robert O'Brien]

I tried adding the following custom action sequenced to happen after 
MsiPublishAssemblies and even though the verbose logs show it completing 
successfully the dll.config is not there after setup competes.   Any thoughts 
on why that is happening and how I get this required dll.config file placed in 
the gac folder along side its parent dll?




!Sdk1=2 And 
&Sdk1=3 And ?Sdk1Gac14=2 And $Sdk1Gac14=3
!Sdk1=2 And 
&Sdk1=3 And ?Sdk1Gac14=2 And $Sdk1Gac14=3

From: Robert O'Brien
Sent: Thursday, February 19, 2009 9:13 AM
To: 'wix-users@lists.sourceforge.net'
Subject: any pointers on the syntax i should one use to enable deployment of a 
gac dll required dll.config file, e.g. gac dll's that make use if setting 
designer/api runtime settings?

Any pointers on the syntax i should one use to enable deployment of a gac dll 
required dll.config file, e.g. gac dll's that make use if setting designer/api 
runtime settings?

I tried the following two options and the first, currently commented out, 
doesn't work because it doesn't drop the file in the actual gac folder, the 
second doesn't work because it seems the gac placement processing deletes it 
when the Assembly=".net" dll file setting is processed.


 
 















--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] any pointers on the syntax i should one use to enable deployment of a gac dll required dll.config file, e.g. gac dll's that make use if setting designer/api runtime settings?

[Robert O'Brien]

Any pointers on the syntax i should one use to enable deployment of a gac dll 
required dll.config file, e.g. gac dll's that make use if setting designer/api 
runtime settings?

I tried the following two options and the first, currently commented out, 
doesn't work because it doesn't drop the file in the actual gac folder, the 
second doesn't work because it seems the gac placement processing deletes it 
when the Assembly=".net" dll file setting is processed.


 
 















--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] any pointers on the syntax i should one use to enable deployment of a gac dll required dll.config file, e.g. gac dll's that make use if setting designer/api runtime settings?

[Robert O'Brien]

any pointers on the syntax i should one use to enable deployment of a gac dll 
required dll.config file, e.g. gac dll's that make use if setting designer/api 
runtime settings?

I tried the following two options and the first, currently commented out, 
doesn't work because it doesn't drop the file in the actual gac folder, the 
second doesn't work because it seems the gac placement processing deletes it 
when the Assembly=".net" dll file setting is processed.

 


 














--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] i need util:XmlFile associated SchedXmlFile action to happen before a specific CAQuietExec deferred custom action . . .

[Robert O'Brien]

i need util:XmlFile associated SchedXmlFile action to happen before a specific 
CAQuietExec deferred custom action .

Would using the following sequence entry for SchedXmlFile be the correct / 
supported way to make that happen?

!Database1=2 And 
&Database1=3 And ?Database1=2 And $Database1=3

!Database1=2 And 
&Database1=3 And ?Database1=2 And $Database1=3
!Database1=2 And 
&Database1=3 And ?Database1=2 And $Database1=3


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] i need util:XmlFile associated SchedXmlFile action to happen before a specific CAQuietExec deferred custom action . . .

[Robert O'Brien]

Would !Database1=2 And 
&Database1=3 And ?Database1=2 And $Database1=3

!Database1=2 And 
&Database1=3 And ?Database1=2 And $Database1=3
!Database1=2 And 
&Database1=3 And ?Database1=2 And $Database1=3


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] any insights as to why sql extension commands containing public property references are not working

[Robert O'Brien]

p.s.   looking at my verbose logs searching for "ExecuteSqlStrings" hits I only 
see "RollbackExecuteSqlStrings" hits containing both the sql login and db user 
settings I want applied during install ( and during component uninstall 
rollbacks) as well as the settings I want applied during uninstall ( and during 
component install rollbacks ).


q1 - is having the sql:String attribute pair ExecuteOnInstall="yes" 
RollbackOnUninstall="yes" correct to control having the specific setting 
applied during installs and also during component uninstall rollbacks?

q2 - is having the sql:String attribute pair ExecuteOnUninstall="yes" 
RollbackOnInstall="yes" correct to control having the specific setting applied 
during uninstalls and also during component install rollbacks?

From: Robert O'Brien
Sent: Wednesday, February 11, 2009 11:28 AM
To: General discussion for Windows Installer XML toolset.
Subject: any insights as to why sql extension commands containing public 
property references are not working

Any insights as to why the following sql extensions commands that create a sql 
login and db user setting work













but the following similar sql extensions calls where I have the sql login and 
db user statements making use of a public property value + the statements 
configured to also execute on uninstall rollback, do not work?













/eom

--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] any insights as to why sql extension commands containing public property references are not working

[Robert O'Brien]

p.s.   looking at my verbose logs searching for "ExecuteSqlStrings" hits I only 
see "RollbackExecuteSqlStrings" hits containing both the sql login and db user 
settings I want applied during install ( and during component uninstall 
rollbacks) as well as the settings I want applied during uninstall ( and during 
component install rollbacks ).


q1 - is having the sql:String attribute pair ExecuteOnInstall="yes" 
RollbackOnUninstall="yes" correct to control having the specific setting 
applied during installs and also during component uninstall rollbacks?

q2 - is having the sql:String attribute pair ExecuteOnUninstall="yes" 
RollbackOnInstall="yes" correct to control having the specific setting applied 
during uninstalls and also during component install rollbacks?

From: Robert O'Brien
Sent: Wednesday, February 11, 2009 11:28 AM
To: General discussion for Windows Installer XML toolset.
Subject: any insights as to why sql extension commands containing public 
property references are not working

Any insights as to why the following sql extensions commands that create a sql 
login and db user setting work













but the following similar sql extensions calls where I have the sql login and 
db user statements making use of a public property value + the statements 
configured to also execute on uninstall rollback, do not work?













/eom

--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] any insights as to why sql extension commands containing public property references are not working

[Robert O'Brien]

Any insights as to why the following sql extensions commands that create a sql 
login and db user setting work













but the following similar sql extensions calls where I have the sql login and 
db user statements making use of a public property value + the statements 
configured to also execute on uninstall rollback, do not work?













/eom

--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] is setting sql:Database ConfirmOverwrite="no" expected cause the db not being created if it already exists?

[Robert O'Brien]

is setting sql:Database ConfirmOverwrite="no" expected cause the db not being 
created if it already exists?
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] is customaction impersonate attribute default when attribute is not specified "yes" or "no" . . . the current chm details does not say which

[Robert O'Brien]

is customaction impersonate attribute default when attribute is not specified 
"yes" or "no"  . . . the current chm details does not say which
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] does

[Robert O'Brien]

If a person wanted to create some form of wix support for installed .txt or 
.xml file regular expression search and replace...

q1. What would you gain by taking on the effort of the native code 
implementation work necessary to provide it as a wix extension versus creating 
support for this using a dtf managed custom action?

q2. Is there some wix / msi provided functionality that provide a solution for 
the case where the modified file was not part of the installer deployed files, 
or patch applied change to unpatched release deployed file, where if you could 
easily handle it you would want to be able to revert the wix extension or dtf 
managed custom action modified file back to its state prior to the regular 
expression searchNreplace was applied?

-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Wednesday, December 10, 2008 8:53 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] does mailto:robert.obr...@microsoft.com]
Sent: Tuesday, December 09, 2008 16:37
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] does http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] does

[Robert O'Brien]

I have a bindings.xml file that my wix component deploys that I then need to 
roll through and just do a search and replace of all "localhost" hits before 
this file gets processed by an After="InstallFiles" custom action.

Does http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Announcement: WiX v3.0 beta exit release available

[Robert O'Brien]

So the following sources associated with to enabling msi major upgrade support 
will do major upgrade processing w/o concern for whether or not the "major" 
number has changed in the product major.minor.build.revision number settings?















NEWERVERSIONDETECTED



NEWERVERSIONDETECTED
OLDERVERSIONDETECTED
OLDERVERSIONDETECTED
OLDERVERSIONDETECTED


-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Friday, December 05, 2008 3:39 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Announcement: WiX v3.0 beta exit release available

The WiX MSIs are all doing Major Upgrades.  We're not being careful with the 
MSI name nor the Componentization during day to day development to try to do 
more optimal minor upgrade or patching.  Major upgrades are just easier 
(although less optimal).

-Original Message-----
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Friday, December 05, 2008 08:34
To: 'WiX-users'
Subject: Re: [WiX-users] Announcement: WiX v3.0 beta exit release available

Great news and congratulations on reaching this milestone.

A while back I posted some questions to the forum about how to structure an msi 
to automatically set REINSTALL and REINSTALLMODE property settings to necessary 
values for patch and minor upgrade processing.   There were working solutions 
for the patch msp case but in the case of minor upgrade processing the remark 
was made that you need to build a msi wrapper that launches it with 
REINSTALL=ALL and REINSTALLMODE=vomus versus being able to automatically detect 
minor upgrade scenarios and set those properties automatically within the msi.  
 Well it appears from my installation of the 3.0.4805.0 wix3_x64.msi that there 
is some solution in place allowing you to just run the msi directly and for it 
to determine a minor upgrade is necessary and set the required REINSTALL=ALL 
and REINSTALLMODE= vomus property values so that the minor upgrade processing 
can succeed.   Any tips on how that was accomplished so it can be reused in 
other wix authored msi work?

-Original Message-
From: Bob Arnson [mailto:[EMAIL PROTECTED]
Sent: Friday, December 05, 2008 6:28 AM
To: WiX-users
Subject: [WiX-users] Announcement: WiX v3.0 beta exit release available

The WiX Working Group is pleased to announced that the WiX v3.0 "beta
exit" build (v3.0.4805.0) is now available. We encourage all users to
upgrade to this build for the latest fixes and to verify how ready WiX
v3.0 is for release. For more information, see Rob's announcement
<http://robmensching.com/blog/archive/2008/11/29/WiX-v3-toolset-end-of-the-Beta-imminent.aspx>,
my follow-up
<http://www.joyofsetup.com/2008/11/29/wix-v30-beta-coming-soon/>, and
Highlights of WiX v3.0.4805.0
<http://www.joyofsetup.com/2008/12/05/highlights-of-wix-v3048050/>.


You can download it from http://wix.sourceforge.net/releases/3.0.4805.0/
or from the WiX SourceForge.net releases page
<https://sourceforge.net/project/showfiles.php?group_id=105970&package_id=16&release_id=645083>.
*
*

--
sig://boB
http://joyofsetup.com/

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of 

[WiX-users] looking for some clarification on conditions to use for sequencing activities to cover install | modify add feature | rollback | modify remove feature | uninstall cases

[Robert O'Brien]

Looking for some clarification on conditions to use for sequencing activities 
to cover install | modify add feature | rollback | modify remove feature | 
uninstall cases.

I usually end up having one type of custom actions that are feature or 
component specific and intended to provision things during install | modify add 
feature processing.

I also then end up having another type of custom actions that are feature or 
component specific and intended to un-provision things during rollback | modify 
remove feature | uninstall processing.

So for feature or component related custom actions that have feature or 
component related provisioning / un-provisioning behaviors is it true that 
you'd always want the sequencing conditions to be based on feature or component 
state and action checking, and not the less granular "Install" and "Not 
Installed" condition checks, so that you catch the install | modify add feature 
cases when you want the provisioning to happen and the rollback | modify remove 
feature | uninstall cases when you want the unprovisioning to happen.

For example would it be expected that the following custom action sequence 
conditioning successfully handle install | modify add feature | rollback | 
modify remove feature | uninstall cases?















  
  InstallUtilCmdLine64 And !MainApplication=2 and &MainApplication=3

  
  UnInstallUtilCmdLine64 And !MainApplication=3 and 
&MainApplication=2


Also is it never possible for the "Installed" property to be present/set during 
rollback processing since presumably the product didn't successfully install 
and thus the rollback.  Or is it possible for the for the "Installed" property 
to be present/set during rollback processing the case being when the product 
was already installed and the user used controlpanel programs  modify 
addfeature and the feature addition activities had a failure thus triggering a 
rollback of just that feature addition?

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] is it possible for Installed to be set during rollback processing, e.g. rollback custom actions should always have at least a "Not Installed" not a "Installed" entry in their sequence cond

[Robert O'Brien]

is it possible for Installed to be set during rollback processing, e.g. 
rollback custom actions should always have at least a "Not Installed" not a 
"Installed" entry in their sequence condition?
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Announcement: WiX v3.0 beta exit release available

[Robert O'Brien]

Great news and congratulations on reaching this milestone.

A while back I posted some questions to the forum about how to structure an msi 
to automatically set REINSTALL and REINSTALLMODE property settings to necessary 
values for patch and minor upgrade processing.   There were working solutions 
for the patch msp case but in the case of minor upgrade processing the remark 
was made that you need to build a msi wrapper that launches it with 
REINSTALL=ALL and REINSTALLMODE=vomus versus being able to automatically detect 
minor upgrade scenarios and set those properties automatically within the msi.  
 Well it appears from my installation of the 3.0.4805.0 wix3_x64.msi that there 
is some solution in place allowing you to just run the msi directly and for it 
to determine a minor upgrade is necessary and set the required REINSTALL=ALL 
and REINSTALLMODE= vomus property values so that the minor upgrade processing 
can succeed.   Any tips on how that was accomplished so it can be reused in 
other wix authored msi work?

-Original Message-
From: Bob Arnson [mailto:[EMAIL PROTECTED]
Sent: Friday, December 05, 2008 6:28 AM
To: WiX-users
Subject: [WiX-users] Announcement: WiX v3.0 beta exit release available

The WiX Working Group is pleased to announced that the WiX v3.0 "beta
exit" build (v3.0.4805.0) is now available. We encourage all users to
upgrade to this build for the latest fixes and to verify how ready WiX
v3.0 is for release. For more information, see Rob's announcement
,
my follow-up
, and
Highlights of WiX v3.0.4805.0
.


You can download it from http://wix.sourceforge.net/releases/3.0.4805.0/
or from the WiX SourceForge.net releases page
.
*
*

--
sig://boB
http://joyofsetup.com/

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] prerequisite conditions

[Robert O'Brien]

Thanks.  I tried the following wix xml settings to get LaunchConditions running 
after CostFinalize and it generated the noted compile errors.   I switched to 
use of the CustomAction Error= approach also shown below that you suggested and 
got the desired result.  Question - is the reason for sequencing the execution 
of a customaction in both InstallUISequence And InstallExecuteSequence so that 
you cover both interactive and unattended installs?   In the case of an 
interactive install do the sequenced customactions then end up running twice, 
i.e. once during interactive UI portion of install and then again when user 
selects finish and installer server processing gets carried out?







The CostFinalize element contains an unexpected attribute 'Before'.











!Databases=2 And 
&Databases=3 And Not SQL08DIR

!Services=2 And &Services=3 And Not SSO09DIR And Not 
BTS09DIR



!Databases=2 And 
&Databases=3 And Not SQL08DIR

!Services=2 And &Services=3 And Not SSO09DIR And Not 
BTS09DIR

-Original Message-
From: zett42 [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 04, 2008 10:25 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] prerequisite conditions


http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx
Under "Feature and component state values".

I think it could work if you put LaunchConditions after CostFinalize in the
sequence tables.
Otherwise, you could also use a CustomAction using the "Error" attribute and
you could sequence this after CostFinalize to achieve the same effect.


Robert O'Brien-2 wrote:
>
> Is it expected that prerequisite condition statements support checking
> feature state and action values in order to determine if prerequisite
> should be checked for, e.g. is the following valid given an msi that has a
> Feature named "Databases" and a SQL08DIR property assignment using
> registry search?
>
> 
> Installed Or (!Databases=2 And &Databases=3 And SQL08DIR)
> 
>
> -
> 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
>
>

--
View this message in context: 
http://n2.nabble.com/prerequisite-conditions-tp1614466p1614700.html
Sent from the wix-users mailing list archive at Nabble.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


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] prerequisite conditions

[Robert O'Brien]

Is it expected that prerequisite condition statements support checking feature 
state and action values in order to determine if prerequisite should be checked 
for, e.g. is the following valid given an msi that has a Feature named 
"Databases" and a SQL08DIR property assignment using registry search?


Installed Or (!Databases=2 And &Databases=3 And SQL08DIR)


-
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] is there a canned way for authoring a prerequisite that checks for the presence of another msi installed product, e.g. w/o using registry or directory or file searches?

[Robert O'Brien]

I added the following property assignment using ComponentSearch and 
prerequisite check and the property assignement isn't happening in case where 
prerequisite msi is known to be installed and known to have product id guid 
value specified in componentSearch.   Am I misinterpreting the use of 
ComponentSearch to detect whether or not someother msi owned product is 
installed on a target host?






Installed Or MYPREREQUISITEMSITHATMUSTBEINSTALLED


-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 02, 2008 2:36 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] is there a canned way for authoring a prerequisite 
that checks for the presence of another msi installed product, e.g. w/o using 
registry or directory or file searches?

ComponentSearch.

-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 02, 2008 14:18
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] is there a canned way for authoring a prerequisite that 
checks for the presence of another msi installed product, e.g. w/o using 
registry or directory or file searches?

is there a canned way for authoring a prerequisite that checks for the presence 
of another msi installed product, e.g. w/o using registry or directory or file 
searches?
-
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

[WiX-users] is there a canned way for authoring a prerequisite that checks for the presence of another msi installed product, e.g. w/o using registry or directory or file searches?

[Robert O'Brien]

is there a canned way for authoring a prerequisite that checks for the presence 
of another msi installed product, e.g. w/o using registry or directory or file 
searches?
-
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] any tips on why the following xmlfile machine.config install changes are not working

[Robert O'Brien]

Not sure I'm just using standard issue file | new | wix project template 
generated wixproj to wrap build process with Build Configuration Platform=x64 
enabled.

-Original Message-
From: Rob Mensching
Sent: Monday, December 01, 2008 7:40 PM
To: Robert O'Brien; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Are you setting the platform on the command-line to candle?

-Original Message-----
From: Robert O'Brien
Sent: Monday, December 01, 2008 19:39
To: Rob Mensching; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Bug Filed.

For clarification how come my locally implemented identical registry search 
based property assignment, excerpt from earlier shown here, would be working in 
64-bit installer usage?

   






-Original Message-
From: Rob Mensching
Sent: Monday, December 01, 2008 7:29 PM
To: Robert O'Brien; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

No, the problem is that the RegistrySearch isn't set 64-bit.  So it's always 
searching 32-bit.  That's the bug.  Can you file it?

-Original Message-
From: Robert O'Brien
Sent: Monday, December 01, 2008 19:15
To: Rob Mensching; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

The NetFxExtension.wxs contains the following for assignment of 
NETFRAMEWORK20INSTALLROOTDIR which I would expect to do the right thing for 
Target=X64 build output cases.









Could the issue be that C:\Program Files (x86)\Windows Installer XML 
v3\bin\WixNetFxExtension.dll installed by the Wix3_x64.msi installer was built 
with Target=x86 versus Target=x64?

-Original Message-
From: Rob Mensching
Sent: Monday, December 01, 2008 7:07 PM
To: General discussion for Windows Installer XML toolset.; Robert O'Brien
Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Sounds like a bug in the NETFRAMEWORK20INSTALLROOTDIR not following 64-bit 
correctly.

-----Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2008 16:24
To: Robert O'Brien; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Btw - I was using initially using the following to arrive at my 
NetFramework20ConfigDir setting for use referencing machine.config file.   
registry search result.







In case of $(var.Platform) = "x64" build output the installer was given me a 
systems is was giving me a WixNetFxExtensions property 
NETFRAMEWORK20INSTALLROOTDIR result that was using System\Wow6432Node for the 
installRoot registry key lookup.   Is that expected?

I locally implemented the following and in the local implementation case I get 
the desired non-Software\Wow6432Node result using the exact same registry 
search entry.





    
    
    




-Original Message-
From: Robert O'Brien
Sent: Monday, December 01, 2008 4:17 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Got this to work switching XmlFile entry for install pass to following 
XmlConfig entry.





-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2008 11:39 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Any tips on why the following xmlfile machine.config install changes are not 
working?

I'm using the following component entries:




To try and get this new  element created during install but finding that 
no machine.config changes exist after setup completes.



   
   .
   . .
   . . .
   
   

The verbose logs show the following ExecXmlFile property setting and execution 
of a similarly named custom action
Property(S): ExecXmlFile = 
2EUR0EURC:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.configEUR5EUR0EUR/configuration/system.serviceModel/extensions/behaviorExtensionsEURaddEURname="enableBizTalkHeaderInspector"
 
type="Microsoft.IT.RelationshipManagement.Servic

Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working

[Robert O'Brien]

Bug Filed.

For clarification how come my locally implemented identical registry search 
based property assignment, excerpt from earlier shown here, would be working in 
64-bit installer usage?

   






-Original Message-
From: Rob Mensching
Sent: Monday, December 01, 2008 7:29 PM
To: Robert O'Brien; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

No, the problem is that the RegistrySearch isn't set 64-bit.  So it's always 
searching 32-bit.  That's the bug.  Can you file it?

-Original Message-
From: Robert O'Brien
Sent: Monday, December 01, 2008 19:15
To: Rob Mensching; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

The NetFxExtension.wxs contains the following for assignment of 
NETFRAMEWORK20INSTALLROOTDIR which I would expect to do the right thing for 
Target=X64 build output cases.









Could the issue be that C:\Program Files (x86)\Windows Installer XML 
v3\bin\WixNetFxExtension.dll installed by the Wix3_x64.msi installer was built 
with Target=x86 versus Target=x64?

-Original Message-
From: Rob Mensching
Sent: Monday, December 01, 2008 7:07 PM
To: General discussion for Windows Installer XML toolset.; Robert O'Brien
Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Sounds like a bug in the NETFRAMEWORK20INSTALLROOTDIR not following 64-bit 
correctly.

-----Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2008 16:24
To: Robert O'Brien; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Btw - I was using initially using the following to arrive at my 
NetFramework20ConfigDir setting for use referencing machine.config file.   
registry search result.







In case of $(var.Platform) = "x64" build output the installer was given me a 
systems is was giving me a WixNetFxExtensions property 
NETFRAMEWORK20INSTALLROOTDIR result that was using System\Wow6432Node for the 
installRoot registry key lookup.   Is that expected?

I locally implemented the following and in the local implementation case I get 
the desired non-Software\Wow6432Node result using the exact same registry 
search entry.







        
    



-Original Message-
From: Robert O'Brien
Sent: Monday, December 01, 2008 4:17 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Got this to work switching XmlFile entry for install pass to following 
XmlConfig entry.





-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2008 11:39 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Any tips on why the following xmlfile machine.config install changes are not 
working?

I'm using the following component entries:




To try and get this new  element created during install but finding that 
no machine.config changes exist after setup completes.



   
   .
   . .
   . . .
   
   

The verbose logs show the following ExecXmlFile property setting and execution 
of a similarly named custom action
Property(S): ExecXmlFile = 
2EUR0EURC:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.configEUR5EUR0EUR/configuration/system.serviceModel/extensions/behaviorExtensionsEURaddEURname="enableBizTalkHeaderInspector"
 
type="Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=e2c282dc0883bc94"

-
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] any tips on why the following xmlfile machine.config install changes are not working

[Robert O'Brien]

The NetFxExtension.wxs contains the following for assignment of 
NETFRAMEWORK20INSTALLROOTDIR which I would expect to do the right thing for 
Target=X64 build output cases.









Could the issue be that C:\Program Files (x86)\Windows Installer XML 
v3\bin\WixNetFxExtension.dll installed by the Wix3_x64.msi installer was built 
with Target=x86 versus Target=x64?

-Original Message-
From: Rob Mensching
Sent: Monday, December 01, 2008 7:07 PM
To: General discussion for Windows Installer XML toolset.; Robert O'Brien
Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Sounds like a bug in the NETFRAMEWORK20INSTALLROOTDIR not following 64-bit 
correctly.

-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2008 16:24
To: Robert O'Brien; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Btw - I was using initially using the following to arrive at my 
NetFramework20ConfigDir setting for use referencing machine.config file.   
registry search result.







In case of $(var.Platform) = "x64" build output the installer was given me a 
systems is was giving me a WixNetFxExtensions property 
NETFRAMEWORK20INSTALLROOTDIR result that was using System\Wow6432Node for the 
installRoot registry key lookup.   Is that expected?

I locally implemented the following and in the local implementation case I get 
the desired non-Software\Wow6432Node result using the exact same registry 
search entry.












-Original Message-
From: Robert O'Brien
Sent: Monday, December 01, 2008 4:17 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Got this to work switching XmlFile entry for install pass to following 
XmlConfig entry.





-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2008 11:39 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Any tips on why the following xmlfile machine.config install changes are not 
working?

I'm using the following component entries:




To try and get this new  element created during install but finding that 
no machine.config changes exist after setup completes.



   
   .
   . .
   . . .
   
   

The verbose logs show the following ExecXmlFile property setting and execution 
of a similarly named custom action
Property(S): ExecXmlFile = 
2EUR0EURC:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.configEUR5EUR0EUR/configuration/system.serviceModel/extensions/behaviorExtensionsEURaddEURname="enableBizTalkHeaderInspector"
 
type="Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=e2c282dc0883bc94"

-
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] any tips on why the following xmlfile machine.config install changes are not working

[Robert O'Brien]

Btw - I was using initially using the following to arrive at my 
NetFramework20ConfigDir setting for use referencing machine.config file.   
registry search result.







In case of $(var.Platform) = "x64" build output the installer was given me a 
systems is was giving me a WixNetFxExtensions property 
NETFRAMEWORK20INSTALLROOTDIR result that was using System\Wow6432Node for the 
installRoot registry key lookup.   Is that expected?

I locally implemented the following and in the local implementation case I get 
the desired non-Software\Wow6432Node result using the exact same registry 
search entry.












-Original Message-----
From: Robert O'Brien
Sent: Monday, December 01, 2008 4:17 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Got this to work switching XmlFile entry for install pass to following 
XmlConfig entry.





-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2008 11:39 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Any tips on why the following xmlfile machine.config install changes are not 
working?

I'm using the following component entries:




To try and get this new  element created during install but finding that 
no machine.config changes exist after setup completes.



   
   .
   . .
   . . .
   
   

The verbose logs show the following ExecXmlFile property setting and execution 
of a similarly named custom action
Property(S): ExecXmlFile = 
2EUR0EURC:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.configEUR5EUR0EUR/configuration/system.serviceModel/extensions/behaviorExtensionsEURaddEURname="enableBizTalkHeaderInspector"
 
type="Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=e2c282dc0883bc94"

-
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] any tips on why the following xmlfile machine.config install changes are not working

[Robert O'Brien]

Got this to work switching XmlFile entry for install pass to following 
XmlConfig entry.





-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2008 11:39 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] any tips on why the following xmlfile machine.config 
install changes are not working

Any tips on why the following xmlfile machine.config install changes are not 
working?

I'm using the following component entries:




To try and get this new  element created during install but finding that 
no machine.config changes exist after setup completes.



   
   .
   . .
   . . .
   
   

The verbose logs show the following ExecXmlFile property setting and execution 
of a similarly named custom action
Property(S): ExecXmlFile = 
2EUR0EURC:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.configEUR5EUR0EUR/configuration/system.serviceModel/extensions/behaviorExtensionsEURaddEURname="enableBizTalkHeaderInspector"
 
type="Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=e2c282dc0883bc94"

-
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

[WiX-users] any tips on why the following xmlfile machine.config install changes are not working

[Robert O'Brien]

Any tips on why the following xmlfile machine.config install changes are not 
working?

I'm using the following component entries:




To try and get this new  element created during install but finding that 
no machine.config changes exist after setup completes.



   
   .
   . .
   . . .
   
   

The verbose logs show the following ExecXmlFile property setting and execution 
of a similarly named custom action
Property(S): ExecXmlFile = 
2EUR0EURC:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.configEUR5EUR0EUR/configuration/system.serviceModel/extensions/behaviorExtensionsEURaddEURname="enableBizTalkHeaderInspector"
 
type="Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=e2c282dc0883bc94"

-
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] Is there a strategy for getting rid of ice57 warning in a vdir component with these file, shortcut and webapplication settings you'd typically expect?

[Robert O'Brien]

e.g. is using wixproj | properties | settings | suppress specific ice 
validation = ICE38;ICE43;ICE57 considered acceptable?

-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Friday, November 21, 2008 3:37 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] Is there a strategy for getting rid of ice57 warning in a 
vdir component with these file, shortcut and webapplication settings you'd 
typically expect?

Using the following vdir component setup




















I get the following build ice57 warning which in my case is treated as an error 
due to my wixproj "treat warnings as errors" setting.

  Error 22 ICE57: Component 'Site1Vdir1' has both per-user and per-machine data 
with an HKCU Registry KeyPath.

Is there a strategy for getting rid of ice57 warning in a vdir component with 
these file, shortcut and webapplication settings you'd typically expect?

-
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

[WiX-users] Is there a strategy for getting rid of ice57 warning in a vdir component with these file, shortcut and webapplication settings you'd typically expect?

[Robert O'Brien]

Using the following vdir component setup




















I get the following build ice57 warning which in my case is treated as an error 
due to my wixproj "treat warnings as errors" setting.

  Error 22 ICE57: Component 'Site1Vdir1' has both per-user and per-machine data 
with an HKCU Registry KeyPath.

Is there a strategy for getting rid of ice57 warning in a vdir component with 
these file, shortcut and webapplication settings you'd typically expect?

-
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] what's the custom action name I use to sequence a custom action to process just before/after CreateDatabase activities?

[Robert O'Brien]

Thanks that did the trick.

Using that value and xRefencing with my verbose log output it appears that one 
can try and determine extension related custom action names by searching for 
"Doing action " | "Entrypoint " | "Action start " | "Action ended " hits.

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 20, 2008 1:41 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what's the custom action name I use to sequence a 
custom action to process just before/after CreateDatabase activities?

ConfigureSql is an old name.  New names: InstallSqlData and UninstallSqlData.

-----Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 20, 2008 12:29
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what's the custom action name I use to sequence a 
custom action to process just before/after CreateDatabase activities?

Same compile time result using ConfigureSql.   So looks like 
Before="CreateDatabase" and Before="ConfigureSql" both don't work.   Odd 
because my verbose log say executing action "CreateDatabase" which I would have 
though mean that's the actual name of the custom action.

-Original Message-
From: Chad Miles [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 9:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what's the custom action name I use to sequence a 
custom action to process just before/after CreateDatabase activities?

Try ConfigureSql

On Wed, Nov 19, 2008 at 9:24 PM, Robert O'Brien <[EMAIL PROTECTED]
> wrote:

> I have a custom action that I wanted to schedule to happen just before
> CreateDatase processing occurs.   I tried the following custom action
> sequencing statement
>
> Not
> Installed
>
> and when I compile I get the following error
>
> Error 1 Unresolved reference to symbol
> 'WixAction:InstallExecuteSequence/CreateDatabase' in section
> 'Product:{}'.
>
> Question - what's the custom action name I use to sequence a custom action
> to process just before/after CreateDatabase activities?
> -
> 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


-
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

[WiX-users] is there a source settings that would cause WixUI_FeatureTree to not display features in order that they are defined in the sources?

[Robert O'Brien]

Up until a half hour ago when I started yanking no longer required feature 
condition statements my WixUI_FeatureTree UI experience was displaying features 
in the order that they were defined in the sources, e.g.

e.g. if this was the order I entered my features in my sources this was the 
order that WixUI_FeatureTree would display them in.

 







The above list now being displayed in order except for Databases which is 
getting displayed in last position.  Is there a source settings that would 
cause WixUI_FeatureTree to no longer display features in order that they are 
defined in the sources?
-
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] correct way to enable commadn line support for defining features/subfeatures that are selected and unselected by default when you step into interactive install UI experience

[Robert O'Brien]

I see so the reason for feature conditions that would adjust level from > 0 
enabled to 0 disabled would be something like if you wanted to automatically 
check for a version specific prerequisite and if not present automatically 
disable that feature option.   Do any of the WIXUI_* provided interactive UI 
experiences have a behavior where if feature is set to level = 0 == disabled it 
shows the feature as grayed out versus not showing it at all?

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 20, 2008 3:28 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] correct way to enable commadn line support for 
defining features/subfeatures that are selected and unselected by default when 
you step into interactive install UI experience

Condition on a Feature?  In case you conditionally wanted a Feature to show up 
in the tree or not.

-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 20, 2008 14:36
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] correct way to enable commadn line support for 
defining features/subfeatures that are selected and unselected by default when 
you step into interactive install UI experience

Scratch that question and thanks for the reminder/redirection to the msi 
provided addlocal functionality.  From past experience with other installers I 
recall that addlocal=featureFoo,featureBar sets the feature action choice 
versus my public property approach I've been using to conditionally set the 
level of features from their default of 1 to 0 is effectively 
enabling/disabling the features to arrive at a similar result but probably not 
in a best practices way.

So it sounds like what I really need to be using is msi provided 
addlocal/remove= to enabling command line definable feature 
action choices for both interactive and unattended installer passes.   That 
being the case could you provide a quick comment on what the primary intended 
use case for conditionally setting feature levels to 1=enabled or 0=disabled?

-Original Message-----
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 20, 2008 2:08 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] correct way to enable commadn line support for 
defining features/subfeatures that are selected and unselected by default when 
you step into interactive install UI experience

If Level=0 == feature not displayed and Level=1 == feature displayed and 
/addlocal feature1,feature2 causes feature1 & feature2 to be displayed and 
selected what is the magic feature specific property value that /addlocal is 
controlling in order to define whether a feature is selected or not selected 
when you land on the canned features dialog UI?

Having worked with old way msimsp.exe generated patch stuff on our previously 
deliverable I found that by default I need all my features set to level=1 in my 
wix sources in order for the msimsp.exe old/new msi diff processing to 
function...so now I'm hesitant to have features with default level!=1 in 
sources until we've had a chance to make new way torch.exe generated patch 
stuff work.

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 7:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] correct way to enable commadn line support for 
defining features/subfeatures that are selected and unselected by default when 
you step into interactive install UI experience

MSI also has ways of controlling features using ADDLOCAL and friends.  That 
might work better...

-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 14:05
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] correct way to enable commadn line support for defining 
features/subfeatures that are selected and unselected by default when you step 
into interactive install UI experience

I have the following logic in each of my feature/subfeature settings so that 
from the command line users can easily define what features/subfeatures are 
selected and unselected by default when they step into the interactive install 
or run and unattended install.

When I run my msi in interactive install mode and feed it switches such as 
"my.msi SITES=1 SITE1=1 SITE2=0 /l*v mymsi.log" what I find in the case of the 
 interactive UI experience is that instead of 
Site2 showing up as unselected it is instead removed from the list of 
subfeatures all together.   Am I going about enabling command line support for 
selected and unselected features/subfeatures the wrong way with this approach?


SITES=0

SITE1=0


SITE2=0



--

Re: [WiX-users] correct way to enable commadn line support for defining features/subfeatures that are selected and unselected by default when you step into interactive install UI experience

[Robert O'Brien]

Scratch that question and thanks for the reminder/redirection to the msi 
provided addlocal functionality.  From past experience with other installers I 
recall that addlocal=featureFoo,featureBar sets the feature action choice 
versus my public property approach I've been using to conditionally set the 
level of features from their default of 1 to 0 is effectively 
enabling/disabling the features to arrive at a similar result but probably not 
in a best practices way.

So it sounds like what I really need to be using is msi provided 
addlocal/remove= to enabling command line definable feature 
action choices for both interactive and unattended installer passes.   That 
being the case could you provide a quick comment on what the primary intended 
use case for conditionally setting feature levels to 1=enabled or 0=disabled?

-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 20, 2008 2:08 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] correct way to enable commadn line support for 
defining features/subfeatures that are selected and unselected by default when 
you step into interactive install UI experience

If Level=0 == feature not displayed and Level=1 == feature displayed and 
/addlocal feature1,feature2 causes feature1 & feature2 to be displayed and 
selected what is the magic feature specific property value that /addlocal is 
controlling in order to define whether a feature is selected or not selected 
when you land on the canned features dialog UI?

Having worked with old way msimsp.exe generated patch stuff on our previously 
deliverable I found that by default I need all my features set to level=1 in my 
wix sources in order for the msimsp.exe old/new msi diff processing to 
function...so now I'm hesitant to have features with default level!=1 in 
sources until we've had a chance to make new way torch.exe generated patch 
stuff work.

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 7:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] correct way to enable commadn line support for 
defining features/subfeatures that are selected and unselected by default when 
you step into interactive install UI experience

MSI also has ways of controlling features using ADDLOCAL and friends.  That 
might work better...

-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 14:05
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] correct way to enable commadn line support for defining 
features/subfeatures that are selected and unselected by default when you step 
into interactive install UI experience

I have the following logic in each of my feature/subfeature settings so that 
from the command line users can easily define what features/subfeatures are 
selected and unselected by default when they step into the interactive install 
or run and unattended install.

When I run my msi in interactive install mode and feed it switches such as 
"my.msi SITES=1 SITE1=1 SITE2=0 /l*v mymsi.log" what I find in the case of the 
 interactive UI experience is that instead of 
Site2 showing up as unselected it is instead removed from the list of 
subfeatures all together.   Am I going about enabling command line support for 
selected and unselected features/subfeatures the wrong way with this approach?


SITES=0

SITE1=0


SITE2=0



-
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 Op

Re: [WiX-users] correct way to enable commadn line support for defining features/subfeatures that are selected and unselected by default when you step into interactive install UI experience

[Robert O'Brien]

If Level=0 == feature not displayed and Level=1 == feature displayed and 
/addlocal feature1,feature2 causes feature1 & feature2 to be displayed and 
selected what is the magic feature specific property value that /addlocal is 
controlling in order to define whether a feature is selected or not selected 
when you land on the canned features dialog UI?

Having worked with old way msimsp.exe generated patch stuff on our previously 
deliverable I found that by default I need all my features set to level=1 in my 
wix sources in order for the msimsp.exe old/new msi diff processing to 
function...so now I'm hesitant to have features with default level!=1 in 
sources until we've had a chance to make new way torch.exe generated patch 
stuff work.

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 7:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] correct way to enable commadn line support for 
defining features/subfeatures that are selected and unselected by default when 
you step into interactive install UI experience

MSI also has ways of controlling features using ADDLOCAL and friends.  That 
might work better...

-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 14:05
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] correct way to enable commadn line support for defining 
features/subfeatures that are selected and unselected by default when you step 
into interactive install UI experience

I have the following logic in each of my feature/subfeature settings so that 
from the command line users can easily define what features/subfeatures are 
selected and unselected by default when they step into the interactive install 
or run and unattended install.

When I run my msi in interactive install mode and feed it switches such as 
"my.msi SITES=1 SITE1=1 SITE2=0 /l*v mymsi.log" what I find in the case of the 
 interactive UI experience is that instead of 
Site2 showing up as unselected it is instead removed from the list of 
subfeatures all together.   Am I going about enabling command line support for 
selected and unselected features/subfeatures the wrong way with this approach?


SITES=0

SITE1=0


SITE2=0



-
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] what's the custom action name I use to sequence a custom action to process just before/after CreateDatabase activities?

[Robert O'Brien]

Same compile time result using ConfigureSql.   So looks like 
Before="CreateDatabase" and Before="ConfigureSql" both don't work.   Odd 
because my verbose log say executing action "CreateDatabase" which I would have 
though mean that's the actual name of the custom action.

-Original Message-
From: Chad Miles [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 9:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what's the custom action name I use to sequence a 
custom action to process just before/after CreateDatabase activities?

Try ConfigureSql

On Wed, Nov 19, 2008 at 9:24 PM, Robert O'Brien <[EMAIL PROTECTED]
> wrote:

> I have a custom action that I wanted to schedule to happen just before
> CreateDatase processing occurs.   I tried the following custom action
> sequencing statement
>
> Not
> Installed
>
> and when I compile I get the following error
>
> Error 1 Unresolved reference to symbol
> 'WixAction:InstallExecuteSequence/CreateDatabase' in section
> 'Product:{}'.
>
> Question - what's the custom action name I use to sequence a custom action
> to process just before/after CreateDatabase activities?
> -
> 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

[WiX-users] what's the custom action name I use to sequence a custom action to process just before/after CreateDatabase activities?

[Robert O'Brien]

I have a custom action that I wanted to schedule to happen just before 
CreateDatase processing occurs.   I tried the following custom action 
sequencing statement

Not 
Installed

and when I compile I get the following error

Error 1 Unresolved reference to symbol 
'WixAction:InstallExecuteSequence/CreateDatabase' in section 'Product:{}'.

Question - what's the custom action name I use to sequence a custom action to 
process just before/after CreateDatabase activities?
-
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

[WiX-users] CreateDatabase processing failing because databasehostname public property assignment using [%ComputerName] doesn't appear to be working

[Robert O'Brien]

If I use the following

my log output shows something other than what I'd expect
Property(S): DATABASESHOSTNAME = [%ComputerName]
and my CreateDatabase call that uses the public property DATABASESHOSTNAME fails

If I use the following

my log output shows what you'd expect
Property(S): DATABASESHOSTNAME = localhost
and my CreateDatabase call that uses the public property DATABASESHOSTNAME 
succeeds

Question - Shouldn't the public property assignment using the runtime 
environment syntax above work?
-
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] using a variable for Component Win64 attribute value still generating generic warning not uniquely suppressible in wixproj | build | suppress specific warnings field

[Robert O'Brien]

So basically I no longer need to include the Win64 attribute except in cases 
where the value for a specific component has to be a specific value regardless 
of what the Platform setting is?

-Original Message-
From: Bob Arnson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 18, 2008 10:36 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] using a variable for Component Win64 attribute value 
still generating generic warning not uniquely suppressible in wixproj | build | 
suppress specific warnings field

Robert O'Brien wrote:
> Any insights on how I might still use a $(var.Platform) derived value for the 
> Win64 attribute and also suppress the generic warning generated by every 
> instance where I do this so that my project build doesn't break building when 
> the treat warnings as errors quality assurance project setting is in place.
>

The error comes from the XML editor's Intellisense engine; it isn't an
error from the WiX compiler. However, it's unnecessary; you can have the
compiler supply the default value for the Win64 attribute when the
InstallerPlatform .wixproj property is x64 or ia64/intel64.

--
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

[WiX-users] correct way to enable commadn line support for defining features/subfeatures that are selected and unselected by default when you step into interactive install UI experience

[Robert O'Brien]

I have the following logic in each of my feature/subfeature settings so that 
from the command line users can easily define what features/subfeatures are 
selected and unselected by default when they step into the interactive install 
or run and unattended install.

When I run my msi in interactive install mode and feed it switches such as 
"my.msi SITES=1 SITE1=1 SITE2=0 /l*v mymsi.log" what I find in the case of the 
 interactive UI experience is that instead of 
Site2 showing up as unselected it is instead removed from the list of 
subfeatures all together.   Am I going about enabling command line support for 
selected and unselected features/subfeatures the wrong way with this approach?


SITES=0

SITE1=0


SITE2=0



-
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] what is the recommended way for setting the AppPool associated with a new iis:WebSite?

[Robert O'Brien]

Thanks this helps.  Btw - are there currently any plans to remove the wix3 
requirement for w08/iis7 installs to have the iis6 metabase mgmt compatibility 
features installed in order for  installer activities to do their 
thing?

-Original Message-
From: Amy Rosewater [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 18, 2008 1:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what is the recommended way for setting the AppPool 
associated with a new iis:WebSite?

Hi Robert,

In my wxs for IIS components I have all those elements separate such
that I can choose based on the user selections what components to
install.  Note that if the condition for the
CreateWebsiteWithPortAnonymous component are met, then the
WebApplication is the MainWebApplication (at the top) and my WebAppPool
created by CreateAppPool component is set as the app pool.  Similarly,
if the CreateVirtualDirectoryAnonymous conditions are met, then the
WebApplication is my MainWebApplication.

Hope this helps...

Amy






























-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 18, 2008 2:13 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] what is the recommended way for setting the AppPool
associated with a new iis:WebSite?

what is the recommended way for setting the AppPool associated with a
new iis:WebSite?   Lots of samples on this for the case of an
iis:WebVirtualDir but nothing that made sense in the case of an
iis:WebSite where creating a child iis:WebApplication doesn't make sense
given that's typically a vdir thing in the iis admin UI experience.

-
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

[WiX-users] what is the recommended way for setting the AppPool associated with a new iis:WebSite?

[Robert O'Brien]

what is the recommended way for setting the AppPool associated with a new 
iis:WebSite?   Lots of samples on this for the case of an iis:WebVirtualDir but 
nothing that made sense in the case of an iis:WebSite where creating a child 
iis:WebApplication doesn't make sense given that's typically a vdir thing in 
the iis admin UI experience.
-
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

[WiX-users] the "How To: Generate a GUID" document suggests that wix supports compiling with PUT-GUID-HERE tokens vs actual Guid values or where allowed "*" token autogenerated Guid values defined...b

[Robert O'Brien]

the "How To: Generate a GUID" document (excerpt below) suggests that wix 
supports compiling with PUT-GUID-HERE tokens vs actual Guid values or where 
allowed "*" token autogenerated Guid values defined...but the PUT-GUID-HERE 
tokens case isn't working with the latest install

"All examples in the How To documentation use the text 
PUT-GUID-HERE
 for GUIDs. These samples can be compiled directly by WiX and will have 
temporary, auto-generated GUIDs, inserted. For production purposes you should 
replace each occurrence of 
PUT-GUID-HERE
 with an actual GUID generated using the methods described above."

We are trying to maintain a service deliverable template setup.wixproj and so I 
want to use PUT-GUID-HERE tokens wherever a Guid is required so users of the 
template will ultimately be required to use their own unique guids or where 
allowed "*" token autogenerated Guid values.When I compile with the 
PUT-GUID-HERE tokens in place I get the following compiler error.

"The Product/@Id attribute's value, 'PUT-GUID-HERE', is not a legal Guid value. 
 A Guid needs to be generated and put in place of 'PUT-GUID-HERE' in the source 
file."

Question - am I misinterpreting the documentation or am I using the 
template/sample oriented guid token PUT-GUID-HERE incorrectly?

-
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

[WiX-users] using a variable for Component Win64 attribute value still generating generic warning not uniquely suppressible in wixproj | build | suppress specific warnings field

[Robert O'Brien]

Background
--
A while ago I raised an issue to do with a warning being generated when using a 
variable for the Component Win64 attribute value.   Below you'll see the an 
excerpt of the logic I'm using so that in the case of all managed code 
deliverables I can create one set of wix sources that can produce x64 and x86 
specific build output by just switching the wixproj platform setting.The 
issue I'm running into that was happening before is using a variable for 
Component Win64 attribute value generates a generic warning not uniquely 
suppressible in wixproj | build | suppress specific warnings field.

Question
---
Any insights on how I might still use a $(var.Platform) derived value for the 
Win64 attribute and also suppress the generic warning generated by every 
instance where I do this so that my project build doesn't break building when 
the treat warnings as errors quality assurance project setting is in place.

Warning
---
The 'Win64' attribute is invalid - The value '$(var.Win64)' is invalid 
according to its datatype 'http://schemas.microsoft.com/wix/2006/wi:YesNoType' 
- The '$' character, hexadecimal value 0x24, cannot be included in a name.

Sources
--



















. . .



. . .



/eom
-
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] How to GAC .Net assemblies the correct way?

[Robert O'Brien]

Thanks.  Wix.chm | search "global assembly cache" -> returned one hit for "File 
Element" documentation which did detail use of the Assembly attribute for 
install/remove of managed dlls in %systemroot%\assembly\gac_msil.   So the 
addition of just Assembly and KeyPath to File element as shown here did the 
trick for me.





-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 18, 2008 8:07 AM
To: General discussion for Windows Installer XML toolset.; '[EMAIL PROTECTED]'
Subject: Re: [WiX-users] How to GAC .Net assemblies the correct way?

Yeah, you have to search for "global assembly cache" in the WiX.chm to find it. 
 "GAC" only finds the NativeImage element.  Probably should tweak the 
documentation to catch both.

-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 18, 2008 03:58
To: 'General discussion for Windows Installer XML toolset.'; '[EMAIL PROTECTED]'
Subject: Re: [WiX-users] How to GAC .Net assemblies the correct way?

I looked under the current wix help file how to section and could only find 
"How To: NGen Managed Assemblies During Installation".

This appears to cover having wix generated msi's install/uninstall to 
%systemroot%\assembly\gac_32 & %systemroot%\assembly\gac_64 but does not appear 
to have an option to all me to direct install to %systemroot%\assembly\gac_msil.

Am I overlooking some mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 7:07 AM
To: [EMAIL PROTECTED]; General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to GAC .Net assemblies the correct way?

There is a complete example of how to do this in the WiX help file that ships 
with WiX. Look under the How To section.

Neil


From: Wong Shao Voon [EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 2:54 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to GAC .Net assemblies the correct way?

Hey guys,

I could use a custom action to gacutil the .Net dlls into the GAC. But I 
searched that WiX and MSI has the correct way of GAC'ing the dlls, instead of 
using gacutil.exe . After I googled, I still couldn't find a single example on 
how to do it. Could someone kind enough to enlighten me the correct way to 
specify it in the WXS file?

Thank you very much!

And have a nice day!

Best regards,
Shao Voon




-
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


-
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

Re: [WiX-users] How to GAC .Net assemblies the correct way?

[Robert O'Brien]

I looked under the current wix help file how to section and could only find 
"How To: NGen Managed Assemblies During Installation".

This appears to cover having wix generated msi's install/uninstall to 
%systemroot%\assembly\gac_32 & %systemroot%\assembly\gac_64 but does not appear 
to have an option to all me to direct install to %systemroot%\assembly\gac_msil.

Am I overlooking some mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 7:07 AM
To: [EMAIL PROTECTED]; General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to GAC .Net assemblies the correct way?

There is a complete example of how to do this in the WiX help file that ships 
with WiX. Look under the How To section.

Neil


From: Wong Shao Voon [EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 2:54 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to GAC .Net assemblies the correct way?

Hey guys,

I could use a custom action to gacutil the .Net dlls into the GAC. But I 
searched that WiX and MSI has the correct way of GAC'ing the dlls, instead of 
using gacutil.exe . After I googled, I still couldn't find a single example on 
how to do it. Could someone kind enough to enlighten me the correct way to 
specify it in the WXS file?

Thank you very much!

And have a nice day!

Best regards,
Shao Voon




-
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

[WiX-users] does current wix 3.0 authored msi's provide automatically a similar solution where by a user can generate a transform .mst based on an interactive .msi session?

[Robert O'Brien]

There are many msi based setups I've used in the past, office and vstudio for 
example, where a custom command line is provided that allows you to run an 
interactive .msi session and at the end of it capture to a .mst all the 
settings you chose but not actually do the install.

Does current wix 3.0 authored msi's provide automatically a similar solution 
where by a user can generate a transform .mst based on an interactive .msi 
session?

-
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] How can i do Partial Un installation

[Robert O'Brien]

I believe the default behavior of the  and  maintenance mode UI experience is that it provides 
users the option of only selecting specific features currently installed that 
they would like removed.

-Original Message-
From: Sandeep Gautam (HCL Technologies Ltd) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 7:53 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How can i do Partial Un installation

Hi ,

I want to do partial uninstallation. There would be one some check  boxes for 
selection to which I want to uninstall on Remove screen but I don't know is 
this possible?

Regards
-Sandeep

-
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] how does one get XmlFile to insert literal translations of < and > entity settings when setting values?

[Robert O'Brien]

Switched to util:XmlConfig and inserted a document fragment which did the 
trick.   I included an xml comment, as shown in excerpt below, in document 
fragment xml but util:XmlConfig stripped the xml comment.   Is there a way to 
keep util:XmlConfig from stripping xml code comment sout of the document 
fragment?





-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 4:22 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] how does one get XmlFile to insert literal 
translations of < and > entity settings when setting values?

You need to create a new element.  Or you can switch to XmlConfig and insert a 
document fragment.

-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 13:14
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] how does one get XmlFile to insert literal translations of 
< and > entity settings when setting values?

Background:
-
I have a wix souce file with the following XmlFile entry



When I run my msi using "msiexec /I myServiceDeliverable.msi 
SERVICEGATEWAYIDENTITY="<servicePrincipalName value='host/localhost' />" 
/l*v myServiceDeliverable.log" end up with the following xml config file 
settings.


https://localhost/ServiceGateway/ServiceGateway.svc";>
<servicePrincipalName value='host/localhost' 
/>

https://localhost/ServiceGateway2/ServiceGateway2.svc";>




Question
-
How does one get XmlFile to insert literal translations of < and > entity 
settings when setting values?

-
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] Do i need to pass property values both at install time and Uninstalltime.

[Robert O'Brien]

   . . .
   
  
   
   . . .


-Original Message-
From: Chandra Vuppala [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 9:44 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Do i need to pass property values both at install time 
and Uninstalltime.

thanks Sandeep,
Can u give code for storing property value in registry and getting it.

Thanks &  Regards,
Chandrashekar vuppala
M-9908298419




From: Sandeep Gautam (HCL Technologies Ltd) [mailto:[EMAIL PROTECTED]
Sent: Wed 24/09/2008 9:22 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Do i need to pass property values both at install time 
and Uninstalltime.



Yes, you need to pass the value at both time. So keep your values stored in 
registry for any future reference if required.

Regards
Sandeep

-Original Message-
From: Chandra Vuppala [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 8:20 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Do i need to pass property values both at install time and 
Uninstalltime.

Hi,

I have 2 servers in which one is database server and other is Application 
server.

while Installing the MSI on Application server  i have to pass Database server 
name. i am using Properties for that, it works fine, but while uninstalling if 
i dont pass Propety value it is taking default value. When i passed property 
value while uninstalling it is taking correct value. But my question is MSI 
will  persist the property value or not? If not Why? What is other way of 
implementation, beacuse i dont want to pass property value while Uninstallation.

Please anyone help me

Thanks &  Regards,
Chandrashekar vuppala
M-9908298419




From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Wed 24/09/2008 7:51 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] How to Keep the Property value along with MSI



Here is what I use to save off the databasehost name provided at install time 
so it will be set automatically to the correct value during uninstall 
processing.






For $(var.SoftwareKey) assignment I have the following in place.
























-Original Message-
From: Brian Rogers [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 3:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to Keep the Property value along with MSI

Hey Sandeep,

I imagine that you could have a registry entry that sets the value of the 
property and you could have registry locator that reads that value. Check your 
state and when doing an uninstall use that registry locator value?

Thanks,

--
Brian Rogers
"Intelligence removes complexity." - Me
http://icumove.spaces.live.com <http://icumove.spaces.live.com/>  
<http://icumove.spaces.live.com/>

On Mon, Sep 22, 2008 at 3:39 PM, Sandeep Gautam (HCL Technologies Ltd) < [EMAIL 
PROTECTED]> wrote:

> Hi,
>
> While Installing , I am passing One Data base server name along with
> One property. But while uninstalling, It is giving error because it is
> looking for data base name. So I want to save the value of the
> property so that I can use the same on uninstallation.
>
> Regards
> Sandeep
>
-
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



IMPORTANT
1.  This email and any attachments are confidential.  Any unauthorised 
dissemination or other use of these materials is prohibited.  If received in 
error, please contact us and delete all copies.
2.  Before opening or using attachments, check them for viruses and 
defects.  Our liability i

Re: [WiX-users] How to Keep the Property value along with MSI

[Robert O'Brien]

Here is what I use to save off the databasehost name provided at install time 
so it will be set automatically to the correct value during uninstall 
processing.






For $(var.SoftwareKey) assignment I have the following in place.
























-Original Message-
From: Brian Rogers [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 3:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to Keep the Property value along with MSI

Hey Sandeep,

I imagine that you could have a registry entry that sets the value of the
property and you could have registry locator that reads that value. Check
your state and when doing an uninstall use that registry locator value?

Thanks,

--
Brian Rogers
"Intelligence removes complexity." - Me
http://icumove.spaces.live.com

On Mon, Sep 22, 2008 at 3:39 PM, Sandeep Gautam (HCL Technologies Ltd) <
[EMAIL PROTECTED]> wrote:

> Hi,
>
> While Installing , I am passing One Data base server name along with One
> property. But while uninstalling, It is giving error because it is looking
> for data base name. So I want to save the value of the property so that I
> can use the same on uninstallation.
>
> Regards
> Sandeep
>
-
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

[WiX-users] how does one get XmlFile to insert literal translations of < and > entity settings when setting values?

[Robert O'Brien]

Background:
-
I have a wix souce file with the following XmlFile entry



When I run my msi using "msiexec /I myServiceDeliverable.msi 
SERVICEGATEWAYIDENTITY="" 
/l*v myServiceDeliverable.log" end up with the following xml config file 
settings.


https://localhost/ServiceGateway/ServiceGateway.svc";>


https://localhost/ServiceGateway2/ServiceGateway2.svc";>




Question
-
How does one get XmlFile to insert literal translations of < and > entity 
settings when setting values?

-
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] SQL Server 2008

[Robert O'Brien]

...also if you switch the account initially specified for services to run under 
during setup of sql05 or sql08 to a different account sometime after setup 
completes you need to remember to add that account to the appropriate 
SqlServer local security groups in order for the 
necessary security permissions to be present.

-Original Message-
From: Neil Sleightholm [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 10:01 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] SQL Server 2008

Amy

SQL 2005 runs as "Network Service" as well so you should have seen the
problem there. You shouldn't need to make it run as "Local System" (in
fact it opens a security issue) as the SQL install sets the permissions
on the data and log folders (it is group SQLServerx). If you are
installing to a non-default folder then you would need to change the
permissions on that folder. I did come across a PC that had a
permissions problem but that was due to the way another instance of SQL
had been installed by the PC manufacturer.

I hope this helps.

Neil

-Original Message-
From: Amy Rosewater [mailto:[EMAIL PROTECTED]
Sent: 23 September 2008 17:45
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] SQL Server 2008

Hi All,

This did indeed turn out to be a SQL Server 2008 configuration issue
related to the identity under which the SQL Server service was running.
Once this was set to Local System (which has permissions to write to the
Program Files directory) it works fine.  Just in case anyone else runs
into this one.

Amy

-Original Message-
From: Amy Rosewater [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2008 4:19 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] SQL Server 2008

Hi Michael,

I am actually creating the folder into which I place the .mdf and .ldf
files for SQL Server as a part of the install, and those directories are
definitely getting created.  However, I found a clue on a the following
posting:

http://www.tech-archive.net/Archive/SQL-Server/microsoft.public.sqlserve
r.clustering/2006-10/msg00073.html

This basically says you must add disk resources as dependencies for SQL
Server or SQL Server cannot see the disks.  I am hoping this is the case
as it would mean it is not the install, but the configuration of SQL
Server that is the issue.

Thanks,

Amy

-Original Message-
From: Michael Osmond [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2008 3:27 PM
To: General discussion for Windows Installer XML toolset.; General
discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] SQL Server 2008

Hello Amy,

My suspicion is that the folder structure created by SQL2008 is
different to SQL2005 (this was the case between 2000 and 2005).  If the
folder doesn't exist then the Create Database command will fail.

Is there a need to actually set the paths to these folders?  If you dont
set them then you allow the SQL server to create these files in its own
default directories.  Then its just a matter of SQL server being
correctly configured.

Regards

Michael





From: Amy Rosewater [mailto:[EMAIL PROTECTED]
Sent: Tue 23/09/2008 7:13 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] SQL Server 2008



Hi All,



I have an install that has been working well for months against SQL
Server 2005.  We recently upgraded one of our test servers to SQL Server
2008 and now the Wix Component to create my database no longer executes
correctly.



The error number I receive is 26201.  I have searched for other reports
of this error being encountered and it appears to potentially be related
to the use of the SqlFileSpec and SqlLogFileSpec elements in my wix xml.



>From my log:



Error 26201. Error -2147217900: failed to create SQL database:
iVantage50, error detail: CREATE DATABASE failed. Some file names listed
could not be created. Check related errors..



>From my wix xml:





  

  





Any ideas why this would stop working for SQL Server 2008?



Thanks in advance for your help.



Amy Rosewater

SPECTRUM Human Resource Systems Corporation

707 17th Street Suite 3800

Denver CO, 80202

303.592.3403

[EMAIL PROTECTED]




-
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
challe

[WiX-users] handling v1.0 to v1.1 release start | programs | folder changes

[Robert O'Brien]

In my v1.0 release I had shortcut settings in multiple components using start | 
programs | "My Service Deliverable" menu folder.In my v1.1 release I 
changed the wix sources to use "start | programs | "My Service Deliverable 
v1.1".   When I run a v1.0 to v1.1 msp patch or msi upgrade I end up with the 
old shortcuts menu folder start | programs | "My Service Deliverable" menu 
folder and the new start | programs | "My Service Deliverable v1.1" menu 
folder.   Is there something I'm overlooking that would enable the msp patch 
and msi upgrade processing get rid of the old folder?

in v1.0 wix sources
My Service Deliverable
in v1.1 wix sources
My Service Deliverable v1.1

in v1.0 and v1.1 wix sources this stayed the same














-
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] Patch creation problems

[Robert O'Brien]

You need to launch the msp using the command line and the properties 
REINSTALL=ALL REINSTALLMODE=omus.   If you want to be able to use your msp by 
double clicking on it you need to add something like the following to your wix 
sources so that those property values will get assigned automatically before 
processing begins.






PATCH And Installed
PATCH And Installed


-Original Message-
From: Scott Sam [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2008 9:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patch creation problems


When I double click on my msp file  I get the welcome dialog, followed
by the maintenance dialog, giving me the choice to change, repair or
remove.  Choosing repair or change, will cause the patch to show up in
add/remove programs, but the text file does not show the changes that I
made.

Problem 1: Why do I get the maintenance dialog?  I would like to just
double click the msp file and then have the patch be applied.  Is there
any way to do this?
Problem 2: the changes aren't being applied.  How do I fix this?

I'm using wix version 3.0.4429.0

To create my patch I'm using the following method:
1.  Compile original msi
2.  Change a text file that is included in the msi.
3.  Compile new msi
4.  Create a transform between the two msi's.
torch.exe -p -xi original\Product.wixpdb Product.wixpdb -out
Patch\Diff.Wixmst
5.  Build the patch
pyro.exe Patch\Patch.WixMsp -out Patch\Patch.msp -t RTM
Patch\Diff.wixmst

here is my patch.wxs file:

http://schemas.microsoft.com/wix/2006/wi";>
  

  



  
  

  

  




-
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] WiX-users Digest, Vol 27, Issue 36

[Robert O'Brien]

fyi - in my wix sources I'm able to successfully set/use util:xmlfile 
elementpath values with attribute search qualifiers using the following 
escaping syntax.

   

You can use alternatively:

   


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Evans, Jim
Sent: Tuesday, August 12, 2008 11:27 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] WiX-users Digest, Vol 27, Issue 36

The workaround mentioned in the bug you supplied the link to works around my 
problem nicely. Thanks for the heads-up.



From: Meyer, Shawn [mailto:[EMAIL PROTECTED]
Sent: Tue 8/12/2008 12:21 PM
To: wix-users@lists.sourceforge.net
Cc: Evans, Jim
Subject: RE: WiX-users Digest, Vol 27, Issue 36



I saw an old bug similar to your problem here
http://osdir.com/ml/windows.devel.wix.devel/2006-07/msg00017.html

There is a suggested work around that may help diagnose if the xpath is
parsed due to the brackets.

A work around to avoid this bug is to use a property for
the XPath value. So if your WXS file is:

   

You can use alternatively:

   [EMAIL PROTECTED]"third"]

   

Using this work around, the Xml node is correctly
processed by WiX.


Let us know what you find.


Date: Tue, 12 Aug 2008 10:35:03 -0400
From: "Evans, Jim" <[EMAIL PROTECTED]>
Subject: [WiX-users] XmlConfig XPath problem
To: 
Message-ID:

<[EMAIL PROTECTED]>
Content-Type: text/plain;   charset="iso-8859-1"

I'm having a problem writing a value to an XML file using XmlConfig (WiX
3.0.4401). Here is a model XML file with the structure I have:


  

  


  ...

  


I need to set the server attribute of the Default element. Here is my
WiX code for XmlConfig:



When I try to run the resulting .msi, I receive an error that says
"Failed to find node:
/configuration/myComponent/[EMAIL PROTECTED]'DatabaseConnections]Default in
XML file
, system error: -2147467259"

What concerns me is that my path delimiter ('/') is getting lost between
my section "name" attribute and my child "Default" element. Am I
escaping something wrong? Is my xpath wrong (I don't think it is, but
I'm not the greatest at xpath)? Most of the samples I've seen for
XmlConfig stop after finding a node with an attribute, not continuing to
a child node thereof.

--Jim Evans
Numara Software


-
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] create setup.exe

[Robert O'Brien]

So it would seem that setting REINSTALL and REINSTALLMODE automatically within 
wix works for msp small update or minor upgrade processing but not an option, 
as suggested by others earlier, for msi minor upgrade processing.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 18, 2008 1:15 AM
To: 'wix-users@lists.sourceforge.net'
Subject: Re: [WiX-users] create setup.exe

fyi - msi minor upgrade detection using QFEUpgrade=1 property setting condition 
is no longer working for me, i.e. qfeupgrade property no longer being generated 
during msi minor upgrade processing.  Not yet sure what changes to my wix 
sources have broke that option or how I was testing to cause it to show 
up...its probably because when I was testing this I was still setting 
REINSTALL=ALL and REINSTALLMODE=vomus on the command line.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Wednesday, September 17, 2008 6:08 PM
To: 'wix-users@lists.sourceforge.net'
Subject: Re: [WiX-users] create setup.exe

Here is what I'm now using to accomplish this w/o needing a setup.exe wrapper, 
e.g. you can just double click the msp and/or msi.   Initial knowledge share 
for the double click msp property settings solution this came from John 
Nannenga.

















QFEUpgrade=2
QFEUpgrade=2


QFEUpgrade=1
QFEUpgrade=1


NEWERVERSIONFOUND
OLDERVERSIONFOUND
OLDERVERSIONFOUND
OLDERVERSIONFOUND  



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Ding
Sent: Wednesday, September 17, 2008 8:36 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] create setup.exe

Hello All,



Small and minor upgrades cannot be run simply by clicking on the .msi
file, Wix Tutorial recommends using a setup.exe to launch it which
includes this command

   msiexec /i setup.msi REINSTALL=ALL REINSTALLMODE=vomus



Could anyone give me a good reference about creating the setup.exe for
this purpose? Thanks.



Jason



-
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


-
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] create setup.exe

[Robert O'Brien]

fyi - msi minor upgrade detection using QFEUpgrade=1 property setting condition 
is no longer working for me, i.e. qfeupgrade property no longer being generated 
during msi minor upgrade processing.  Not yet sure what changes to my wix 
sources have broke that option or how I was testing to cause it to show 
up...its probably because when I was testing this I was still setting 
REINSTALL=ALL and REINSTALLMODE=vomus on the command line.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Wednesday, September 17, 2008 6:08 PM
To: 'wix-users@lists.sourceforge.net'
Subject: Re: [WiX-users] create setup.exe

Here is what I'm now using to accomplish this w/o needing a setup.exe wrapper, 
e.g. you can just double click the msp and/or msi.   Initial knowledge share 
for the double click msp property settings solution this came from John 
Nannenga.

















QFEUpgrade=2
QFEUpgrade=2


QFEUpgrade=1
QFEUpgrade=1


NEWERVERSIONFOUND
OLDERVERSIONFOUND
OLDERVERSIONFOUND
OLDERVERSIONFOUND  



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Ding
Sent: Wednesday, September 17, 2008 8:36 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] create setup.exe

Hello All,



Small and minor upgrades cannot be run simply by clicking on the .msi
file, Wix Tutorial recommends using a setup.exe to launch it which
includes this command

   msiexec /i setup.msi REINSTALL=ALL REINSTALLMODE=vomus



Could anyone give me a good reference about creating the setup.exe for
this purpose? Thanks.



Jason



-
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] msp patch and msi upgrade processing scenario where a specific .config file setting which has changed is not getting updated

[Robert O'Brien]

After some additional trial and error investigation what appears to be 
happening here is that component files that get modified by 

...








...
!Services=3 And ?Service1=3 And (QFEUpgrade=2 Or 
QFEUpgrade=1)
!Services=3 And ?Service1=3 And (QFEUpgrade=2 Or 
QFEUpgrade=1)

Conversely when the msp is removed I ended up with the prior release copy of 
that file w/o the mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Wednesday, September 17, 2008 12:38 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] msp patch and msi upgrade processing scenario where a 
specific .config file setting which has changed is not getting updated

I have a msp patch and msi minor pgrade processing result where a specific 
.config file setting which has underwent some miner content changes in the 
v1.1 release is not getting updated.

If I diff my v1.0 target adminInstall and my v1.1 update adminInstall used to 
by the old msimsp patch method for msp generation I can see the expected 
differences between the two releases of the particular file in question.

When I run a v1.1 clean install I get the expected file contents.

The file in question gets updated during v1.0 deployment by associated 
component  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] some final points for clarification on the wholev1.0 to v1.1 msp patch upgrade [ or a v1.0 to v1.1 msi upgrade ]process

[Robert O'Brien]

That's was it.   I had had one test build of my patch where it tested it doing 
a v1.0 to v1.1 minor upgrade where the v1.1 wix had introduced a ServiceControl 
entry.   I used hyper-v snapshot to roll back to prior that msp patch minor 
upgrade test pass and removed the v1.1 wix that had introduced a ServiceControl 
entry and I was back to a scenario where my msp patch minor upgrade tests were 
able to be removed.

All the recent noise from me on the forum to do with msp patch minor upgrade 
and msi minor upgrade options is the result of our teams first release case 
where we needed to do a v1.0 to v1.1 service deliverable deployment.   We 
wanted to use the wix msi supported minor upgrade solution, versus a v1.0 
uninstall followed by v1.1 install, so we could retain website, vdirs, window 
services and database setups & state deployed by the initial v1.0 release.  I 
don't think I'm still 100% sure on all the knobs one has at their disposal to 
control everything during small update msp patch, minor upgrade msp patch or 
msi and major upgrade msi processing.   I did try and use the new wix3 sources 
and torch/pyro utilities for patch generation but ran into issues with the pyro 
compile stage and so due to time crunch stuck with the old msimsp sources and 
utility approach for getting the msp built which was working.   Overall our 
team is very impressed and happy about the magic that gets done w
 ith only a little bit of patch wix sources work and msi minor upgrade source 
changes.

There are still many subtle things going on that I really am not 100% sure on, 
for example after rereading the doc pointers provided several times it seems 
that:
- msi  v1.next minor upgrade processing just works if all that is 
involves is binary file updates w/o doing anything other than incrementing 
 minor value setting
- the QFEUpdate=2 [ or PATCH ] property setting depicts msp small update and 
minor upgrade processing and QFEUpdate=1 property setting depicts a msi minor 
upgrade processing and UPGRADINGPRODUCTCODE property setting depicts msi major 
upgrade processing and MSIPATCHREMOVE depicts msp small update or minor upgrade 
removal processing
- the above property settings can be use to have the msp required REINSTALL=ALL 
and REINSTALLMODE=omus and msi upgrade processing required REINSTALL=ALL and 
REINSTALLMODE=vomus property settings automatically set using customactions 
versus having to resort to a setup.exe or script wrapper for launching msp & 
msi enabled with update/upgrade behaviors
- component files that get modified by mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic
Sent: Monday, September 15, 2008 4:14 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] some final points for clarification on the wholev1.0 
to v1.1 msp patch upgrade [ or a v1.0 to v1.1 msi upgrade ]process

Some patches are un-installable:

http://msdn.microsoft.com/en-us/library/aa372102(VS.85).aspx

I'm offering to pay and ship few cases of beer and hamburger patties so
that you guys at Microsoft can meet somewhere at campus, relax, hammer
this out and explain all of it (I mean patching business) to the rest of
us in some blog post.

-
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] create setup.exe

[Robert O'Brien]

Here is what I'm now using to accomplish this w/o needing a setup.exe wrapper, 
e.g. you can just double click the msp and/or msi.   Initial knowledge share 
for the double click msp property settings solution this came from John 
Nannenga.

















QFEUpgrade=2
QFEUpgrade=2


QFEUpgrade=1
QFEUpgrade=1


NEWERVERSIONFOUND
OLDERVERSIONFOUND
OLDERVERSIONFOUND
OLDERVERSIONFOUND  



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Ding
Sent: Wednesday, September 17, 2008 8:36 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] create setup.exe

Hello All,



Small and minor upgrades cannot be run simply by clicking on the .msi
file, Wix Tutorial recommends using a setup.exe to launch it which
includes this command

   msiexec /i setup.msi REINSTALL=ALL REINSTALLMODE=vomus



Could anyone give me a good reference about creating the setup.exe for
this purpose? Thanks.



Jason



-
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

[WiX-users] msp patch and msi upgrade processing scenario where a specific .config file setting which has changed is not getting updated

[Robert O'Brien]

I have a msp patch and msi minor pgrade processing result where a specific 
.config file setting which has underwent some miner content changes in the 
v1.1 release is not getting updated.

If I diff my v1.0 target adminInstall and my v1.1 update adminInstall used to 
by the old msimsp patch method for msp generation I can see the expected 
differences between the two releases of the particular file in question.

When I run a v1.1 clean install I get the expected file contents.

The file in question gets updated during v1.0 deployment by associated 
component  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] some final points for clarification on the whole v1.0 to v1.1 msp patch upgrade [ or a v1.0 to v1.1 msi upgrade ] process

[Robert O'Brien]

Each of the following three forms for using the MSIPATCHREMOVE property 
referred to at http://msdn.microsoft.com/en-us/library/aa370348(VS.85).aspx 
looks like they should do the trick but currently I'm getting a "Uninstallation 
of the patch package is not supported." result.   I previously was able to use 
control panel | add remove programs | show updates |  | remove to 
uninstall the patch but I no longer am offered that option.   Any thoughts on 
what I clobbered that now prevents me from being able to uninstall patches?

msiexec /i {F7A5E23F-B931-49D6-BD5B-1B90CD893210} /qb 
MSIPATCHREMOVE={C86050B6-37EC-4BE8-A9D0-A9C61DA42ED6} /l*v 
d:\temp\v10tov11patchRemove.log
msiexec /i "\\rpbuildagent03\builds\RXP Eventing\v1.0rtm\RP Event Notification 
Service.msi" /qb MSIPATCHREMOVE={C86050B6-37EC-4BE8-A9D0-A9C61DA42ED6} /l*v 
d:\temp\v10tov11patchRemove.log
msiexec /i "\\rpbuildagent03\builds\RXP Eventing\v1.0rtm\RP Event Notification 
Service.msi" /qb MSIPATCHREMOVE="\\rpbuildagent03\builds\RXP 
Eventing\CheckInBuilds\Current\Release\RP Event Notification Service Patch.msp" 
/l*v d:\temp\v10tov11patchRemove.log

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Monday, September 15, 2008 12:21 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] some final points for clarification on the whole v1.0 
to v1.1 msp patch upgrade [ or a v1.0 to v1.1 msi upgrade ] process

Found the MSIPATCHREMOVE property... Ref: 
http://msdn.microsoft.com/en-us/library/aa370348(VS.85).aspx

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Monday, September 15, 2008 1:03 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] some final points for clarification on the whole v1.0 
to v1.1 msp patch upgrade [ or a v1.0 to v1.1 msi upgrade ] process

Got answers to these.  Would be interested if anyone already has a command line 
utility wrapping MsiRemovePatches api that allows cmd.exe scripted removal of 
patches.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Monday, September 15, 2008 10:02 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] some final points for clarification on the whole v1.0 to 
v1.1 msp patch upgrade [ or a v1.0 to v1.1 msi upgrade ] process

1.   when I run a v1.0 to v1.1 msp patch upgrade [ or a v1.0 to v1.1 msi 
upgrade ] am I expected to include the additional public property settings that 
were needed/used when I ran the original v1.0 deployment, e.g. INSTALLDIR, 
DATABASESHOSTNAME, DATABASESDOMAINLOGINGROUPNAME, etc.?


2.   is there a programmatic way for removing a patch versus having to go into 
the addRmv Programs | view installed updates listing, e.g. msiexec /x ...?   
I'm trying to script the automated deployment of a patch and want to also 
include the command that undeploy's it.   The primary reason I wanted to get 
v1.0 to v1.1 msp patch upgrading working is to get the service release rollback 
support versus the v1.0 to v1.1 msi upgrade process that has no rollback story.


3.  I have a customaction that I need to execute after the v1.0 to v1.1 msp 
patch upgrade (Installed And PATCH) [ or v1.0 to v1.1 msi upgrade 
(UPGRADINGPRODUCTCODE) ] processing completes...is it recommended that I just 
schedule an installexecutesequence entry for that customaction that is 
conditioned to run if the noted property evaluations are true?

-
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 prize

Re: [WiX-users] some final points for clarification on the whole v1.0 to v1.1 msp patch upgrade [ or a v1.0 to v1.1 msi upgrade ] process

[Robert O'Brien]

Got answers to these.  Would be interested if anyone already has a command line 
utility wrapping MsiRemovePatches api that allows cmd.exe scripted removal of 
patches.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Monday, September 15, 2008 10:02 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] some final points for clarification on the whole v1.0 to 
v1.1 msp patch upgrade [ or a v1.0 to v1.1 msi upgrade ] process

1.   when I run a v1.0 to v1.1 msp patch upgrade [ or a v1.0 to v1.1 msi 
upgrade ] am I expected to include the additional public property settings that 
were needed/used when I ran the original v1.0 deployment, e.g. INSTALLDIR, 
DATABASESHOSTNAME, DATABASESDOMAINLOGINGROUPNAME, etc.?


2.   is there a programmatic way for removing a patch versus having to go into 
the addRmv Programs | view installed updates listing, e.g. msiexec /x ...?   
I'm trying to script the automated deployment of a patch and want to also 
include the command that undeploy's it.   The primary reason I wanted to get 
v1.0 to v1.1 msp patch upgrading working is to get the service release rollback 
support versus the v1.0 to v1.1 msi upgrade process that has no rollback story.


3.  I have a customaction that I need to execute after the v1.0 to v1.1 msp 
patch upgrade (Installed And PATCH) [ or v1.0 to v1.1 msi upgrade 
(UPGRADINGPRODUCTCODE) ] processing completes...is it recommended that I just 
schedule an installexecutesequence entry for that customaction that is 
conditioned to run if the noted property evaluations are true?

-
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

[WiX-users] some final points for clarification on the whole v1.0 to v1.1 msp patch upgrade [ or a v1.0 to v1.1 msi upgrade ] process

[Robert O'Brien]

1.   when I run a v1.0 to v1.1 msp patch upgrade [ or a v1.0 to v1.1 msi 
upgrade ] am I expected to include the additional public property settings that 
were needed/used when I ran the original v1.0 deployment, e.g. INSTALLDIR, 
DATABASESHOSTNAME, DATABASESDOMAINLOGINGROUPNAME, etc.?



2.   is there a programmatic way for removing a patch versus having to go into 
the addRmv Programs | view installed updates listing, e.g. msiexec /x ...?   
I'm trying to script the automated deployment of a patch and want to also 
include the command that undeploy's it.   The primary reason I wanted to get 
v1.0 to v1.1 msp patch upgrading working is to get the service release rollback 
support versus the v1.0 to v1.1 msi upgrade process that has no rollback story.



3.  I have a customaction that I need to execute after the v1.0 to v1.1 msp 
patch upgrade (Installed And PATCH) [ or v1.0 to v1.1 msi upgrade 
(UPGRADINGPRODUCTCODE) ] processing completes...is it recommended that I just 
schedule an installexecutesequence entry for that customaction that is 
conditioned to run if the noted property evaluations are true?

-
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] what setting causes current wix build output to land in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used to land

[Robert O'Brien]

In my setup.wixproj I added the proposed Message command to the following 
Target setting and it did successfully dump the list of full culture specific 
TargetPath build output list as the last output in the build output window.   
So the trick I guess to processing the list of culture specific output would be 
to use Target AfterBuild msbuild task command that is %(list) aware versus 
postBuild event commands.




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Saturday, September 13, 2008 9:20 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Robert O'Brien wrote:
> The syntax of the command is incorrect.
>

That message is coming from cmd.exe; you need to put it in a target instead.

--
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

[WiX-users] scoping wix3 way patch msp generation and relevance of public property settings during msp or msi minor upgrade processing

[Robert O'Brien]

q1 - In the new wix3 way patch msp generation xml is there a way to specify the 
 element to cover get the msp patch generated to cover changes to 
all components from v1.0 to v1.1 versus having what appears to be the need to 
specify every component explicitly as the patch help document sample syntax 
suggests?



















   

   

   



q2 -  when a msp or msi minor upgrade is being processed do public property 
settings that were defined during the v1.0 initial installation need to be 
defined again for the minor upgrade processing or will the values specified 
during v1.0 initial installation be reused, e.g. INSTALLDIR, MYSVCWEBSITENAME, 
MYSVCWEBSITEPORT, MYSVCDATABASENAME, etc.
























-
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] is there a way to get current wix vs08 project extensions to output a patch msp?

[Robert O'Brien]

Thanks.   I'm now using the following Patch.wixproj postbuild events to 
automate the generation of msp output using either new wix3 way or old msimsp 
way.

















Patch.wixproj | postBuild event
move /y "$(TargetDir)en-us\$(TargetName).msi" 
"$(ProjectDir)obj\$(Configuration)\$(TargetName).wixmsp"
robocopy "\\rpbuildagent03\builds\RXP Eventing\v1.0adminInstallAlt" 
"$(ProjectDir)obj\$(Configuration)\v1.0adminInstallAlt" /mir /r:0
if not exist "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" md 
"$(ProjectDir)obj\$(Configuration)\v1.1adminInstall"
rem msiexec.exe /a "$(Setup.TargetDir)en-us\$(Setup.TargetFileName)" /qn 
TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l* 
"$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification 
Service.log"
if "$(IsDesktopBuild)" == "" msiexec.exe /a 
"$(SolutionDir)Setup\Setup\bin\$(Configuration)\en-us\RP Event Notification 
Service.msi" /qn TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" 
/l* "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification 
Service.log"
if "$(IsDesktopBuild)" == "false" msiexec.exe /a "$(OutDir)en-us\RP Event 
Notification Service.msi" /qn 
TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l* 
"$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification 
Service.log"
"$(MSBuildExtensionsPath)\..\Windows Installer XML v3\bin\torch.exe" -p -ax 
"$(ProjectDir)obj\$(Configuration)\extractedAdminInstallBinaries" 
"$(ProjectDir)obj\$(Configuration)\v1.0adminInstall\RP Event Notification 
Service.msi" "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event 
Notification Service.msi" -out 
"$(ProjectDir)obj\$(Configuration)\$(TargetName).wixmst"
"$(MSBuildExtensionsPath)\..\Windows Installer XML v3\bin\pyro.exe 
"$(ProjectDir)obj\$(Configuration)\$(TargetName).wixmsp" -out 
"$(TargetDir)en-us\$(TargetName).msp" -t Rtm 
"$(ProjectDir)obj\$(Configuration)\$(TargetName).wixmst"
cmd /c echo end processing patch post-build event command lines


















Patch.wixproj | postBuild event
move /y "$(TargetDir)en-us\$(TargetName).msi" 
"$(ProjectDir)obj\$(Configuration)\$(TargetName).pcp"
robocopy "\\rpbuildagent03\builds\RXP Eventing\v1.0adminInstall" 
"$(ProjectDir)obj\$(Configuration)\v1.0adminInstall" /mir /r:0
if not exist "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" md 
"$(ProjectDir)obj\$(Configuration)\v1.1adminInstall"
rem msiexec.exe /a "$(Setup.TargetDir)en-us\$(Setup.TargetFileName)" /qn 
TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l* 
"$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification 
Service.log"
if "$(IsDesktopBuild)" == "" msiexec.exe /a 
"$(SolutionDir)Setup\Setup\bin\$(Configuration)\en-us\RP Event Notification 
Service.msi" /qn TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" 
/l* "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification 
Service.log"
if "$(IsDesktopBuild)" == "false" msiexec.exe /a "$(OutDir)en-us\RP Event 
Notification Service.msi" /qn 
TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l* 
"$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification 
Service.log"
if exist "$(TargetDir)en-us\$(TargetName).log" del 
"$(TargetDir)en-us\$(TargetName).log"
pushd "$(TargetDir)en-us\" & "C:\Program Files\Microsoft 
SDKs\Windows\v6.0A\Bin\MsiMsp.exe" -s 
"$(ProjectDir)obj\$(Configuration)\$(TargetName).pcp" -p "$(TargetName).msp" -l 
"$(TargetName).log" & popd
cmd /c echo end processing patch post-build event command lines

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Saturday, September 13, 2008 9:22 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] is there a way to get current wix vs08 project 
extensions to output a patch msp?

Robert O'Brien wrote:
> Question - if the only thing different in the light command that gets applied 
> using the current wix project templet is ".msi" versus ".pcp" then is the 
> contents of the a file going to be right, in other words can I just rename 
> the file in a postBuild event step in order to get the desired .pcp file that 
> 

Re: [WiX-users] using torch.exe -ax to enable use of admin install msi target and update input parameter values

[Robert O'Brien]

Thanks that appears to be exactly what my issue was with my adminInstall 
output.  I used orca to reconfigure the feature level settings in my v1.0 msi 
so I could generate a useable adminInstall of it and configured my in progress 
v1.1 sources to instead use the following feature install condition logic so 
its build output will directly support generation of a useable adminInstall.

DATABASES=0
versus what I had

DATABASES=1

At this point using new wix3 way for patch generation is spitting out the 
following torch.exe processing command error.   If I switch to the old msimsp 
way for patch generation it doesn't seem to have that same issue.  I even tried 
rebuilding my v1.0 msi output using the same wix framework release as I'm using 
for my v1.1 work and it didn't make the torch.exe RadioButton error go away.

Error   2   The table definition of 'RadioButton' in the target database 
does not match the table definition in the updated database. A transform 
requires that the target database schema match the updated database schema. 
  D:\tfswf\ws0\RXD_RXG_PTF\RXP 
Eventing\Main\Setup\Patch\obj\Debug\v1.0adminInstall\RP Event Notification 
Service.msi 0   1   Patch

















Patch.wixproj | postBuild event
move /y "$(TargetDir)en-us\$(TargetName).msi" 
"$(ProjectDir)obj\$(Configuration)\$(TargetName).wixmsp"
robocopy "\\rpbuildagent03\builds\RXP Eventing\v1.0adminInstallAlt" 
"$(ProjectDir)obj\$(Configuration)\v1.0adminInstallAlt" /mir /r:0
if not exist "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" md 
"$(ProjectDir)obj\$(Configuration)\v1.1adminInstall"
rem msiexec.exe /a "$(Setup.TargetDir)en-us\$(Setup.TargetFileName)" /qn 
TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l* 
"$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification 
Service.log"
if "$(IsDesktopBuild)" == "" msiexec.exe /a 
"$(SolutionDir)Setup\Setup\bin\$(Configuration)\en-us\RP Event Notification 
Service.msi" /qn TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" 
/l* "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification 
Service.log"
if "$(IsDesktopBuild)" == "false" msiexec.exe /a "$(OutDir)en-us\RP Event 
Notification Service.msi" /qn 
TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l* 
"$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification 
Service.log"
"$(MSBuildExtensionsPath)\..\Windows Installer XML v3\bin\torch.exe" -p -ax 
"$(ProjectDir)obj\$(Configuration)\extractedAdminInstallBinaries" 
"$(ProjectDir)obj\$(Configuration)\v1.0adminInstall\RP Event Notification 
Service.msi" "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event 
Notification Service.msi" -out 
"$(ProjectDir)obj\$(Configuration)\$(TargetName).wixmst"
"$(MSBuildExtensionsPath)\..\Windows Installer XML v3\bin\pyro.exe 
"$(ProjectDir)obj\$(Configuration)\$(TargetName).wixmsp" -out 
"$(TargetDir)en-us\$(TargetName).msp" -t Rtm 
"$(ProjectDir)obj\$(Configuration)\$(TargetName).wixmst"
cmd /c echo end processing patch post-build event command lines


Patch.wixproj | postBuild event
















rem msiexec.exe /a "$(Setup.TargetDir)en-us\$(Setup.TargetFileName)" /qn 
TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l* 
"$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification 
Service.log"
if "$(IsDesktopBuild)" == "" msiexec.exe /a 
"$(SolutionDir)Setup\Setup\bin\$(Configuration)\en-us\RP Event Notification 
Service.msi" /qn TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" 
/l* "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification 
Service.log"
if "$(IsDesktopBuild)" == "false" msiexec.exe /a "$(OutDir)en-us\RP Event 
Notification Service.msi" /qn 
TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l* 
"$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification 
Service.log"
if exist "$(TargetDir)en-us\$(TargetName).log" del 
"$(TargetDir)en-us\$(TargetName).log"
pushd "$(TargetDir)en-us\" & "C:\Program Files\Microsoft 
SDKs\Windows\v6.0A\Bin\MsiMsp.exe" -s 
"$(ProjectDir)obj\$(Configuration)\$(TargetName).pcp" -p "$(TargetName).msp" -l 
"$(TargetName).log" & popd
cmd /c echo end processing patch post-build event command lines


-Orig

Re: [WiX-users] what setting causes current wix build output to land in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used to land

[Robert O'Brien]

Tried adding  to my wixproj postBuild event and it gives me the following build output 
error.

The syntax of the command is incorrect.
C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.0\Wix.targets(1860,5): error 
MSB3073: The command "http://schemas.microsoft.com/developer/msbuild/2003"; />


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, September 12, 2008 4:21 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

You should be able to add it anywhere inside the postbuild Target. What error 
did you get?

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Friday, September 12, 2008 11:38 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Tried adding "echo 
$(TargetDir)%(EmbeddedResourceWithCulture.Culture)\$(TargetName)$(TargetExt)" 
to my post build event and it caused build errors.

Where am I supposed to add "" in my Setup.wixproj to see it during build processing?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 8:33 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Ok, this is pretty straightforward then. In your postbuild step where you're 
using bin\$(Configuration) change it to this:

$(TargetDir)%(EmbeddedResourceWithCulture.Culture)\$(TargetName)$(TargetExt)

It's pretty long but will translate into the full path of each MSI produced by 
the build. You can test this out by sticking it in a Message task and seeing 
what happens:



The result in my test project is this:

  d:\projects\WixProject7\bin\Debug\en-us\WixProject7.msi
  d:\projects\WixProject7\bin\Debug\en-ca\WixProject7.msi

Let me know if that does (or doesn't!) work.

Neil

____
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Thursday, September 11, 2008 7:43 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Correct. Currently only have a reason to have a macro value for full path of 
msi files output in postbuild step.  Prebuild processing currently only 
involves strong name signing and sandcastle chm file generation prior to msi 
build that uses those bits.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 5:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Robert,

One follow-up question: do you need to know the path to the MSI files in the 
prebuild step? From what you write below it sounds like you only need it for 
postbuild. Prebuild is only about signing the assemblies that go into the MSI, 
correct? (It is very easy to give you the full paths to the built MSIs after 
build, but a bit trickier prebuild).

Neil

________
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Thursday, September 11, 2008 2:27 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

In prebuild events I execute a custom process that carries out a process that 
does full signing of all assemblies that were built using public key only delay 
signed build output.

In postbuild events I execute a custom process that carries out publisher 
signing of msi build output.  I also execute a robocopy command that copies our 
set of service deliverable specific automated distributed msi deployment 
processing xml to the same folder as the service deliverable msi build output.

With this new build output folder scheme this means that pre/postBuild steps 
that may have been using the $(TargetPath) macro value which is no longer valid 
now have to use a set of $(TargetDir)\$(TargetName) steps, e.g. 
$(TargetDir)en-us\$(Target

Re: [WiX-users] getting working v1.0 -> v1.0 minor update using msp & msi solutions pulled together

[Robert O'Brien]

In my case the service in question is one created and destroyed by a sql 
notification services 2005 "nscontrol.exe" command processing so my wix 
"Service1" component sources takes care of putting the necessary files in place 
and a set of related custom actions that use the sqlns05 "nscontrol.exe" 
utility take care of creating/destroying the service (see related excerpts 
below).   Is it possible to include the ServiceControl statement in my 
"Service1" component and condition it to do an stop prior to files being 
processed during (UPGRADINGPRODUCTCODE Or PATCH) activities and then started 
after the (UPGRADINGPRODUCTCODE Or PATCH) activities complete?



























!Services=2 
And ?Service1=2 And &Services=3 And $Service1=3
!Services=2 And ?Service1=2 And &Services=3 And 
$Service1=3

!Services=2 And ?Service1=2 And &Services=3 And 
$Service1=3
!Services=2 And ?Service1=2 And &Services=3 And 
$Service1=3

!Services=2 And ?Service1=2 And &Services=3 And 
$Service1=3
!Services=2 And ?Service1=2 And &Services=3 And 
$Service1=3

!Services=2 And ?Service1=2 And &Services=3 And 
$Service1=3
!Services=2 And ?Service1=2 And &Services=3 And 
$Service1=3

!Services=2 And ?Service1=2 And &Services=3 And 
$Service1=3
!Services=2 And ?Service1=2 And &Services=3 And 
$Service1=3

!Services=2 And ?Service1=2 And &Services=3 And 
$Service1=3
!Services=2 And ?Service1=2 And &Services=3 And 
$Service1=3

!Databases=2 And ?Database1=2 And &Databases=3 
And $Database1=3
!Databases=2 And ?Database1=2 And &Databases=3 
And $Database1=3


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Saturday, September 13, 2008 9:39 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] getting working v1.0 -> v1.0 minor update using msp & 
msi solutions pulled together

Robert O'Brien wrote:
> q1 - should I expect that minor upgrade using msp or msi can shuffle a new 
> dll into place that may be loaded in an active window service process w/o 
> that service needing to be stopped prior to the file update and restarted 
> afterwards or a reboot being required?
>

No.
> q2 - if I for safety reasons I do want to stop the windows service at start 
> of minor upgrade using msp or msi and restart it at the end of the minor 
> upgrade using msp or msi will adding the following customactions into my v1.1 
> msi and setting the sequencing to ??? accomplish that?
>

Don't use unnecessary custom actions. Use ServiceControl which is
already hooked into MSI's support for files-in-use detection.

--
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] using torch.exe -ax to enable use of admin install msi target and update input parameter values

[Robert O'Brien]

Attached are verbose log files from attempts to create expanded admin install 
drops using the following msiexec commands.

msiexec /a "d:\temp\v10Installer\MyServiceDeliverable.msi" /qn 
TARGETDIR=d:\temp\v10adminInstall /l*v d:\temp\v10adminInstall.log
msiexec /a "d:\temp\v11Installer\MyServiceDeliverable.msi" /qn 
TARGETDIR=d:\temp\v11adminInstall /l*v d:\temp\v11adminInstall.log

I tested creating an admin install using a similar msiexec command against 
another random server deliverable msi and it did successfully unpack all the 
files and produce an uncompressed version of the msi.

Any insights on what could be in my pretty typical wix3 sources generated msi's 
that would be preventing them from successfully creating the expected 
admininstall output where the contained files are unpacked which is needed for 
my torch patch installer related command to succeed?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Friday, September 12, 2008 11:29 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] using torch.exe -ax to enable use of admin install msi 
target and update input parameter values

The blog 
http://blogs.msdn.com/pmarcu/archive/2008/05/30/Patching-something-you-didnt-build-with-WiX-using-WiX-.aspx
 outlines using torch.exe -ax switch to enable use of admin install msi target 
and update input parameter values.

When I try and do that using the torch command syntax:

torch.exe -p -ax "obj\Debug\extractedAdminInstallBinaries" 
"obj\Debug\v1.0adminInstall\mydeliverable.msi" "obj\Debug\v1.1adminInstall\ 
mydeliverable.msi" -out "obj\Debug\mydeliverable.wixmst"

I get the error "torch.exe: error TRCH0258: The file 
'obj\Debug\v1.0adminInstall\mydeliverable\Databases\Database1\SQLScripts\AddSubscribers.sql'
 cannot be found."

If I install either of the target or the update msi's the AddSubscribers.sql 
file noted is successfully deployed so it would seem it is there.

I think this is happening because my admin install folders consist of nothing 
more than the uncompressed version of the original msi.   I'm just using 
"msiexec /a mydeliverable.msi /qn /l*v %temp%\ mydeliverableadminInstall.log" 
to generate my admin installs.   Is there some switch or orca or other solution 
I can used to get the required binary files expanded and included in my admin 
install output?

-
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] what setting causes current wix build output to land in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used to land

[Robert O'Brien]

Tried adding "echo 
$(TargetDir)%(EmbeddedResourceWithCulture.Culture)\$(TargetName)$(TargetExt)" 
to my post build event and it caused build errors.

Where am I supposed to add "" in my Setup.wixproj to see it during build processing?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 8:33 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Ok, this is pretty straightforward then. In your postbuild step where you're 
using bin\$(Configuration) change it to this:

$(TargetDir)%(EmbeddedResourceWithCulture.Culture)\$(TargetName)$(TargetExt)

It's pretty long but will translate into the full path of each MSI produced by 
the build. You can test this out by sticking it in a Message task and seeing 
what happens:



The result in my test project is this:

  d:\projects\WixProject7\bin\Debug\en-us\WixProject7.msi
  d:\projects\WixProject7\bin\Debug\en-ca\WixProject7.msi

Let me know if that does (or doesn't!) work.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Thursday, September 11, 2008 7:43 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Correct. Currently only have a reason to have a macro value for full path of 
msi files output in postbuild step.  Prebuild processing currently only 
involves strong name signing and sandcastle chm file generation prior to msi 
build that uses those bits.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 5:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Robert,

One follow-up question: do you need to know the path to the MSI files in the 
prebuild step? From what you write below it sounds like you only need it for 
postbuild. Prebuild is only about signing the assemblies that go into the MSI, 
correct? (It is very easy to give you the full paths to the built MSIs after 
build, but a bit trickier prebuild).

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Thursday, September 11, 2008 2:27 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

In prebuild events I execute a custom process that carries out a process that 
does full signing of all assemblies that were built using public key only delay 
signed build output.

In postbuild events I execute a custom process that carries out publisher 
signing of msi build output.  I also execute a robocopy command that copies our 
set of service deliverable specific automated distributed msi deployment 
processing xml to the same folder as the service deliverable msi build output.

With this new build output folder scheme this means that pre/postBuild steps 
that may have been using the $(TargetPath) macro value which is no longer valid 
now have to use a set of $(TargetDir)\$(TargetName) steps, e.g. 
$(TargetDir)en-us\$(TargetName).

I guess I was just thrown off by the assumption that there might be something 
like a default / language neutral culture which lands in the 
bin\$(Configuration) folder and only non-default / language neutral culture 
output lands in bin\$(Configuration)\ folder.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Sorry, my mistake. I looked at my changes to the WiX build process and you'll 
get the different output locations any time you have a localized build (one 
that has .wxl files in it).

What are you trying to do in your Pre- and Post-Build steps? Depending on what 
you are doing there may be existing things in the wix.targets file you can 
leverage (much like VS does) to make small tweaks to your targets that work 
with the output file locations.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of 

[WiX-users] using torch.exe -ax to enable use of admin install msi target and update input parameter values

[Robert O'Brien]

The blog 
http://blogs.msdn.com/pmarcu/archive/2008/05/30/Patching-something-you-didnt-build-with-WiX-using-WiX-.aspx
 outlines using torch.exe -ax switch to enable use of admin install msi target 
and update input parameter values.

When I try and do that using the torch command syntax:

torch.exe -p -ax "obj\Debug\extractedAdminInstallBinaries" 
"obj\Debug\v1.0adminInstall\mydeliverable.msi" "obj\Debug\v1.1adminInstall\ 
mydeliverable.msi" -out "obj\Debug\mydeliverable.wixmst"

I get the error "torch.exe: error TRCH0258: The file 
'obj\Debug\v1.0adminInstall\mydeliverable\Databases\Database1\SQLScripts\AddSubscribers.sql'
 cannot be found."

If I install either of the target or the update msi's the AddSubscribers.sql 
file noted is successfully deployed so it would seem it is there.

I think this is happening because my admin install folders consist of nothing 
more than the uncompressed version of the original msi.   I'm just using 
"msiexec /a mydeliverable.msi /qn /l*v %temp%\ mydeliverableadminInstall.log" 
to generate my admin installs.   Is there some switch or orca or other solution 
I can used to get the required binary files expanded and included in my admin 
install output?

-
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] How to create only installer for 32 Bit and 64 bit OS

[Robert O'Brien]

Since I know that everything I'm installing is managed code anyCpu build output 
I enabled this with my service deliverable wix sources using the following 
syntax.































  

 



   
   




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sandeep Gautam 
(HCL Technologies Ltd)
Sent: Thursday, September 11, 2008 7:39 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to create only installer for 32 Bit and 64 bit OS

Hi,

I want to create one common installer that will work for 32 Bit and 64 bit OS.
How can I do this?


Regards
Sandeep

-
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] what setting causes current wix build output to land in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used to land

[Robert O'Brien]

Correct. Currently only have a reason to have a macro value for full path of 
msi files output in postbuild step.  Prebuild processing currently only 
involves strong name signing and sandcastle chm file generation prior to msi 
build that uses those bits.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 5:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Robert,

One follow-up question: do you need to know the path to the MSI files in the 
prebuild step? From what you write below it sounds like you only need it for 
postbuild. Prebuild is only about signing the assemblies that go into the MSI, 
correct? (It is very easy to give you the full paths to the built MSIs after 
build, but a bit trickier prebuild).

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Thursday, September 11, 2008 2:27 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

In prebuild events I execute a custom process that carries out a process that 
does full signing of all assemblies that were built using public key only delay 
signed build output.

In postbuild events I execute a custom process that carries out publisher 
signing of msi build output.  I also execute a robocopy command that copies our 
set of service deliverable specific automated distributed msi deployment 
processing xml to the same folder as the service deliverable msi build output.

With this new build output folder scheme this means that pre/postBuild steps 
that may have been using the $(TargetPath) macro value which is no longer valid 
now have to use a set of $(TargetDir)\$(TargetName) steps, e.g. 
$(TargetDir)en-us\$(TargetName).

I guess I was just thrown off by the assumption that there might be something 
like a default / language neutral culture which lands in the 
bin\$(Configuration) folder and only non-default / language neutral culture 
output lands in bin\$(Configuration)\ folder.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Sorry, my mistake. I looked at my changes to the WiX build process and you'll 
get the different output locations any time you have a localized build (one 
that has .wxl files in it).

What are you trying to do in your Pre- and Post-Build steps? Depending on what 
you are doing there may be existing things in the wix.targets file you can 
leverage (much like VS does) to make small tweaks to your targets that work 
with the output file locations.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 11, 2008 1:43 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Thanks for the response.  I currently only have a single Resources\Strings.wxl 
in my project settings which has the Culture="en-us" attribute set.  Should I 
just remove that string resources file Culture attribute setting to get build 
output landing in bin\$(Configuration) again?

http://schemas.microsoft.com/wix/2006/localization";>

For now since we only build Language="1033" setup output getting msi and msp 
build output to land in bin\$(Configuration) again is super helpful in terms of 
TFS automated build processing where being able to have postBuild events simply 
reference $(OutDir) makes the desktop vstudio and tfs build agent server 
pre/postBuild event authoring more straight forward.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Robert,

This happens when you have multiple .wxl files in your project with different 
cultures in them. Setting the Cultures field in properties will control which 
languages get built, but the output will still go into the sub-folder (this 

[WiX-users] getting working v1.0 -> v1.0 minor update using msp & msi solutions pulled together

[Robert O'Brien]

Thanks for all the responses to my recent questions associated with getting 
working v1.0 -> v1.0 minor update using msp & msi solutions pulled together.

At this point I believe I have what should be working sources and build output 
to carry out a minor upgrade using both the msp & msi approaches.   i've 
attached my product, sequence, customaction and product patch sources if it is 
of any help to others trying to accomplish the same thing.  Below I also 
included the Patch.wixproj postBuild event processing I using to generate my 
patch build output in a tfs automated build friendly way to address current wix 
project settings support not available for patch msp build output.  For some 
reason the customaction/sequences steps that attempt to set the necessary 
reinstall and reinstallmode property settings for msp and msi minor upgrade 
processing scenarios without requiring you do pass values on the command line 
things don't work.  If I pass them from the command line, e.g.
msiexec /p "My Service Deliverable Patch.msp" /qb reinstall=all 
reinstallmode=omus /l* d:\temp\v10tov11patch.log
msiexec /i "My Service Deliverable.msi" /qb reinstall=all 
reinstallmode=vomus /l* d:\temp\v10tov11upgrade.log
then the msp update doesn't succeed but the msi update does.  Not sure what I 
got going on to cause the msp to not work even when required props are set 
using command line.

Some outstanding questions I have on the minor upgrade front.   I have a dll 
that I expect to be updated in both the msp and msi minor upgrade approach 
which in an existing v1.0 install is going to be loaded and running in a 
windows service process that will be in place as a result of the v1.0 install.

q1 - should I expect that minor upgrade using msp or msi can shuffle a new dll 
into place that may be loaded in an active window service process w/o that 
service needing to be stopped prior to the file update and restarted afterwards 
or a reboot being required?

q2 - if I for safety reasons I do want to stop the windows service at start of 
minor upgrade using msp or msi and restart it at the end of the minor upgrade 
using msp or msi will adding the following customactions into my v1.1 msi and 
setting the sequencing to ??? accomplish that?





Installed And PATCH or 
UPGRADE
Installed And 
PATCH or UPGRADE 
Installed And PATCH or 
UPGRADE
Installed And 
PATCH or UPGRADE 

q2 - to command line public property settings, other than REINSTALLl and 
REINSTALLMODE, have any relevance when processing a minor upgrade using msp or 
msi solutions?

-

move /y "$(TargetDir)en-us\$(TargetName).msi" 
"$(TargetDir)en-us\$(TargetName).pcp"

robocopy "\\rpbuildagent03\builds\RXP 
Eventing\v1.0adminInstall"
 "$(ProjectDir)obj\$(Configuration)\v1.0adminInstall" /mir /r:0

if not exist "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" md 
"$(ProjectDir)obj\$(Configuration)\v1.1adminInstall"

rem msiexec.exe /a "$(Setup.TargetDir)en-us\$(Setup.TargetFileName)" /qn 
TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l* 
"$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification 
Service.log"
if "$(IsDesktopBuild)" == "" msiexec.exe /a 
"$(SolutionDir)Setup\Setup\bin\$(Configuration)\en-us\RP Event Notification 
Service.msi" /qn TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" 
/l* "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification 
Service.log"

if "$(IsDesktopBuild)" == "false" msiexec.exe /a "$(OutDir)en-us\RP Event 
Notification Service.msi" /qn 
TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l* 
"$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification 
Service.log"

if exist "$(TargetDir)en-us\$(TargetName).log" del 
"$(TargetDir)en-us\$(TargetName).log"

rem "C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\MsiMsp.exe" -s 
"$(TargetDir)en-us\$(TargetName).pcp" -p "$(TargetDir)en-us\$(TargetName).msp" 
-l "$(TargetDir)en-us\$(TargetName).log"
pushd "$(TargetDir)en-us\" & "C:\Program Files\Microsoft 
SDKs\Windows\v6.0A\Bin\MsiMsp.exe" -s "$(TargetName).pcp" -p 
"$(TargetName).msp" -l "$(TargetName).log" & popd

cmd /c echo end processing setup post-build event command lines

-


-
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] is there a way to get current wix vs08 project extensions to output a patch msp?

[Robert O'Brien]

If I create a wix vs08 project containing a single Product.wxs with patch 
content and build I get one warning but otherwise it all builds.

When I look at the underlying candle and light commands they pretty much are 
exactly the same as the chm "Using Patch Creation Properties" outlined candle 
and light commands.

Specifically in the case of the candle command I get the "-dVersion=1.1.0.0" 
switch included using the project settings dialog.

In the case of the light command the only thing that is really difference is 
the "-out ..." switch file name extension.  For example by default the wix 
project template sets the "-out ..." switch to use a file that ends with ".msi" 
versus ".pcp".

Question - if the only thing different in the light command that gets applied 
using the current wix project templet is ".msi" versus ".pcp" then is the 
contents of the a file going to be right, in other words can I just rename the 
file in a postBuild event step in order to get the desired .pcp file that I can 
then run msimsp.exe against to produce my patch .msp file output.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Friday, September 05, 2008 10:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] is there a way to get current wix vs08 project 
extensions to output a patch msp?

Robert O'Brien wrote:
> is there a recommended approach to getting current wix vs08 project 
> extensions to output a patch msp?
>

Currently, Votive and the MSBuild tasks/targets don't support the WiX v3
patching tools. I don't know if they'll be supported as target types in v3.

--
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