[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

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 robert.obr...@microsoft.com:
 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

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 robert.obr...@microsoft.com:
  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

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

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 Deliverable 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.
iis:WebSite Id=DefaultWebSite SiteId=* Description=Default Web Site 
/

Switching it to the following works but then we have the iis:WebAddress port 80 
setting/expectation.
iis:WebSite Id=DefaultWebSite SiteId=* Description=Default Web Site
iis:WebAddress Id=http Port=80 /
/iis:WebSite

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 
robert.obr...@microsoft.commailto:robert.obr...@microsoft.com
To: 'tomtr...@artizan.commailto:tomtr...@artizan.com' 
tomtr...@artizan.commailto:tomtr...@artizan.com, 'General discussion for 
Windows Installer XML toolset.' 
wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net
Cc: Dmitry Frenkel 
dmitry.fren...@microsoft.commailto:dmitry.fren...@microsoft.com, Kiran 
Challa kicha...@microsoft.commailto: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

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 Deliverable 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.
iis:WebSite Id=DefaultWebSite SiteId=* Description=Default Web Site 
/

Switching it to the following works but then we have the iis:WebAddress port 80 
setting/expectation.
iis:WebSite Id=DefaultWebSite SiteId=* Description=Default Web Site
iis:WebAddress Id=http Port=80 /
/iis:WebSite

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

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

iis:WebSite Id=DefaultWebSite Description=Default Web Siteiis:WebAddress 
Id=http Port=80 //iis:WebSite
 
becomes just the following without the iis:WebAddress specifics?

iis:WebSite Id=DefaultWebSite SiteId=0 Description=Default Web 
Site/iis:WebSite
 
-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 robert.obr...@microsoft.com
To: 'wix-users@lists.sourceforge.net' wix-users@lists.sourceforge.net
Cc: Dmitry Frenkel dmitry.fren...@microsoft.com
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.

 iis:WebAppPool Id=efaultAppPool Name=DefaultAppPool /
 iis:WebSite Id=efaultWebSite Description=Default Web Site
 iis:WebAddress Id=ttp Port=80 /
 /iis:WebSite

 Component Id=ite1AppPool Guid=ACF34F1A-5778-4A98-8AF9

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 robert.obr...@microsoft.com
To: 'General discussion for Windows Installer XML toolset.'   
 wix-users@lists.sourceforge.net, 'tomtr...@artizan.com'   
 tomtr...@artizan.com, Kiran Challa kicha...@microsoft.com
Cc: Dmitry Frenkel dmitry.fren...@microsoft.com
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.

 iis:WebSite IdÞfaultWebSite Description=Default Web Siteiis:WebAddress 
 Id=http Port=80 //iis:WebSite
  
 becomes just the following without the iis:WebAddress specifics?

 iis:WebSite IdÞfaultWebSite SiteId=0 Description=Default Web 
 Site/iis:WebSite
  
 -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

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

iis:WebAppPool Id=DefaultAppPool Name=DefaultAppPool /
iis:WebSite Id=DefaultWebSite Description=Default Web Site
iis:WebAddress Id=http Port=80 /
/iis:WebSite

Component Id=Site1AppPool Guid=ACF34F1A-5778-4A98-8AF9-7CF38A81AF6F 
KeyPath=yes Permanent=yes
   iis:WebAppPool Id=Site1AppPool Name=Site1AppPool 
Identity=networkService /
/Component
Component Id=Site1 Guid=35BD9B02-7833-4CCE-9BC6-D8B8B49E5347 
Permanent=yes
   File Id=InstalledSite1.txt Name=InstalledSite1.txt 
Source=Resources\InstalledComponent.txt KeyPath=yes /
   !-- TODO: copy Site1Dir files into place here --
   iis:WebSite Id=Site1WebSite Description=Site1 Web Site 
Directory=Site1Dir
   iis:WebApplication Id=Site1App Name=Site1 Application 
WebAppPool=Site1AppPool Isolation=medium /
   iis:WebAddress Id=Site1WebAddress Port=80 /
   iis:WebAddress Id=Site1WebAddressSsl Port=443 Secure=yes /
   /iis:WebSite
/Component

Component Id=Site2AppPool Guid=510AD484-C0E6-441D-9E07-8B583D2207CA 
KeyPath=yes Permanent=yes
   iis:WebAppPool Id=Site2AppPool Name=Site2AppPool 
Identity=networkService /
/Component
Component Id=Site2 Guid=AFBE602C-550C-43DB-A36A-BCEC66569967 
Permanent=yes
   File Id=InstalledSite2.txt Name=InstalledSite2.txt 
Source=Resources\InstalledComponent.txt KeyPath=yes /
   !-- TODO: copy Site2Dir files into place here --
   iis:WebSite Id=Site2WebSite Description=Site2 Web Site 
Directory=Site2Dir
   iis:WebApplication Id=Site2App Name=Site2 Application 
WebAppPool=Site2AppPool Isolation=medium /
   iis:WebAddress Id=Site2WebAddress Port=80 /
   iis:WebAddress Id=Site2WebAddressSsl Port=443 Secure=yes /
   /iis:WebSite
/Component
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] 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 robert.obr...@microsoft.com
 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.
Feature Id=Databases Title=!(loc.Databases) Level=1
Condition Level=0DATABASES=0/Condition
 versus what I had
Feature Id=Databases Title=!(loc.Databases) Level=0
Condition Level=1DATABASES=1/Condition

 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

 !-- new wix3 way for patch generation --
Patch AllowRemoval=yes Description=!(loc.ProductName)
 Manufacturer=!(loc.ProductName) MoreInfoURL=!(loc.ProductUrl)
 Classification=Update DisplayName=!(loc.ProductName)

Media Id=5000 Cabinet=Rtm.cab
PatchBaseline Id=Rtm /
/Media

PatchFamilyRef Id=v11ReleasePatchFamily/
/Patch

Fragment
PatchFamily Id=v11ReleasePatchFamily Version=1.0.0.0
 Supersede=yes
ComponentRef Id=Service1 /
/PatchFamily
/Fragment

 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

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.  smile/

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

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=detailaid=2655321group_id=105970atid=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=yesin 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

[WiX-users] is there a way to get a dll.config file deployed along side a gac destined file, e.g. a File .../ 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 File .../ 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] is there a way to get a dll.config file deployed along side a gac destined file, e.g. a File .../ 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 == project | properties | Settings | 
Settings.Default.MySettingsDesignerCreatedAndMaintainedRunTimeValue = 12345
settings api == some type implementation.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.

Component Id=Sdk1Gac14 Guid=A6D64010-D181-40BF-9ABC-BA15633E1F45
 File Id=Sdk1GacDataEntities.Providers.dll 
Name=MyGacDestinedAssembly.dll 
Source=$(var.MyGacDestinedAssembly.TargetPath)
 Assembly=.net KeyPath=yes /
/Component
/DirectoryRef

DirectoryRef Id=GacMsilDir
Directory Id=Sdk1Gac14Dir Name=MyGacDestinedAssembly
Directory Id=Sdk1Gac14VersionTokenDir 
Name=2.0.0.0__31bf3856ad364e35
Component Id=Sdk1Gac14DllCfg Guid=*
File Id=MyGacDestinedAssembly.dll.config 
Name=MyGacDestinedAssembly.dll.config 
Source=$(var.MyGacDestinedAssembly.TargetPath).config KeyPath=yes /
/Component
/Directory
/Directory
/DirectoryRef


CustomAction Id=SetSdk1Gac14DllCfg Property=RunSdk1Gac14DllCfg 
Value=quot;[WindowsFolder]system32\cmd.exequot; /c copy 
quot;[#Site1Vdir3BinMyGacDestinedAssembly.dll.config]quot; 
quot;[Sdk1Gac14VersionTokenDir]quot; / 
CustomAction Id=RunSdk1Gac14DllCfg BinaryKey=WixCA DllEntry=CAQuietExec 
Execute=deferred Return=ignore /

Custom Action=SetSdk1Gac14DllCfg After=MsiPublishAssemblies!Sdk1=2 And 
amp;Sdk1=3 And ?Sdk1Gac14=2 And $Sdk1Gac14=3/Custom
Custom Action=RunSdk1Gac14DllCfg After=SetSdk1Gac14DllCfg!Sdk1=2 And 
amp;Sdk1=3 And ?Sdk1Gac14=2 And $Sdk1Gac14=3/Custom


-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 File .../ 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 File .../ 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 File .../ 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

[WiX-users] can I expect that a ServiceControl ... / 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 ServiceControl Id=BtsSvc 
Name=BTSSvc$BizTalkServerApplication Start=both Stop=both Wait=no / 
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] 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=yesin 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

Property Id=DATABASESHOST Value=localhost

sql:SqlDatabase Id=MasterDatabase Database=master
Server=[DATABASESHOST] /

sql:SqlDatabase Id=Database1 Database=MyDeliverableDatabase
Server=[DATABASESHOST] /

sql:SqlString Id=CreateLoginNetworkServiceDatabase1
SqlDb=MasterDatabase SQL=create login [\[]NT AUTHORITY\NETWORK
SERVICE[\]] from windows ContinueOnError=yes ExecuteOnInstall=yes
/

sql:SqlString Id=CreateUserNetworkServiceDatabase1 SqlDb=Database1
SQL=create user [\[]NT AUTHORITY\NETWORK SERVICE[\]] for login [\[]NT
AUTHORITY\NETWORK SERVICE[\]] ContinueOnError=yes
ExecuteOnInstall=yes /

sql:SqlString Id=AddRoleMembershipNetworkServiceDatabase1
SqlDb=Database1 SQL=sp_addrolemember 'NSRunService', 'NT
AUTHORITY\NETWORK SERVICE' ContinueOnError=yes ExecuteOnInstall=yes
/

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?

Property Id=DATABASESHOSTNAME Value=localhost

Property Id=DATABASESLOGINLOCALACCOUNT Value=NT AUTHORITY\NETWORK
SERVICE /

sql:SqlDatabase Id=Master Database=master
Server=[DATABASESHOSTNAME] /

sql:SqlDatabase Id=Database1 Database=MyDeliverableDatabase
Server=[DATABASESHOSTNAME] /

sql:SqlString Id=Database1CreateLoginLocalAccount SqlDb=Master
Sequence=1 SQL=exec('create login
[\[][DATABASESLOGINLOCALACCOUNT][\]] from windows')
ExecuteOnInstall=yes RollbackOnUninstall=yes ContinueOnError=yes
/

sql:SqlString Id=Database1CreateUserLocalAccount SqlDb=Database1
Sequence=2 SQL=exec('create user [\[][DATABASESLOGINLOCALACCOUNT][\]]
for login [\[][DATABASESLOGINLOCALACCOUNT][\]]') ExecuteOnInstall=yes
RollbackOnUninstall=yes ContinueOnError=yes /

/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

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

Component Id=Sdk1Gac14 Guid=A6D64010-D181-40BF-9ABC-BA15633E1F45
 File Id=Sdk1GacDataEntities.Providers.dll 
Name=MyGacDestinedAssembly.dll 
Source=$(var.MyGacDestinedAssembly.TargetPath)
 Assembly=.net KeyPath=yes /
/Component
/DirectoryRef

DirectoryRef Id=GacMsilDir
Directory Id=Sdk1Gac14Dir Name=MyGacDestinedAssembly
Directory Id=Sdk1Gac14VersionTokenDir 
Name=2.0.0.0__31bf3856ad364e35
Component Id=Sdk1Gac14DllCfg Guid=*
File Id=MyGacDestinedAssembly.dll.config 
Name=MyGacDestinedAssembly.dll.config 
Source=$(var.MyGacDestinedAssembly.TargetPath).config KeyPath=yes /
/Component
/Directory
/Directory
/DirectoryRef


CustomAction Id=SetSdk1Gac14DllCfg Property=RunSdk1Gac14DllCfg 
Value=quot;[WindowsFolder]system32\cmd.exequot; /c copy 
quot;[#Site1Vdir3BinMyGacDestinedAssembly.dll.config]quot; 
quot;[Sdk1Gac14VersionTokenDir]quot; /
CustomAction Id=RunSdk1Gac14DllCfg BinaryKey=WixCA DllEntry=CAQuietExec 
Execute=deferred Return=ignore /

Custom Action=SetSdk1Gac14DllCfg After=MsiPublishAssemblies!Sdk1=2 And 
amp;Sdk1=3 And ?Sdk1Gac14=2 And $Sdk1Gac14=3/Custom
Custom Action=RunSdk1Gac14DllCfg After=SetSdk1Gac14DllCfg!Sdk1=2 And 
amp;Sdk1=3 And ?Sdk1Gac14=2 And $Sdk1Gac14=3/Custom



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

CustomAction Id=SetSdk1Gac14DllCfg Property=RunSdk1Gac14DllCfg 
Value=quot;[WindowsFolder]system32\cmd.exequot; /c copy 
quot;[#Site1Vdir3BinMyGacDestinedAssembly.dll.config]quot; 
quot;[Sdk1Gac14VersionTokenDir]quot; /
CustomAction Id=RunSdk1Gac14DllCfg BinaryKey=WixCA DllEntry=CAQuietExec 
Execute=deferred Return=ignore /

Custom Action=SetSdk1Gac14DllCfg After=MsiPublishAssemblies!Sdk1=2 And 
amp;Sdk1=3 And ?Sdk1Gac14=2 And $Sdk1Gac14=3/Custom
Custom Action=RunSdk1Gac14DllCfg After=SetSdk1Gac14DllCfg!Sdk1=2 And 
amp;Sdk1=3 And ?Sdk1Gac14=2 And $Sdk1Gac14=3/Custom

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.

Component Id=Sdk1Gac14 Guid=A6D64010-D181-40BF-9ABC-BA15633E1F45
 File Id=Sdk1GacDataEntities.Providers.dll 
Name=MyGacDestinedAssembly.dll 
Source=$(var.MyGacDestinedAssembly.TargetPath)
 Assembly=.net KeyPath=yes /
 !--File Id=Sdk1Gac MyGacDestinedAssembly.dll.config 
Name=MyGacDestinedAssembly.dll.config 
Source=$(var.MyGacDestinedAssembly.TargetPath).config
 Assembly=no /--
/Component
/DirectoryRef

!-- note - using a SetSdk1Gac14DllCfg/RunSdk1Gac14DllCfg custom actions so we 
can sequence this to happen after InstallFiles does gac dll deployments.  This 
was happening
before then previously and as a result file was being deleted by gac dll 
deployment step --
DirectoryRef Id=GacMsilDir
Directory Id=Sdk1Gac14Dir Name=MyGacDestinedAssembly
Directory Id=Sdk1Gac14VersionTokenDir 
Name=2.0.0.0__31bf3856ad364e35
Component Id=Sdk1Gac14DllCfg Guid=*
File Id=MyGacDestinedAssembly.dll.config 
Name=MyGacDestinedAssembly.dll.config 
Source=$(var.MyGacDestinedAssembly.TargetPath).config KeyPath=yes /
/Component
/Directory
/Directory
/DirectoryRef


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

Component Id=Sdk1Gac14 Guid=A6D64010-D181-40BF-9ABC-BA15633E1F45
 File Id=Sdk1GacDataEntities.Providers.dll 
Name=MyGacDestinedAssembly.dll 
Source=$(var.MyGacDestinedAssembly.TargetPath)
 Assembly=.net KeyPath=yes /
 !--File Id=Sdk1Gac MyGacDestinedAssembly.dll.config 
Name=MyGacDestinedAssembly.dll.config 
Source=$(var.MyGacDestinedAssembly.TargetPath).config
 Assembly=no /--
/Component
/DirectoryRef

!-- note - using a SetSdk1Gac14DllCfg/RunSdk1Gac14DllCfg custom actions so we 
can sequence this to happen after InstallFiles does gac dll deployments.  This 
was happening
before then previously and as a result file was being deleted by gac dll 
deployment step --
DirectoryRef Id=GacMsilDir
Directory Id=Sdk1Gac14Dir Name=MyGacDestinedAssembly
Directory Id=Sdk1Gac14VersionTokenDir 
Name=2.0.0.0__31bf3856ad364e35
Component Id=Sdk1Gac14DllCfg Guid=*
File Id=MyGacDestinedAssembly.dll.config 
Name=MyGacDestinedAssembly.dll.config 
Source=$(var.MyGacDestinedAssembly.TargetPath).config KeyPath=yes /
/Component
/Directory
/Directory
/DirectoryRef


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

 Component Id=Sdk1Gac14 
Guid=A6D64010-D181-40BF-9ABC-BA15633E1F45
File Id=Sdk1GacDataEntities.Providers.dll 
Name=Microsoft.IT.RelationshipManagement.EventNotification.DataEntities.Providers.dll
 Source=$(var.DataEntityProviders.TargetPath)
Assembly=.net KeyPath=yes /
!--File Id=Sdk1GacDataEntities.Providers.dll.config 
Name=Microsoft.IT.RelationshipManagement.EventNotification.DataEntities.Providers.dll.config
 Source=$(var.DataEntityProviders.TargetPath).config
Assembly=no /--
 /Component
/DirectoryRef

!-- note - using a SetSdk1Gac14DllCfg/RunSdk1Gac14DllCfg custom 
actions so we can sequence this to happen after InstallFiles does gac dll 
deployments.  This was happening
before then previously and as a result file was being deleted by 
gac dll deployment step --
DirectoryRef Id=GacMsilDir
Directory Id=Sdk1Gac14Dir Name=MyGacDestinedAssembly
Directory Id=Sdk1Gac14VersionTokenDir 
Name=2.0.0.0__31bf3856ad364e35
Component Id=Sdk1Gac14DllCfg Guid=*
File Id= MyGacDestinedAssembly.dll.config Name= 
MyGacDestinedAssembly.dll.config Source=$(var. 
MyGacDestinedAssembly.TargetPath).config KeyPath=yes /
/Component
/Directory
/Directory
/DirectoryRef


--
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 Custom Action=ExecXmlFile be more relevant than Custom 
Action=SchedXmlFile for ensuring my util:XmlFile settings get applied just 
before my CAQuietExec deferred custom action that needs those settings in place?

From: Robert O'Brien
Sent: Friday, February 13, 2009 1:46 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: i need util:XmlFile associated SchedXmlFile action to happen before a 
specific CAQuietExec deferred custom action . . .

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?

Custom Action=SchedXmlFile Before=SetMyCaQeAction!Database1=2 And 
amp;Database1=3 And ?Database1=2 And $Database1=3/Custom

Custom Action=SetMyCaQeAction Before=RunMyCaQeAction!Database1=2 And 
amp;Database1=3 And ?Database1=2 And $Database1=3/Custom
Custom Action=RunMyCaQeAction Before=InstallSqlData!Database1=2 And 
amp;Database1=3 And ?Database1=2 And $Database1=3/Custom


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

Custom Action=SchedXmlFile Before=SetMyCaQeAction!Database1=2 And 
amp;Database1=3 And ?Database1=2 And $Database1=3/Custom

Custom Action=SetMyCaQeAction Before=RunMyCaQeAction!Database1=2 And 
amp;Database1=3 And ?Database1=2 And $Database1=3/Custom
Custom Action=RunMyCaQeAction Before=InstallSqlData!Database1=2 And 
amp;Database1=3 And ?Database1=2 And $Database1=3/Custom


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

Property Id=DATABASESHOST Value=localhost

sql:SqlDatabase Id=MasterDatabase Database=master Server=[DATABASESHOST] 
/

sql:SqlDatabase Id=Database1 Database=MyDeliverableDatabase 
Server=[DATABASESHOST] /

sql:SqlString Id=CreateLoginNetworkServiceDatabase1 SqlDb=MasterDatabase 
SQL=create login [\[]NT AUTHORITY\NETWORK SERVICE[\]] from windows 
ContinueOnError=yes ExecuteOnInstall=yes /

sql:SqlString Id=CreateUserNetworkServiceDatabase1 SqlDb=Database1 
SQL=create user [\[]NT AUTHORITY\NETWORK SERVICE[\]] for login [\[]NT 
AUTHORITY\NETWORK SERVICE[\]] ContinueOnError=yes ExecuteOnInstall=yes /

sql:SqlString Id=AddRoleMembershipNetworkServiceDatabase1 SqlDb=Database1 
SQL=sp_addrolemember 'NSRunService', 'NT AUTHORITY\NETWORK SERVICE' 
ContinueOnError=yes ExecuteOnInstall=yes /

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?

Property Id=DATABASESHOSTNAME Value=localhost

Property Id=DATABASESLOGINLOCALACCOUNT Value=NT AUTHORITY\NETWORK SERVICE 
/

sql:SqlDatabase Id=Master Database=master Server=[DATABASESHOSTNAME] /

sql:SqlDatabase Id=Database1 Database=MyDeliverableDatabase 
Server=[DATABASESHOSTNAME] /

sql:SqlString Id=Database1CreateLoginLocalAccount SqlDb=Master 
Sequence=1 SQL=exec('create login [\[][DATABASESLOGINLOCALACCOUNT][\]] from 
windows') ExecuteOnInstall=yes RollbackOnUninstall=yes 
ContinueOnError=yes /

sql:SqlString Id=Database1CreateUserLocalAccount SqlDb=Database1 
Sequence=2 SQL=exec('create user [\[][DATABASESLOGINLOCALACCOUNT][\]] for 
login [\[][DATABASESLOGINLOCALACCOUNT][\]]') ExecuteOnInstall=yes 
RollbackOnUninstall=yes ContinueOnError=yes /

/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

Property Id=DATABASESHOST Value=localhost

sql:SqlDatabase Id=MasterDatabase Database=master Server=[DATABASESHOST] 
/

sql:SqlDatabase Id=Database1 Database=MyDeliverableDatabase 
Server=[DATABASESHOST] /

sql:SqlString Id=CreateLoginNetworkServiceDatabase1 SqlDb=MasterDatabase 
SQL=create login [\[]NT AUTHORITY\NETWORK SERVICE[\]] from windows 
ContinueOnError=yes ExecuteOnInstall=yes /

sql:SqlString Id=CreateUserNetworkServiceDatabase1 SqlDb=Database1 
SQL=create user [\[]NT AUTHORITY\NETWORK SERVICE[\]] for login [\[]NT 
AUTHORITY\NETWORK SERVICE[\]] ContinueOnError=yes ExecuteOnInstall=yes /

sql:SqlString Id=AddRoleMembershipNetworkServiceDatabase1 SqlDb=Database1 
SQL=sp_addrolemember 'NSRunService', 'NT AUTHORITY\NETWORK SERVICE' 
ContinueOnError=yes ExecuteOnInstall=yes /

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?

Property Id=DATABASESHOSTNAME Value=localhost

Property Id=DATABASESLOGINLOCALACCOUNT Value=NT AUTHORITY\NETWORK SERVICE 
/

sql:SqlDatabase Id=Master Database=master Server=[DATABASESHOSTNAME] /

sql:SqlDatabase Id=Database1 Database=MyDeliverableDatabase 
Server=[DATABASESHOSTNAME] /

sql:SqlString Id=Database1CreateLoginLocalAccount SqlDb=Master 
Sequence=1 SQL=exec('create login [\[][DATABASESLOGINLOCALACCOUNT][\]] from 
windows') ExecuteOnInstall=yes RollbackOnUninstall=yes 
ContinueOnError=yes /

sql:SqlString Id=Database1CreateUserLocalAccount SqlDb=Database1 
Sequence=2 SQL=exec('create user [\[][DATABASESLOGINLOCALACCOUNT][\]] for 
login [\[][DATABASESLOGINLOCALACCOUNT][\]]') ExecuteOnInstall=yes 
RollbackOnUninstall=yes ContinueOnError=yes /

/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

Property Id=DATABASESHOST Value=localhost

sql:SqlDatabase Id=MasterDatabase Database=master Server=[DATABASESHOST] 
/

sql:SqlDatabase Id=Database1 Database=MyDeliverableDatabase 
Server=[DATABASESHOST] /

sql:SqlString Id=CreateLoginNetworkServiceDatabase1 SqlDb=MasterDatabase 
SQL=create login [\[]NT AUTHORITY\NETWORK SERVICE[\]] from windows 
ContinueOnError=yes ExecuteOnInstall=yes /

sql:SqlString Id=CreateUserNetworkServiceDatabase1 SqlDb=Database1 
SQL=create user [\[]NT AUTHORITY\NETWORK SERVICE[\]] for login [\[]NT 
AUTHORITY\NETWORK SERVICE[\]] ContinueOnError=yes ExecuteOnInstall=yes /

sql:SqlString Id=AddRoleMembershipNetworkServiceDatabase1 SqlDb=Database1 
SQL=sp_addrolemember 'NSRunService', 'NT AUTHORITY\NETWORK SERVICE' 
ContinueOnError=yes ExecuteOnInstall=yes /

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?

Property Id=DATABASESHOSTNAME Value=localhost

Property Id=DATABASESLOGINLOCALACCOUNT Value=NT AUTHORITY\NETWORK SERVICE 
/

sql:SqlDatabase Id=Master Database=master Server=[DATABASESHOSTNAME] /

sql:SqlDatabase Id=Database1 Database=MyDeliverableDatabase 
Server=[DATABASESHOSTNAME] /

sql:SqlString Id=Database1CreateLoginLocalAccount SqlDb=Master 
Sequence=1 SQL=exec('create login [\[][DATABASESLOGINLOCALACCOUNT][\]] from 
windows') ExecuteOnInstall=yes RollbackOnUninstall=yes 
ContinueOnError=yes /

sql:SqlString Id=Database1CreateUserLocalAccount SqlDb=Database1 
Sequence=2 SQL=exec('create user [\[][DATABASESLOGINLOCALACCOUNT][\]] for 
login [\[][DATABASESLOGINLOCALACCOUNT][\]]') ExecuteOnInstall=yes 
RollbackOnUninstall=yes ContinueOnError=yes /

/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 util:XmlFile or util:XmlConfig or util:??? have some way of just doing a token search and replace throughout an entire file?

[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 util:XmlFile or util:XmlConfig or util:??? 
have some way of just doing a token search and replace throughout an entire 
file?

No.

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com]
Sent: Tuesday, December 09, 2008 16:37
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] does util:XmlFile or util:XmlConfig or util:??? have 
some way of just doing a token search and replace throughout an entire file?

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 util:XmlFile or util:XmlConfig or util:??? have some way of just doing 
a token search and replace throughout an entire file?

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

[WiX-users] does util:XmlFile or util:XmlConfig or util:??? have some way of just doing a token search and replace throughout an entire file?

[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 util:XmlFile or util:XmlConfig or util:??? have some way of just doing 
a token search and replace throughout an entire file?

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

Feature Id=MainApplication Title=Main Application Level=1
ComponentRef Id=MmcSnapin.dll /
ComponentRef Id=Configuration.dll /
/Feature

!-- The Install and Modify Feature Add actions --
CustomAction Id=SetInstallUtilCmdLine64 Property=InstallUtilCmdLine64
Value=quot;[INSTALLUTIL64]quot; 
quot;[APPLICATIONROOTDIRECTORY]\Company.Deliverable.UI.MmcSnapin.dllquot;  /
CustomAction Id=InstallUtilCmdLine64 BinaryKey=WixCA 
DllEntry=CAQuietExec Execute=deferred Return=check/

!-- The Rollback, Modify Feature Remove and Uninstall actions --
CustomAction Id=SetUnInstallUtilCmdLine64 Property=UnInstallUtilCmdLine64
Value=quot;[INSTALLUTIL64]quot; /u 
quot;[APPLICATIONROOTDIRECTORY]\Company.Deliverable..UI.MmcSnapin.dllquot;  
/
CustomAction Id=UnInstallUtilCmdLine64 BinaryKey=WixCA 
DllEntry=CAQuietExec Execute=deferred Return=check/

InstallExecuteSequence
  Custom Action=SetInstallUtilCmdLine64 After=InstallFiles /
  Custom Action=InstallUtilCmdLine64 After=SetInstallUtilCmdLine64 
InstallUtilCmdLine64 And !MainApplication=2 and ampMainApplication=3/Custom

  Custom Action=SetUnInstallUtilCmdLine64 Before=UnInstallUtilCmdLine64 /
  Custom Action=UnInstallUtilCmdLine64 Before=RemoveFiles 
UnInstallUtilCmdLine64 And !MainApplication=3 and 
ampMainApplication=2/Custom
/InstallExecuteSequence

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

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?

Product Id=PUT-GUID-HERE
 Name=!(loc.ProductName)
 Language=1033 Version=3.0.4805.0
 Manufacturer=!(loc.ProductManufacturer)
 UpgradeCode= PUT-UPGRADECODE-GUID-HERE 

Upgrade Id=PUT-UPGRADECODE-GUID-HERE
UpgradeVersion Minimum=3.0.4805.0 IncludeMinimum=yes OnlyDetect=yes 
Property=NEWERVERSIONDETECTED /
UpgradeVersion Minimum=3.0.4513.0 IncludeMinimum=yes 
Maximum=3.0.4805.0 IncludeMaximum=no Property=OLDERVERSIONDETECTED /
/Upgrade

!-- for msi major upgrade processing --
CustomAction Id=SetMsiMajorUpgradePreventDowngradingError Error=A newer 
version of [ProductName] is already installed. /
CustomAction Id=SetMsiMajorUpgradeReInstallProperty Property=REINSTALL 
Value=ALL /
CustomAction Id=SetMsiMajorUpgradeReInstallModeProperty 
Property=REINSTALLMODE Value=vomus /

InstallUISequence
!-- for msi major upgrade processing --
Custom Action=SetMsiMajorUpgradePreventDowngradingError 
After=FindRelatedProductsNEWERVERSIONDETECTED/Custom

InstallExecuteSequence
!-- for msi major upgrade processing --
Custom Action=SetMsiMajorUpgradePreventDowngradingError 
After=FindRelatedProductsNEWERVERSIONDETECTED/Custom
Custom Action=SetMsiMajorUpgradeReInstallProperty 
After=FindRelatedProductsOLDERVERSIONDETECTED/Custom
Custom Action=SetMsiMajorUpgradeReInstallModeProperty 
After=FindRelatedProductsOLDERVERSIONDETECTED/Custom
RemoveExistingProducts 
After=InstallFinalizeOLDERVERSIONDETECTED/RemoveExistingProducts


-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=105970package_id=16release_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

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?

InstallUISequence
CostFinalize Before=LaunchConditions /
!--LaunchConditions After=CostFinalize /--
InstallExecuteSequence
CostFinalize Before=LaunchConditions /
!--LaunchConditions After=CostFinalize /--
The CostFinalize element contains an unexpected attribute 'Before'.
!-- ICE27: 'LaunchConditions' Action in InstallExecuteSequence table in wrong 
place. Current: Selection, Correct: Search --


!-- for prerequisites that require checking feature and/or component state 
and action conditions --
CustomAction Id=PrerequisitesExSql08 Error=[ProductName] requires Sql08 
to be installed. /
CustomAction Id=PrerequisitesExSql05Ns Error=[ProductName] requires 
Sql05 Notification Services to be installed. /
CustomAction Id=PrerequisitesExSql05 Error=[ProductName] requires Sql05 
to be installed. /
CustomAction Id=PrerequisitesExSso09AndBts09 Error=[ProductName] 
requires Sso09 and Bts09 to be installed. /

InstallUISequence
!-- for prerequisites that require checking feature and/or component state 
and action conditions  --
Custom Action=PrerequisitesExSql08 After=CostFinalize!Databases=2 And 
amp;Databases=3 And Not SQL08DIR/Custom
!--Custom Action=PrerequisitesExSql05Ns 
After=CostFinalize!Databases=2 And amp;Databases=3 And Not 
SQL05NSDIR/Custom
Custom Action=PrerequisitesExSql05 After=CostFinalize!Databases=2 And 
amp;Databases=3 And Not SQL05DIR/Custom--
Custom Action=PrerequisitesExSso09AndBts09 
After=CostFinalize!Services=2 And amp;Services=3 And Not SSO09DIR And Not 
BTS09DIR/Custom

InstallExecuteSequence
!-- for prerequisites that require checking feature and/or component state 
and action conditions  --
Custom Action=PrerequisitesExSql08 After=CostFinalize!Databases=2 And 
amp;Databases=3 And Not SQL08DIR/Custom
!--Custom Action=PrerequisitesExSql05Ns 
After=CostFinalize!Databases=2 And amp;Databases=3 And Not 
SQL05NSDIR/Custom
Custom Action=PrerequisitesExSql05 After=CostFinalize!Databases=2 And 
amp;Databases=3 And Not SQL05DIR/Custom--
Custom Action=PrerequisitesExSso09AndBts09 
After=CostFinalize!Services=2 And amp;Services=3 And Not SSO09DIR And Not 
BTS09DIR/Custom

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

 Condition Message=[ProductName] requires Sql08 to be installed.
 Installed Or (!Databases=2 And amp;Databases=3 And SQL08DIR)
 /Condition

 -
 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=100url=/
 ___
 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=100url

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
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=105970package_id=16release_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

[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

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

Condition Message=[ProductName] requires Sql08 to be installed.
Installed Or (!Databases=2 And amp;Databases=3 And SQL08DIR)
/Condition

-
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=100url=/
___
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=100url=/
___
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:
util:XmlFile Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector 
File=[NetFramework20ConfigDir]machine.config

ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions
Name=add Value=name=quot;enableBizTalkHeaderInspectorquot; 
type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot;
Action=createElement /

util:XmlConfig Id=RemoveBehaviorExtensionsEnableBizTalkHeaderInspector 
File=[NetFramework20ConfigDir]machine.config

ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions

VerifyPath=/configuration/system.serviceModel/extensions/behaviorExtensions/[EMAIL
 PROTECTED]quot;enableBizTalkHeaderInspectorquot; amp;amp; 
@type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot;[\]]
Action=delete Node=element On=uninstall /

To try and get this new add / element created during install but finding that 
no machine.config changes exist after setup completes.
configuration
system.serviceModel
extensions
   behaviorExtensions
   .
   . .
   . . .
   add name=enableBizTalkHeaderInspector 
type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=e2c282dc0883bc94 /
   /behaviorExtensions

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=100url=/
___
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.


util:XmlConfig Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector 
File=[NetFramework20ConfigDir]machine.config

ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions
Action=create Node=document On=install![CDATA[
!-- this line was added by rxp eventing v2.0 service deliverable installer 
--
add name=enableBizTalkHeaderInspector 
type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=31bf3856ad364e35/
]]/util:XmlConfig


-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:
util:XmlFile Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector 
File=[NetFramework20ConfigDir]machine.config

ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions
Name=add Value=name=quot;enableBizTalkHeaderInspectorquot; 
type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot;
Action=createElement /

util:XmlConfig Id=RemoveBehaviorExtensionsEnableBizTalkHeaderInspector 
File=[NetFramework20ConfigDir]machine.config

ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions

VerifyPath=/configuration/system.serviceModel/extensions/behaviorExtensions/[EMAIL
 PROTECTED]quot;enableBizTalkHeaderInspectorquot; amp;amp; 
@type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot;[\]]
Action=delete Node=element On=uninstall /

To try and get this new add / element created during install but finding that 
no machine.config changes exist after setup completes.
configuration
system.serviceModel
extensions
   behaviorExtensions
   .
   . .
   . . .
   add name=enableBizTalkHeaderInspector 
type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=e2c282dc0883bc94 /
   /behaviorExtensions

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=100url=/
___
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=100url=/
___
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.

PropertyRef Id=NETFRAMEWORK20INSTALLROOTDIR /

Directory Id=NETFRAMEWORK20INSTALLROOTDIR
Directory Id=NetFramework20ConfigDir Name=CONFIG /
/Directory

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.
Property Id=NFX20INSTALLROOTDIR
RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw 
Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot
DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 
Depth=0 /
/RegistrySearch
/Property
Property Id=NFX20X86INSTALLROOTDIR
RegistrySearch Id=NfxX86InstallRootForNetfx20Search Type=raw 
Root=HKLM Key=Software\Wow6432Node\Microsoft\.NETFramework 
Name=InstallRoot
DirectorySearch Id=Nfx20X86InstallRootSearch Path=v2.0.50727 
Depth=0 /
/RegistrySearch
/Property


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


util:XmlConfig Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector 
File=[NetFramework20ConfigDir]machine.config

ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions
Action=create Node=document On=install![CDATA[
!-- this line was added by rxp eventing v2.0 service deliverable installer 
--
add name=enableBizTalkHeaderInspector 
type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=31bf3856ad364e35/
]]/util:XmlConfig


-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:
util:XmlFile Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector 
File=[NetFramework20ConfigDir]machine.config

ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions
Name=add Value=name=quot;enableBizTalkHeaderInspectorquot; 
type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot;
Action=createElement /

util:XmlConfig Id=RemoveBehaviorExtensionsEnableBizTalkHeaderInspector 
File=[NetFramework20ConfigDir]machine.config

ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions

VerifyPath=/configuration/system.serviceModel/extensions/behaviorExtensions/[EMAIL
 PROTECTED]quot;enableBizTalkHeaderInspectorquot; amp;amp; 
@type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot;[\]]
Action=delete Node=element On=uninstall /

To try and get this new add / element created during install but finding that 
no machine.config changes exist after setup completes.
configuration
system.serviceModel
extensions
   behaviorExtensions
   .
   . .
   . . .
   add name=enableBizTalkHeaderInspector 
type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=e2c282dc0883bc94 /
   /behaviorExtensions

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

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.

Fragment
Property Id=NETFRAMEWORK20INSTALLROOTDIR Secure=yes
RegistrySearch Id=NetFxInstallRootForNetfx20Search Type=raw 
Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot
DirectorySearch Id=NetFx20InstallRootSearch 
Path=v2.0.50727 Depth=0 /
/RegistrySearch
/Property
/Fragment

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.

PropertyRef Id=NETFRAMEWORK20INSTALLROOTDIR /

Directory Id=NETFRAMEWORK20INSTALLROOTDIR
Directory Id=NetFramework20ConfigDir Name=CONFIG /
/Directory

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.
Property Id=NFX20INSTALLROOTDIR
RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw 
Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot
DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 
Depth=0 /
/RegistrySearch
/Property
Property Id=NFX20X86INSTALLROOTDIR
RegistrySearch Id=NfxX86InstallRootForNetfx20Search Type=raw 
Root=HKLM Key=Software\Wow6432Node\Microsoft\.NETFramework 
Name=InstallRoot
DirectorySearch Id=Nfx20X86InstallRootSearch Path=v2.0.50727 
Depth=0 /
/RegistrySearch
/Property


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


util:XmlConfig Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector 
File=[NetFramework20ConfigDir]machine.config

ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions
Action=create Node=document On=install![CDATA[
!-- this line was added by rxp eventing v2.0 service deliverable installer 
--
add name=enableBizTalkHeaderInspector 
type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=31bf3856ad364e35/
]]/util:XmlConfig


-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:
util:XmlFile Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector 
File=[NetFramework20ConfigDir]machine.config

ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions
Name=add Value=name=quot;enableBizTalkHeaderInspectorquot; 
type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot;
Action=createElement /

util:XmlConfig Id=RemoveBehaviorExtensionsEnableBizTalkHeaderInspector 
File=[NetFramework20ConfigDir]machine.config

ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions

VerifyPath=/configuration/system.serviceModel/extensions/behaviorExtensions/[EMAIL
 PROTECTED]quot;enableBizTalkHeaderInspectorquot; amp;amp; 
@type=quot

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?

   Property Id=NFX20INSTALLROOTDIR
RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw 
Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot
DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 
Depth=0 /
/RegistrySearch
/Property


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

Fragment
Property Id=NETFRAMEWORK20INSTALLROOTDIR Secure=yes
RegistrySearch Id=NetFxInstallRootForNetfx20Search Type=raw 
Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot
DirectorySearch Id=NetFx20InstallRootSearch 
Path=v2.0.50727 Depth=0 /
/RegistrySearch
/Property
/Fragment

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.

PropertyRef Id=NETFRAMEWORK20INSTALLROOTDIR /

Directory Id=NETFRAMEWORK20INSTALLROOTDIR
Directory Id=NetFramework20ConfigDir Name=CONFIG /
/Directory

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.
Property Id=NFX20INSTALLROOTDIR
RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw 
Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot
DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 
Depth=0 /
/RegistrySearch
/Property
Property Id=NFX20X86INSTALLROOTDIR
RegistrySearch Id=NfxX86InstallRootForNetfx20Search Type=raw 
Root=HKLM Key=Software\Wow6432Node\Microsoft\.NETFramework 
Name=InstallRoot
DirectorySearch Id=Nfx20X86InstallRootSearch Path=v2.0.50727 
Depth=0 /
/RegistrySearch
/Property


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


util:XmlConfig Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector 
File=[NetFramework20ConfigDir]machine.config

ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions
Action=create Node=document On=install![CDATA[
!-- this line was added by rxp eventing v2.0 service deliverable installer 
--
add name=enableBizTalkHeaderInspector 
type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement,
 Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=31bf3856ad364e35/
]]/util:XmlConfig


-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2008 11:39 AM
To: 'General discussion

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?

   Property Id=NFX20INSTALLROOTDIR
RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw 
Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot
DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 
Depth=0 /
/RegistrySearch
/Property


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

Fragment
Property Id=NETFRAMEWORK20INSTALLROOTDIR Secure=yes
RegistrySearch Id=NetFxInstallRootForNetfx20Search Type=raw 
Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot
DirectorySearch Id=NetFx20InstallRootSearch 
Path=v2.0.50727 Depth=0 /
/RegistrySearch
/Property
/Fragment

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.

PropertyRef Id=NETFRAMEWORK20INSTALLROOTDIR /

Directory Id=NETFRAMEWORK20INSTALLROOTDIR
Directory Id=NetFramework20ConfigDir Name=CONFIG /
/Directory

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.
Property Id=NFX20INSTALLROOTDIR
RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw 
Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot
DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 
Depth=0 /
/RegistrySearch
/Property
Property Id=NFX20X86INSTALLROOTDIR
RegistrySearch Id=NfxX86InstallRootForNetfx20Search Type=raw 
Root=HKLM Key=Software\Wow6432Node\Microsoft\.NETFramework 
Name=InstallRoot
DirectorySearch Id=Nfx20X86InstallRootSearch Path=v2.0.50727 
Depth=0 /
/RegistrySearch
/Property


-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

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

 Custom Action=QtExecCmdLineRun5 Before=CreateDatabaseNot
 Installed/Custom

 and when I compile I get the following error

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

 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=100url=/
 ___
 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=100url=/
___
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=100url=/
___
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=100url=/
___
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=100url=/
___
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

Component Id=Site1Vdir1 Guid=15280DB5-1879-4D3D-A559-566FCA21FB77
!--File Id=InstalledSite1Vdir1.txt Name=InstalledSite1Vdir1.txt 
Source=Resources\InstalledComponent.txt KeyPath=yes /--
!-- if you introduce a shortcut then you need to use an HCKU key keypath 
to statisfy ice43 checks --
RegistryKey Root=HKCU 
Key=$(var.SoftwareKey)\Microsoft\!(loc.ProductKey)
RegistryValue Name=InstalledSite1Vdir1 Type=integer Value=1 
KeyPath=yes /
/RegistryKey

File Id=Site1Vdir1Web.config Name=Web.Config 
Source=$(var.EventingWcfProvider.ProjectDir)Web.config /
File Id=Site1Vdir1Service1.svc Name=Service1.svc 
Source=$(var.EventingWcfProvider.ProjectDir)Service1.svc /

Shortcut Id=Site1Vdir1Shortcut1 Name=Eventing Wcf Provider
  Target=[IE]
  Arguments=[SetSite1Vdir1Shortcut1ArgProperty]
  Directory=ProductMenuFolder
  Description=Site1 Vdir1 Default Page /
RemoveFolder Id=Site1Vdir1ShortcutsRemoveProductMenuFolder 
On=uninstall /

!--iis:WebVirtualDir Id=Site1Vdir1 Alias=Site1Vdir1 
WebSite=DefaultWebSite Directory=Site1Vdir1Dir--
iis:WebVirtualDir Id=Site1Vdir1 Alias=Site1Vdir1 
WebSite=Site1WebSite Directory=Site1Vdir1Dir
iis:WebApplication Id=Site1Vdir1App Name=Site1Vdir1 Application 
WebAppPool=Site1AppPool Isolation=medium /
/iis:WebVirtualDir
/Component

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=100url=/
___
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

Component Id=Site1Vdir1 Guid=15280DB5-1879-4D3D-A559-566FCA21FB77
!--File Id=InstalledSite1Vdir1.txt Name=InstalledSite1Vdir1.txt 
Source=Resources\InstalledComponent.txt KeyPath=yes /--
!-- if you introduce a shortcut then you need to use an HCKU key keypath 
to statisfy ice43 checks --
RegistryKey Root=HKCU 
Key=$(var.SoftwareKey)\Microsoft\!(loc.ProductKey)
RegistryValue Name=InstalledSite1Vdir1 Type=integer Value=1 
KeyPath=yes /
/RegistryKey

File Id=Site1Vdir1Web.config Name=Web.Config 
Source=$(var.EventingWcfProvider.ProjectDir)Web.config /
File Id=Site1Vdir1Service1.svc Name=Service1.svc 
Source=$(var.EventingWcfProvider.ProjectDir)Service1.svc /

Shortcut Id=Site1Vdir1Shortcut1 Name=Eventing Wcf Provider
  Target=[IE]
  Arguments=[SetSite1Vdir1Shortcut1ArgProperty]
  Directory=ProductMenuFolder
  Description=Site1 Vdir1 Default Page /
RemoveFolder Id=Site1Vdir1ShortcutsRemoveProductMenuFolder 
On=uninstall /

!--iis:WebVirtualDir Id=Site1Vdir1 Alias=Site1Vdir1 
WebSite=DefaultWebSite Directory=Site1Vdir1Dir--
iis:WebVirtualDir Id=Site1Vdir1 Alias=Site1Vdir1 
WebSite=Site1WebSite Directory=Site1Vdir1Dir
iis:WebApplication Id=Site1Vdir1App Name=Site1Vdir1 Application 
WebAppPool=Site1AppPool Isolation=medium /
/iis:WebVirtualDir
/Component

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=100url=/
___
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=100url=/
___
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

 Custom Action=QtExecCmdLineRun5 Before=CreateDatabaseNot
 Installed/Custom

 and when I compile I get the following error

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

 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=100url=/
 ___
 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=100url=/
___
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=100url=/
___
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]

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=csv features list 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 
UIRef Id=WixUI_FeatureTreeEx / 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?

Feature Id=Sites Title=!(loc.Sites) Level=1
Condition Level=0SITES=0/Condition
Feature Id=Site1 Title=!(loc.Site1) Level=1
Condition Level=0SITE1=0/Condition
/Feature
Feature Id=Site2 Title=!(loc.Site2) Level=1
Condition Level=0SITE2=0/Condition
/Feature
/Feature

-
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=100url=/
___
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=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email

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=csv features list 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 
UIRef Id=WixUI_FeatureTreeEx / 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?

Feature Id=Sites Title=!(loc.Sites) Level=1
Condition Level=0SITES=0/Condition
Feature Id=Site1 Title=!(loc.Site1) Level=1

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

 FeatureRef Id=Databases /
FeatureRef Id=Services /
FeatureRef Id=Sites /
FeatureRef Id=Tools /
FeatureRef Id=Sdks /

UIRef Id=WixUI_FeatureTree /

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=100url=/
___
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 iis:* / 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



iis:WebApplication Id=MainWebApplication
Name=[IISWEBAPPLICATIONNAME] WebAppPool=WebAppPool /
DirectoryRef Id=TARGETDIR
!--These components can be shared across multiple IIS6
Components--
Component Id=CreateUser
Guid=5f36c780-e62b-11dc-95ff-0800200c9a66
Condition![CDATA[IISMJRVRSN=#6]]/Condition
util:User Id=InstallUser Name=[APPLICATIONUSER]
Password=[APPLICATIONPASSWORD] CreateUser=yes
PasswordNeverExpires=yes CanNotChangePassword=yes
RemoveOnUninstall=yes UpdateIfExists=yes Domain=[ComputerName]
LogonAsService=yes
util:GroupRef Id=IISWorkerProcessGroup/
/util:User
/Component
Component Id=CreateAppPool
Guid=28676FA9-2BF7-4815-8732-EF2CF0B8470E
Condition![CDATA[IISMJRVRSN=#6]]/Condition
iis:WebAppPool Id=WebAppPool Name=[IISAPPPOOLNAME]
Identity=other User=InstallUser IdleTimeout=0  RecycleMinutes=0
RecycleRequests=0
iis:RecycleTime Value=03:00/
/iis:WebAppPool
/Component
!--These components have something unique that must be within
this specific component IIS6 Component--
Component Id=CreateVirtualDirectoryAnonymous
Guid=5f9a10ee-72b1-11dc-8314-0800200c9a66
Condition![CDATA[(IISMJRVRSN=#6) AND
(IISCONFIGURATIONTYPE=0) AND
(IISUSEWINDOWSAUTHENTICATIONchecked)]]/Condition
iis:WebVirtualDir Id=WebVirtualDir
Alias=[IISVIRTUALDIRECTORY] Directory=MainWebDirectory
WebSite=DefaultWebSite WebApplication=MainWebApplication
DirProperties=WebDirPropertiesAnonymous /
/Component
Component Id=CreateWebsiteWithPortAnonymous
Guid=f3ced440-e62c-11dc-95ff-0800200c9a66
Condition![CDATA[(IISMJRVRSN=#6) AND
(IISCONFIGURATIONTYPE=1) AND (IISWebsiteUseIPchecked) AND
(IISUSEWINDOWSAUTHENTICATIONchecked)]]/Condition
iis:WebSite Id=NewWebsitePort
Description=[IISWEBSITE] Directory=MainWebDirectory AutoStart=yes
WebApplication=MainWebApplication
DirProperties=WebDirPropertiesAnonymous
iis:WebAddress Id=WebsiteWebAddressPort
Port=[IISPORT] /
/iis:WebSite
/Component

-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=100url=/
___
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=100url=/
___
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 
UIRef Id=WixUI_FeatureTreeEx / 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?

Feature Id=Sites Title=!(loc.Sites) Level=1
Condition Level=0SITES=0/Condition
Feature Id=Site1 Title=!(loc.Site1) Level=1
Condition Level=0SITE1=0/Condition
/Feature
Feature Id=Site2 Title=!(loc.Site2) Level=1
Condition Level=0SITE2=0/Condition
/Feature
/Feature

-
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=100url=/
___
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=100url=/
___
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=100url=/
___
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
Property Id=DATABASESHOSTNAME Value=[%ComputerName]
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
Property Id=DATABASESHOSTNAME Value=localhost
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=100url=/
___
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

Custom Action=QtExecCmdLineRun5 Before=CreateDatabaseNot 
Installed/Custom

and when I compile I get the following error

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

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=100url=/
___
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]

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 netfx:NativeImage attribute setting that will result in 
bits getting placed in %systemroot%\assembly\gac_msil?

-Original Message-
From: Neil Enns [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=100url=/
___
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=100url=/
___
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=100url=/
___
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.

Component Id=gacitem1 Guid=PUT-GUID-HERE Win64=$(var.Win64)
File Id=SomeGacDestinedItem.dll 
Name=Company.Deliverable.SomeGacDestinedItem.dll 
Source=$(var.SomeGacDestinedItem.TargetPath) Assembly=.net KeyPath=yes /
/Component

-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 netfx:NativeImage attribute setting that will result in 
bits getting placed in %systemroot%\assembly\gac_msil?

-Original Message-
From: Neil Enns [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=100url=/
___
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=100url=/
___
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=100url=/
___
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=100url=/
___
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

[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
--
?if $(var.Platform) = x64 ?
?define Win64 = yes ?
?define SystemFolder = System64Folder ?
?define SystemFolderX86 = SystemFolder ?
?define SoftwareKey = Software ?
?define SoftwareKeyX86 = Software\Wow6432Node ?
?define ProgramFilesFolder = ProgramFiles64Folder ?
?define ProgramFilesFolderX86 = ProgramFilesFolder ?
?else?
?define Win64 = no ?
?define SystemFolder = SystemFolder ?
?define SystemFolderX86 = SystemFolder ?
?define SoftwareKey = Software ?
?define SoftwareKeyX86 = Software ?
?define ProgramFilesFolder = ProgramFilesFolder ?
?define ProgramFilesFolderX86 = ProgramFilesFolder ?
?endif?

Component Id=SomeComponent1 Guid=PUT-GUID-HERE Win64=$(var.Win64)
. . .
/Component

Component Id=SomeComponent2 Guid=PUT-GUID-HERE Win64=$(var.Win64)
. . .
/Component


/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=100url=/
___
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-HEREmk:@MSITStore:C:\Program%20Files%20(x86)\Windows%20Installer%20XML%20v3\doc\WiX.chm::/html/generate_guids.htm
 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-HEREmk:@MSITStore:C:\Program%20Files%20(x86)\Windows%20Installer%20XML%20v3\doc\WiX.chm::/html/generate_guids.htm
 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=100url=/
___
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=100url=/
___
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=100url=/
___
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]

Component Id=SomeComponent Guid=PUT-GUID-HERE Win64=$(var.Win64)
   . . .
   RegistryKey Root=HKLM 
Key=$(var.SoftwareKey)\Microsoft\!(loc.ProductKey)
  RegistryValue Name=DATABASESHOST Type=string Value=[DATABASESHOST] 
/
   /RegistryKey
   . . .
/Component

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

Property Id=DATABASESHOST Value=[%ComputerName]
!-- Any public property default values that were overridden at install time 
are not automatically overridden with the same value at uninstall time.  
Therefore for any public property values that you also need to use during 
uninstall you need to store the value of them that was used at install time so 
that it can be read and used at uninstall time. --
RegistrySearch Id=DatabasesHostSearch1 Type=raw Root=HKLM
Key=$(var.SoftwareKey)\Microsoft\!(loc.ProductKey) 
Name=DATABASESHOST /
/Property

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

?if $(var.Platform) = x64 ?
?define Win64 = yes ?
?define SystemFolder = System64Folder ?
?define SystemFolderX86 = SystemFolder ?
?define SoftwareKey = Software ?
?define SoftwareKeyX86 = Software\Wow6432Node ?
?define ProgramFilesFolder = ProgramFiles64Folder ?
?define ProgramFilesFolderX86 = ProgramFilesFolder ?
?define DotNetFramework35Folder = 
[%SystemRoot]\Microsoft.NET\Framework64\v3.5\ ?
?define DotNetFramework20Folder = 
[%SystemRoot]\Microsoft.NET\Framework64\v2.0.50727\ ?
?else?
?define Win64 = no ?
?define SystemFolder = SystemFolder ?
?define SystemFolderX86 = SystemFolder ?
?define SoftwareKey = Software ?
?define SoftwareKeyX86 = Software ?
?define ProgramFilesFolder = ProgramFilesFolder ?
?define ProgramFilesFolderX86 = ProgramFilesFolder ?
?define DotNetFramework35Folder = 
[%SystemRoot]\Microsoft.NET\Framework\v3.5\ ?
?define DotNetFramework20Folder = 
[%SystemRoot]\Microsoft.NET\Framework\v2.0.50727\ ?
?endif?


-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

Re: [WiX-users] how does one get XmlFile to insert literal translations of lt; and gt; 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?

util:XmlConfig Id=Service1IServiceGatewayEndpointIdentity 
File=[#NsService.exe.config]
ElementPath=/configuration/system.serviceModel/client/[EMAIL 
PROTECTED]quot;ServiceGatewayEndpointquot;[\]]
  Action=create Node=document On=install![CDATA[
  !-- Added for bug #343521.  MSSolve endpoints require identity settings 
for systems with .net framework 3.5 sp1 installed.  --
  identity[SERVICEGATEWAYIDENTITY]/identity]]
/util:XmlConfig
util:XmlConfig Id=Service1IServiceGatewayEndpointIdentityUninstall 
File=[#NsService.exe.config]
  ElementPath=/configuration/system.serviceModel/client/[EMAIL 
PROTECTED]quot;ServiceGatewayEndpointquot;[\]]
  
VerifyPath=/configuration/system.serviceModel/client/endpoint/identity[\[]../@bindingConfiguration=quot;ServiceGatewayEndpointquot;[\]]
 Action=delete Node=element On=uninstall /

-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 lt; and gt; 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 
lt; and gt; entity settings when setting values?

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

util:XmlFile Id=Service1IServiceGatewayEndpointIdentity 
File=[#NsService.exe.config]

ElementPath=/configuration/system.serviceModel/client/endpoint/identity[\[]../@bindingConfiguration=quot;ServiceGatewayEndpointquot;[\]]
Value=[SERVICEGATEWAYIDENTITY] Action=setValue /

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

client
endpoint binding=wsHttpBinding 
bindingConfiguration=ServiceGatewayEndpoint 
contract=ServiceReference1.IServiceGateway name=ServiceGatewayEndpoint 
behaviorConfiguration=ImpersonationBehavior 
address=https://localhost/ServiceGateway/ServiceGateway.svc;
identitylt;servicePrincipalName value='host/localhost' 
/gt;/identity
/endpoint
endpoint binding=wsHttpBinding 
bindingConfiguration=ServiceGateway2Endpoint 
contract=ServiceReference2.IServiceGateway2 name=ServiceGateway2Endpoint 
behaviorConfiguration=ImpersonationBehavior 
address=https://localhost/ServiceGateway2/ServiceGateway2.svc;
identity/identity
/endpoint
/client

Question
-
How does one get XmlFile to insert literal translations of lt; and gt; 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=100url=/
___
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=100url=/
___
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=100url=/
___
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 UIRef Id=WixUI_Mondo / and UIRef 
Id=WixUI_FeatureTree / 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=100url=/
___
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=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] handling v1.0 to v1.1 release start | programs | shortcuts menu 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
String Id=ProductMenuMy Service Deliverable/String
in v1.1 wix sources
String Id=ProductMenuMy Service Deliverable v1.1/String

in v1.0 and v1.1 wix sources this stayed the same
Directory Id=ProgramMenuFolder
Directory Id=ProductMenuFolder Name=!(loc.ProductMenu) /
/Directory

DirectoryRef Id=ProductMenuFolder
Component Id=UninstallShortcut 
Guid=BFE964D5-D248-44E7-83C7-D2D43BAF198B Win64=$(var.Win64)
RegistryKey Root=HKCU 
Key=$(var.SoftwareKey)\Microsoft\!(loc.ProductKey)
RegistryValue Name=InstalledUninstallShortcut 
Type=integer Value=1 KeyPath=yes /
/RegistryKey
Shortcut Id=UninstallProduct Name=Uninstall 
!(loc.ProductName)
  Target=[$(var.SystemFolder)]msiexec.exe
  Arguments=/x [ProductCode]
  Directory=ProductMenuFolder
  Description=Uninstalls !(loc.ProductName) /
RemoveFolder Id=UninstallShortcutRemoveProductMenuFolder 
On=uninstall /
/Component
/DirectoryRef

-
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=100url=/
___
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 lt; and gt; entity settings when setting values?

[Robert O'Brien]

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

util:XmlFile Id=Service1IServiceGatewayEndpointIdentity 
File=[#NsService.exe.config]

ElementPath=/configuration/system.serviceModel/client/endpoint/identity[\[]../@bindingConfiguration=quot;ServiceGatewayEndpointquot;[\]]
Value=[SERVICEGATEWAYIDENTITY] Action=setValue /

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

client
endpoint binding=wsHttpBinding 
bindingConfiguration=ServiceGatewayEndpoint 
contract=ServiceReference1.IServiceGateway name=ServiceGatewayEndpoint 
behaviorConfiguration=ImpersonationBehavior 
address=https://localhost/ServiceGateway/ServiceGateway.svc;
identitylt;servicePrincipalName value='host/localhost' 
/gt;/identity
/endpoint
endpoint binding=wsHttpBinding 
bindingConfiguration=ServiceGateway2Endpoint 
contract=ServiceReference2.IServiceGateway2 name=ServiceGateway2Endpoint 
behaviorConfiguration=ImpersonationBehavior 
address=https://localhost/ServiceGateway2/ServiceGateway2.svc;
identity/identity
/endpoint
/client

Question
-
How does one get XmlFile to insert literal translations of lt; and gt; 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=100url=/
___
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.

   util:XmlFile ... ElementPath='//[EMAIL PROTECTED]third\]'/

You can use alternatively:

   util:XmlFile ... ElementPath=//[EMAIL PROTECTED]quot;thirdquot;[\]] /


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

   XmlFile ... ElementPath='//[EMAIL PROTECTED]third\]'/

You can use alternatively:

   Property Id=THIRDNODE[EMAIL PROTECTED]third]/Property

   XmlFile ... ElementPath='//add[THIRDNODE]'/

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: wix-users@lists.sourceforge.net
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:

configuration
  myComponent
section name=DatabaseSettings
  Default server=foo database=bar/
/section
section name=MoreSettings
  ...
/section
  /myComponent
/configuration

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

util:XmlConfig Id=WriteServerConfigValue
Action=create
On=install
Node=value

ElementPath=/configuration/myComponent/[EMAIL PROTECTED]'DatabaseConnec
tions'[\]]/Default

VerifyPath=/configuration/myComponent/[EMAIL PROTECTED]'DatabaseConnect
ions'[\]]/Default
Name=server
Value=[CORRECTDATABASESERVER]
File=[#MyXmlConfigFile]
Sequence=1 /

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
My file name, 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=100url=/
___
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=100url=/
___
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.

!-- for msp small update or minor upgrade processing --
CustomAction Id=SetMspSmallUpdateOrMinorUpgradeReInstallProperty 
Property=REINSTALL Value=ALL /
CustomAction Id=SetMspSmallUpdateOrMinorUpgradeReInstallModeProperty 
Property=REINSTALLMODE Value=omus /

!-- for msu minor upgrade processing --
CustomAction Id=SetMsiMinorUpgradeReInstallProperty Property=REINSTALL 
Value=ALL /
CustomAction Id=SetMsiMinorUpgradeReInstallModeProperty 
Property=REINSTALLMODE Value=vomus /

!-- for msi major upgrade processing --
CustomAction Id=SetMsiMajorUpgradePreventDowngradingError Error=Newer 
version already installed. /
CustomAction Id=SetMsiMajorUpgradeReInstallProperty Property=REINSTALL 
Value=ALL /
CustomAction Id=SetMsiMajorUpgradeReInstallModeProperty 
Property=REINSTALLMODE Value=vomus /

InstallExecuteSequence
!-- for msp small update or minor upgrade processing --
!--Custom Action=SetMspSmallUpdateOrMinorUpgradeReInstallProperty 
After=LaunchConditionsPATCH And Installed/Custom
Custom Action=SetMspSmallUpdateOrMinorUpgradeReInstallModeProperty 
After=LaunchConditionsPATCH And Installed/Custom--
Custom Action=SetMspSmallUpdateOrMinorUpgradeReInstallProperty 
After=LaunchConditionsQFEUpgrade=2/Custom
Custom Action=SetMspSmallUpdateOrMinorUpgradeReInstallModeProperty 
After=LaunchConditionsQFEUpgrade=2/Custom

!-- for msi minor upgrade processing --
Custom Action=SetMsiMinorUpgradeReInstallProperty 
After=LaunchConditionsQFEUpgrade=1/Custom
Custom Action=SetMsiMinorUpgradeReInstallModeProperty 
After=LaunchConditionsQFEUpgrade=1/Custom

!-- for msi major upgrade processing --
Custom Action=SetMsiMajorUpgradePreventDowngradingError 
After=FindRelatedProductsNEWERVERSIONFOUND/Custom
Custom Action=SetMsiMajorUpgradeReInstallProperty 
After=FindRelatedProductsOLDERVERSIONFOUND/Custom
Custom Action=SetMsiMajorUpgradeReInstallModeProperty 
After=FindRelatedProductsOLDERVERSIONFOUND/Custom
RemoveExistingProducts 
After=InstallFinalizeOLDERVERSIONFOUND/RemoveExistingProducts  !-- note - 
windows installer sets UPGRADINGPRODUCTCODE property when this action runs --



-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=100url=/
___
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=100url=/
___
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

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.

!-- for msp small update or minor upgrade processing --
CustomAction Id=SetMspSmallUpdateOrMinorUpgradeReInstallProperty 
Property=REINSTALL Value=ALL /
CustomAction Id=SetMspSmallUpdateOrMinorUpgradeReInstallModeProperty 
Property=REINSTALLMODE Value=omus /

!-- for msu minor upgrade processing --
CustomAction Id=SetMsiMinorUpgradeReInstallProperty Property=REINSTALL 
Value=ALL /
CustomAction Id=SetMsiMinorUpgradeReInstallModeProperty 
Property=REINSTALLMODE Value=vomus /

!-- for msi major upgrade processing --
CustomAction Id=SetMsiMajorUpgradePreventDowngradingError Error=Newer 
version already installed. /
CustomAction Id=SetMsiMajorUpgradeReInstallProperty Property=REINSTALL 
Value=ALL /
CustomAction Id=SetMsiMajorUpgradeReInstallModeProperty 
Property=REINSTALLMODE Value=vomus /

InstallExecuteSequence
!-- for msp small update or minor upgrade processing --
!--Custom Action=SetMspSmallUpdateOrMinorUpgradeReInstallProperty 
After=LaunchConditionsPATCH And Installed/Custom
Custom Action=SetMspSmallUpdateOrMinorUpgradeReInstallModeProperty 
After=LaunchConditionsPATCH And Installed/Custom--
Custom Action=SetMspSmallUpdateOrMinorUpgradeReInstallProperty 
After=LaunchConditionsQFEUpgrade=2/Custom
Custom Action=SetMspSmallUpdateOrMinorUpgradeReInstallModeProperty 
After=LaunchConditionsQFEUpgrade=2/Custom

!-- for msi minor upgrade processing --
Custom Action=SetMsiMinorUpgradeReInstallProperty 
After=LaunchConditionsQFEUpgrade=1/Custom
Custom Action=SetMsiMinorUpgradeReInstallModeProperty 
After=LaunchConditionsQFEUpgrade=1/Custom

!-- for msi major upgrade processing --
Custom Action=SetMsiMajorUpgradePreventDowngradingError 
After=FindRelatedProductsNEWERVERSIONFOUND/Custom
Custom Action=SetMsiMajorUpgradeReInstallProperty 
After=FindRelatedProductsOLDERVERSIONFOUND/Custom
Custom Action=SetMsiMajorUpgradeReInstallModeProperty 
After=FindRelatedProductsOLDERVERSIONFOUND/Custom
RemoveExistingProducts 
After=InstallFinalizeOLDERVERSIONFOUND/RemoveExistingProducts  !-- note - 
windows installer sets UPGRADINGPRODUCTCODE property when this action runs --



-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=100url=/
___
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

[WiX-users] msp patch and msi upgrade processing scenario where a specific app.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 
app.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  util:XmlFile settings that update wcf endpoint address settings to 
be deployment environment specific.   Is it those updates to that are 
preventing the v1.0 to v1.1 msp patch minor upgrade and msi minor upgrade 
processes from updating that file to contain the just the v1.1 added content?   
 If so is there syntax to instruct v1.0 to v1.1 msp patch and msi minor upgrade 
processing to replace that file regardless and rerun the util:XmlFile settings 
component step?
-
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=100url=/
___
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.

!-- for msp small update or minor upgrade processing --
CustomAction Id=SetMspSmallUpdateOrMinorUpgradeReInstallProperty 
Property=REINSTALL Value=ALL /
CustomAction Id=SetMspSmallUpdateOrMinorUpgradeReInstallModeProperty 
Property=REINSTALLMODE Value=omus /

!-- for msu minor upgrade processing --
CustomAction Id=SetMsiMinorUpgradeReInstallProperty Property=REINSTALL 
Value=ALL /
CustomAction Id=SetMsiMinorUpgradeReInstallModeProperty 
Property=REINSTALLMODE Value=vomus /

!-- for msi major upgrade processing --
CustomAction Id=SetMsiMajorUpgradePreventDowngradingError Error=Newer 
version already installed. /
CustomAction Id=SetMsiMajorUpgradeReInstallProperty Property=REINSTALL 
Value=ALL /
CustomAction Id=SetMsiMajorUpgradeReInstallModeProperty 
Property=REINSTALLMODE Value=vomus /

InstallExecuteSequence
!-- for msp small update or minor upgrade processing --
!--Custom Action=SetMspSmallUpdateOrMinorUpgradeReInstallProperty 
After=LaunchConditionsPATCH And Installed/Custom
Custom Action=SetMspSmallUpdateOrMinorUpgradeReInstallModeProperty 
After=LaunchConditionsPATCH And Installed/Custom--
Custom Action=SetMspSmallUpdateOrMinorUpgradeReInstallProperty 
After=LaunchConditionsQFEUpgrade=2/Custom
Custom Action=SetMspSmallUpdateOrMinorUpgradeReInstallModeProperty 
After=LaunchConditionsQFEUpgrade=2/Custom

!-- for msi minor upgrade processing --
Custom Action=SetMsiMinorUpgradeReInstallProperty 
After=LaunchConditionsQFEUpgrade=1/Custom
Custom Action=SetMsiMinorUpgradeReInstallModeProperty 
After=LaunchConditionsQFEUpgrade=1/Custom

!-- for msi major upgrade processing --
Custom Action=SetMsiMajorUpgradePreventDowngradingError 
After=FindRelatedProductsNEWERVERSIONFOUND/Custom
Custom Action=SetMsiMajorUpgradeReInstallProperty 
After=FindRelatedProductsOLDERVERSIONFOUND/Custom
Custom Action=SetMsiMajorUpgradeReInstallModeProperty 
After=FindRelatedProductsOLDERVERSIONFOUND/Custom
RemoveExistingProducts 
After=InstallFinalizeOLDERVERSIONFOUND/RemoveExistingProducts  !-- note - 
windows installer sets UPGRADINGPRODUCTCODE property when this action runs --



-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=100url=/
___
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=100url=/
___
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 Upgrade/UpgradeVersion sources and FindRelatedProducts only execute 
during Major Upgrade processing where ones Product Id would have changed...i 
kept thinking this was buying me something for msi minor upgrade processing
- RemoveExistingProducts needs to be explicitly included in the 
installexecutesequence, versus getting added automatically if msi 
Upgrade/UpgradeVersion sources are present and only execute during Major 
Upgrade processing where ones Product Id would have changed
- msi v1.0 - v1.next minor upgrade processing just works if all that is 
involves is binary file updates w/o doing anything other than incrementing 
Product Version=major.minor.build.revision / 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 util:XmlFile settings will not get 
updated by msp small update or minor upgrade processing unless you include a 
behavior that deletes the file up front during msp small update or minor 
upgrade processing...conversly when that msp is removed you'll end up with the 
prior release copy of that file w/o the util:XmlFile applied settings.   
Haven't figured out yet how to have that step rerun when the msp is removed
- and more that I probably don't even know I should know about yet

Once we get our current service deliverable shipped I would like to put 
together a one pager new user overview of the small update, minor upgrade and 
major upgrade wix provided services as a knowledge share exercise for others in 
my org to leverage in there msp  msi authoring activities.  When I do that I 
can share it with the internal pros who can decide whether or not it would be 
worth putting in one of their blogs.

-Original Message-
From: [EMAIL PROTECTED] [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 

Re: [WiX-users] msp patch and msi upgrade processing scenario where a specific app.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 util:XmlFile 
settings will not get updated by msp small update or minor upgrade processing.  
 The only way I could get the file to be updated with the new file settings, 
e.g. assembly reference version number changes, and reapply the util:XmlFile 
settings was to include a msp processing case behavior that deletes the file up 
front during msp small update or minor upgrade processing.

DirectoryRef Id=Service1Dir
Component Id=Service1 
Guid=B9CD4A81-9755-42F5-BB25-CC8879B38C2B Win64=$(var.Win64)
...
File Id=NsService.exe.config Name=NsService.exe.config 
Source=$(var.SolutionDir)ClientSpecific\MSSolve\Configuration\NsService.exe.config
 /
util:XmlFile Id=Service1INgimServiceGatewayEndpointAddress 
File=[#NsService.exe.config]

ElementPath=/configuration/system.serviceModel/client/[EMAIL 
PROTECTED]quot;NGIMServiceGatewayEndpointquot;[\]]
Name=address Value=[SERVICEGATEWAYURL] 
Action=setValue /


CustomAction Id=QtExecCmdLineSet16 Property=QtExecCmdLineRun16 
Value=quot;[$(var.SystemFolder)]cmd.exequot; /c del /f 
quot;[Service1Dir]NsService.exe.configquot; /
CustomAction Id=QtExecCmdLineRun16 BinaryKey=WixCA DllEntry=CAQuietExec 
Execute=deferred /

InstallExecuteSequence
...
Custom Action=QtExecCmdLineSet16 
After=QtExecCmdLineRun15!Services=3 And ?Service1=3 And (QFEUpgrade=2 Or 
QFEUpgrade=1)/Custom
Custom Action=QtExecCmdLineRun16 
After=QtExecCmdLineSet16!Services=3 And ?Service1=3 And (QFEUpgrade=2 Or 
QFEUpgrade=1)/Custom

Conversely when the msp is removed I ended up with the prior release copy of 
that file w/o the util:XmlFile applied settings.   I haven't figured out yet 
how to have the remove process reapply the util:XmlFile customizations to the 
reverted version of that file.   Any suggestions are welcome.


-Original Message-
From: [EMAIL PROTECTED] [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 app.config file setting which has changed is not getting updated

I have a msp patch and msi minor pgrade processing result where a specific 
app.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  util:XmlFile settings that update wcf endpoint address settings to 
be deployment environment specific.   Is it those updates to that are 
preventing the v1.0 to v1.1 msp patch minor upgrade and msi minor upgrade 
processes from updating that file to contain the just the v1.1 added content?   
 If so is there syntax to instruct v1.0 to v1.1 msp patch and msi minor upgrade 
processing to replace that file regardless and rerun the util:XmlFile settings 
component step?
-
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=100url=/
___
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=100url=/
___
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=100url=/
___
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]

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=100url=/
___
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=100url=/
___
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]

 PatchFamily=EventingV11PatchFamily Sequence=1.0.0.0 
Supersede=yes /
/PatchCreation

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

Robert O'Brien wrote:
 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?


If a feature's install level is 0, 'msiexec /a' won't install it.

--
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=100url=/
___
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=100url=/
___
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]

).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 
 I can then run msimsp.exe against to produce my patch .msp file output.


I believe so. A .pcp is just another MSI database. The WiX v3 patching
tools use different tools that aren't supported in Votive.

--
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=100url=/
___
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=100url=/
___
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 
PatchFamily 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?

Patch AllowRemoval=yes Description=!(loc.ProductName) 
Manufacturer=!(loc.ProductName) MoreInfoURL=!(loc.ProductUrl) 
Classification=Update DisplayName=!(loc.ProductName)

Media Id=5000 Cabinet=Rtm.cab

PatchBaseline Id=Rtm /

/Media



PatchFamilyRef Id=v11ReleasePatchFamily/

/Patch



Fragment

   PatchFamily Id=v11ReleasePatchFamily Version=1.0.0.0 Supersede=yes

   ComponentRef Id=Service1 /

   /PatchFamily

/Fragment

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=100url=/
___
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.
Target Name=AfterBuild
Message Importance=high 
Text=$(TargetDir)%(EmbeddedResourceWithCulture.Culture)\$(TargetName)$(TargetExt)
 /
/Target

-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=100url=/
___
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=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

[Robert O'Brien]

!Databases=2 And ?Database1=2 And amp;Databases=3 
And $Database1=3/Custom
Custom Action=QtExecCmdLineRun10 
After=QtExecCmdLineSet10!Databases=2 And ?Database1=2 And amp;Databases=3 
And $Database1=3/Custom


-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=100url=/
___
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=100url=/
___
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 Message Importance=high 
Text=$(TargetDir)%(EmbeddedResourceWithCulture.Culture)\$(TargetName)$(TargetExt)
 / 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 Message Importance=high 
Text=D:\tfswf\ws0\RXD_RXG_PTF\RXP 
Eventing\Main\Setup\Patch\bin\Debug\%(EmbeddedResourceWithCulture.Culture)\RP 
Event Notification Service Patch.msi 
xmlns=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 Message Importance=high 
Text=$(TargetDir)%(EmbeddedResourceWithCulture.Culture)\$(TargetName)$(TargetExt)
 / 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:

Message Importance=high 
Text=$(TargetDir)%(EmbeddedResourceWithCulture.Culture)\$(TargetName)$(TargetExt)/

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

[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=100url=/
___
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 Message Importance=high 
Text=$(TargetDir)%(EmbeddedResourceWithCulture.Culture)\$(TargetName)$(TargetExt)
 / 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:

Message Importance=high 
Text=$(TargetDir)%(EmbeddedResourceWithCulture.Culture)\$(TargetName)$(TargetExt)/

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)lang-local\$(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)\lang-locale 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

[WiX-users] does inclusion of msi minor upgrade wix sources in v1.1 msi block the ability to also generate v1.0 - v1.1 patch msp minor upgrade msp wix sources

[Robert O'Brien]

Does inclusion of msi minor upgrade wix sources in v1.1 msi block the ability 
to also generate patch msp minor upgrade msp wix sources?

For example does having the following product.wxs sources prevent me from also 
being able to generate a v1.0 - v1.1 patch msp minor upgrade msp wix sources?

Upgrade Id=D1652FA2-32AC-4D5B-8DCF-5DF11FE128BA
UpgradeVersion Minimum=1.1.0.0 IncludeMinimum=no 
OnlyDetect=yes Property=NEWERVERSIONFOUND /
UpgradeVersion Minimum=1.0.0.0 IncludeMinimum=yes 
Maximum=1.1.0.0 IncludeMaximum=no Property=OLDERVERSIONFOUND /
/Upgrade

CustomAction Id=PreventDowngrading Error=Newer version already 
installed. /
CustomAction Id=SetUpgradeReInstallProperty Property=REINSTALL 
Value=all /
CustomAction Id=SetUpgradeReInstallModeProperty Property=REINSTALLMODE 
Value=vomus /

InstallUISequence
Custom Action=PreventDowngrading 
After=FindRelatedProductsNEWERVERSIONFOUND/Custom
/InstallUISequence

InstallExecuteSequence
Custom Action=PreventDowngrading 
After=FindRelatedProductsNEWERVERSIONFOUND/Custom
Custom Action=SetUpgradeReInstallProperty 
After=FindRelatedProductsOLDERVERSIONFOUND/Custom
Custom Action=SetUpgradeReInstallModeProperty 
After=FindRelatedProductsOLDERVERSIONFOUND/Custom
RemoveExistingProducts After=InstallFinalize /

Also evertying I read about the RemoveExistingProducts After=InstallFinalize 
/ action suggests that it causes all v1.0 product components not conditioned 
with an UPDATINGPRODUCTCODE setting to be removed after the v1.1 release has 
been installed provided REINSTALL=all REINSTALLMODE=vomus are set.What is 
really confusing me about this is if that's the case how do all these minor and 
major upgrade server deliverable msi's work that take you from a prior release 
to the next release w/o doing things like dropping databases or iis site and 
vdir settings during minor/major upgrade processing?
-
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=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] does inclusion of msi minor upgrade wix sources in v1.1 msi block the ability to also generate v1.0 - v1.1 patch msp minor upgrade msp wix sources

[Robert O'Brien]

Thanks for the responses.

When folks on the dll state that FindRelatedProducts and RemoveExistingProducts 
only runs the first time the product is installed do they mean only the first 
time a specific msi version of a product is installed? Put another way if I 
having nothing on the system and run the v1.0 msi FindRelatedProducts and 
RemoveExistingProducts run with the latter only running if I have explicitly 
added it to my InstallExecuteSequence.

Now I come along and on that same system with v1.0 installed run the v1.1 msi 
in which case is this considered the first time the v1.1 product is being 
installed or the second time the vwhatever release of the given product is 
being installed.

As for components/custom actions I don't want to rerun during the second pass 
such as database create, script and related custom actions sounds like if I get 
my v1.1 minor upgrade msi and v1.1 minor upgrade patch msp output correct I 
don't explicitely have to worry about them provided in the case of components 
that their KeyPath is properly detected during the upgrade or patch processing 
and in the case of custom actions I've have the correct install pass only 
feature  component state conditions in place.  Is that a correct assumption.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Thursday, September 11, 2008 1:18 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] does inclusion of msi minor upgrade wix sources in 
v1.1 msi block the ability to also generate v1.0 - v1.1 patch msp minor 
upgrade msp wix sources

FindRelatedProducts:  
http://msdn.microsoft.com/en-us/library/aa368600(VS.85).aspx ... only runs the 
first time the product is installed.  As so, I don't believe it executes during 
a patch scenario (so it wouldn't be relevant).

That is also documented as being true for RemoveExistingProducts (only runs the 
first time the product is installed); so not relevant for a patch scenario.


Having never delivered a small update or minor upgrade with an MSI, I can't 
answer those questions.  Hopefully folks with experience in this area will 
chime in.


Regarding all v1.0 product components not conditioned with an 
UPDATINGPRODUCTCODE setting will be removed; I'm not familiar with that.  The 
way I've understood placement of RemoveExistingProducts post InstallFinalize 
has to do with component rules:

Simple example:

V1.0 Installs:
Foo.dll v1.2.0
Foobar.dll  v1.2.0

V2.0 Installs:
Foo.dll v1.2.3



When V1.0 is installed, Foo.dll and Foobar.dll are installed.

When the upgrade to V2.0 is performed, Foo.dll is updated to v1.2.3 and the 
ref-count is incremented for the component.  InstallFinalize takes place, then 
the removal of V1.0 takes place.  Foo.dll's component is de-refcounted but 
since a product is still using it (V2.0) the file remains (v1.2.3).  Foobar.dll 
gets removed.

Custom actions should determine what to do based upon a related component 
state.  If you had a DB removal action tied to the removal of Foo.dll, in the 
above scenario that action would be not executed (if it was conditioned upon 
Foobar.dll, it would be executed).


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 11, 2008 2:20 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] does inclusion of msi minor upgrade wix sources in v1.1 
msi block the ability to also generate v1.0 - v1.1 patch msp minor upgrade msp 
wix sources

Does inclusion of msi minor upgrade wix sources in v1.1 msi block the ability 
to also generate patch msp minor upgrade msp wix sources?

For example does having the following product.wxs sources prevent me from also 
being able to generate a v1.0 - v1.1 patch msp minor upgrade msp wix sources?

Upgrade Id=D1652FA2-32AC-4D5B-8DCF-5DF11FE128BA
UpgradeVersion Minimum=1.1.0.0 IncludeMinimum=no 
OnlyDetect=yes Property=NEWERVERSIONFOUND /
UpgradeVersion Minimum=1.0.0.0 IncludeMinimum=yes 
Maximum=1.1.0.0 IncludeMaximum=no Property=OLDERVERSIONFOUND /
/Upgrade

CustomAction Id=PreventDowngrading Error=Newer version already 
installed. /
CustomAction Id=SetUpgradeReInstallProperty Property=REINSTALL 
Value=all /
CustomAction Id=SetUpgradeReInstallModeProperty Property=REINSTALLMODE 
Value=vomus /

InstallUISequence
Custom Action=PreventDowngrading 
After=FindRelatedProductsNEWERVERSIONFOUND/Custom
/InstallUISequence

InstallExecuteSequence
Custom Action=PreventDowngrading 
After=FindRelatedProductsNEWERVERSIONFOUND/Custom
Custom Action=SetUpgradeReInstallProperty 
After=FindRelatedProductsOLDERVERSIONFOUND/Custom
Custom Action=SetUpgradeReInstallModeProperty 
After=FindRelatedProductsOLDERVERSIONFOUND/Custom
RemoveExistingProducts After=InstallFinalize /

Also evertying I

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]

This is really got me in a tail spin.

In my existing project started with 4004 and recently migrated to the latest 
wix drop regardless of whether I do or do not have a wixProject | properties 
| build | cultures field value specified my light.exe output is getting 
directed to bin\$(Configuration)\en-us.

In any file | new | wix project regardless of whether I do or do not have a 
wixProject | properties | build | cultures field value specified my light.exe 
output is getting directed to bin\$(Configuration).

Diff'ng both wixproj files I am unable to find anything different that would 
suggest why.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, September 10, 2008 6:47 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:
 If I clear my wixProject | properties | build | cultures to build field and 
 rebuild I'm still getting output in the bin\$(Configuration)\en-us folder.   
 Is there a way to restore build output landing in bin\$(Configuration) ?


Not that I'm aware of.

--
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=100url=/
___
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=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] does running upgrade msi orpatch msistill require additional command line switches?

[Robert O'Brien]

Based on some earlier dl responses I'm currently testing the following syntax 
to see if it accomplishes automatically setting the desired REINSTALL and 
REINSTALLMODE property values for both msp and msi minor upgrade processing.  
Not finalized yet whether it works or not.

Upgrade Id=D1652FA2-32AC-4D5B-8DCF-5DF11FE128BA
UpgradeVersion Minimum=1.1.0.0 IncludeMinimum=no OnlyDetect=yes 
Property=NEWERVERSIONFOUND /
UpgradeVersion Minimum=1.0.0.0 IncludeMinimum=yes 
Maximum=1.1.0.0 IncludeMaximum=no Property=OLDERVERSIONFOUND /
/Upgrade

!-- for msp  minor upgrade processing --
CustomAction Id=SetPatchReInstallProperty Property=REINSTALL 
Value=all /
CustomAction Id=SetPatchReInstallModeProperty Property=REINSTALLMODE 
Value=omus /

!-- for msi minor upgrade processing --
CustomAction Id=PreventDowngrading Error=Newer version already 
installed. /
CustomAction Id=SetUpgradeReInstallProperty Property=REINSTALL 
Value=all /
CustomAction Id=SetUpgradeReInstallModeProperty Property=REINSTALLMODE 
Value=vomus /

InstallUISequence
Custom Action=PreventDowngrading 
After=FindRelatedProductsNEWERVERSIONFOUND/Custom

InstallExecuteSequence
!-- for msp  minor upgrade processing --
Custom Action=SetPatchReInstallProperty 
After=LaunchConditionsPATCH AND Installed/Custom
Custom Action=SetPatchReInstallModeProperty 
After=SetPatchReInstallPropertyPATCH AND Installed/Custom

!-- for msi minor upgrade processing --
Custom Action=PreventDowngrading 
After=FindRelatedProductsNEWERVERSIONFOUND/Custom
Custom Action=SetUpgradeReInstallProperty 
After=FindRelatedProductsOLDERVERSIONFOUND/Custom
Custom Action=SetUpgradeReInstallModeProperty 
After=FindRelatedProductsOLDERVERSIONFOUND/Custom
RemoveExistingProducts After=InstallFinalize /




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yu, Brian
Sent: Wednesday, September 10, 2008 10:02 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] does running upgrade msi orpatch msistill require 
additional command line switches?

Is there an equivalent in MSI? i.e. can we do this in msi?
In the tutorial, it says it must be done via command line


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John
Nannenga
Sent: 10 September 2008 17:42
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] does running upgrade msi orpatch msistill
require additional command line switches?

The info I provided below was in response to the double click an MSP
file; not in regards to an MSI.

Good info to have, though...


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Yu, Brian
Sent: Wednesday, September 10, 2008 11:13 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] does running upgrade msi or patch msistill
require additional command line switches?

I had the same issue and used the following custom actions
But double clicking the new msi still fails to run as it complains
there's already a version running.

  CustomAction Id='AlreadyUpdated' Error='program is already
installed.' /
  CustomAction Id='NoDowngrade' Error='A later version of
program is already installed.' /
CustomAction Id='Patch_SetReinstall'
Property='REINSTALL'Value='ALL'/
CustomAction Id='Patch_SetReinstallMode'
Property='REINSTALLMODE'Value='vomus'/


InstallExecuteSequence
. other custom actions ...
Custom Action='AlreadyUpdated'
After='FindRelatedProducts'PATCHFOUND/Custom
  Custom Action='NoDowngrade'
After='FindRelatedProducts'NEWERFOUND/Custom
Custom Action='Patch_SetReinstall'
After=LaunchConditionsInstalled/Custom
Custom Action='Patch_SetReinstallMode'
After=Patch_SetReinstallInstalled/Custom
/InstallExecuteSequence

Yet without the custom actions of the Reinstalls, running this command
line works
msiexec -i program.msi REINSTALL=ALL REINSTALLMODE=vomus




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
O'Brien
Sent: 09 September 2008 19:20
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] does running upgrade msi or patch msistill
require additional command line switches?

Awesome thanks...so with this in place one should be able to just double
click on the My deliverable Small Update or Minor Upgrade Patch.msp
and get the desired result?

To set these required flags in the case of using a My Deliverable Small
Update or Minor Upgrade.msi approach to update an existing install
would I include similar CustomActions but use the condition UPGRADE and
Installed versus PATCH and Installed?

In an earlier response it was suggested that to execute a minor upgrade
you need reinstallmode=vomus

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]

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?

WixLocalization Culture=en-us 
xmlns=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 is 
so you can set up different configurations, for example, to control which 
languages get built for different types of builds).

The only way to disable this is to remove the .wxl files from the project that 
are for other languages. You could also perhaps do some tweaking to the project 
file to conditionally include those .wxl files based on a flag somewhere, but 
that would be some additional work and tweaking.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 11, 2008 1: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

This is really got me in a tail spin.

In my existing project started with 4004 and recently migrated to the latest 
wix drop regardless of whether I do or do not have a wixProject | properties 
| build | cultures field value specified my light.exe output is getting 
directed to bin\$(Configuration)\en-us.

In any file | new | wix project regardless of whether I do or do not have a 
wixProject | properties | build | cultures field value specified my light.exe 
output is getting directed to bin\$(Configuration).

Diff'ng both wixproj files I am unable to find anything different that would 
suggest why.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, September 10, 2008 6:47 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:
 If I clear my wixProject | properties | build | cultures to build field and 
 rebuild I'm still getting output in the bin\$(Configuration)\en-us folder.   
 Is there a way to restore build output landing in bin\$(Configuration) ?


Not that I'm aware of.

--
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=100url=/
___
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=100url=/
___
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=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists

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]

Scratch that question I tried removing the Culture=en-us attribute and saw 
that it is not optional.   So it seems that with the current wix framework the 
moment you add Resources\Strings.wxl WixLocalization / file to your sources 
you can expect build output to start showing up in 
bin\$(Configuration)\wixLocalizationCultureAttribValue.

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

WixLocalization Culture=en-us 
xmlns=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 is 
so you can set up different configurations, for example, to control which 
languages get built for different types of builds).

The only way to disable this is to remove the .wxl files from the project that 
are for other languages. You could also perhaps do some tweaking to the project 
file to conditionally include those .wxl files based on a flag somewhere, but 
that would be some additional work and tweaking.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 11, 2008 1: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

This is really got me in a tail spin.

In my existing project started with 4004 and recently migrated to the latest 
wix drop regardless of whether I do or do not have a wixProject | properties 
| build | cultures field value specified my light.exe output is getting 
directed to bin\$(Configuration)\en-us.

In any file | new | wix project regardless of whether I do or do not have a 
wixProject | properties | build | cultures field value specified my light.exe 
output is getting directed to bin\$(Configuration).

Diff'ng both wixproj files I am unable to find anything different that would 
suggest why.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, September 10, 2008 6:47 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:
 If I clear my wixProject | properties | build | cultures to build field and 
 rebuild I'm still getting output in the bin\$(Configuration)\en-us folder.   
 Is there a way to restore build output landing in bin\$(Configuration) ?


Not that I'm aware of.

--
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=100url=/
___
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] 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 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)lang-local\$(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)\lang-locale 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?

WixLocalization Culture=en-us 
xmlns=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 is 
so you can set up different configurations, for example, to control which 
languages get built for different types of builds).

The only way to disable this is to remove the .wxl files from the project that 
are for other languages. You could also perhaps do some tweaking to the project 
file to conditionally include those .wxl files based on a flag somewhere, but 
that would be some additional work and tweaking.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 11, 2008 1: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

This is really got me in a tail spin.

In my existing project started with 4004 and recently migrated to the latest 
wix drop regardless of whether I do or do not have a wixProject | properties 
| build | cultures field value specified my light.exe output is getting 
directed to bin\$(Configuration)\en-us.

In any file | new | wix project regardless of whether I do or do not have a 
wixProject | properties | build | cultures field value specified my light.exe 
output is getting directed to bin\$(Configuration).

Diff'ng both wixproj files I am unable to find anything different that would 
suggest

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=100url=/
___
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=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[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?
CustomAction Id=QtExecCmdLineSet9 Property=QtExecCmdLineRun9 
Value=quot;[$(var.SystemFolder)]net.exequot; start 
NS$EventingMSSolveInstance /
CustomAction Id=QtExecCmdLineRun9 BinaryKey=WixCA DllEntry=CAQuietExec 
Execute=deferred Return=ignore /
CustomAction Id=QtExecCmdLineSet102 Property=QtExecCmdLineRun102 
Value=quot;[$(var.SystemFolder)]net.exequot; stop 
NS$EventingMSSolveInstance /
CustomAction Id=QtExecCmdLineRun102 BinaryKey=WixCA DllEntry=CAQuietExec 
Execute=deferred Return=ignore /

Custom Action=QtExecCmdLineSet9 Before=???Installed And PATCH or 
UPGRADE/Custom
Custom Action=QtExecCmdLineRun9 Before=QtExecCmdLineSet9Installed And 
PATCH or UPGRADE /Custom
Custom Action=QtExecCmdLineSet102 Before=???Installed And PATCH or 
UPGRADE/Custom
Custom Action=QtExecCmdLineRun102 Before=QtExecCmdLineSet9Installed And 
PATCH or UPGRADE /Custom

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.0adminInstallfile:///\\rpbuildagent03\builds\RXP%20Eventing\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

Re: [WiX-users] using a Variable for Plaform setting causes undesired build warning

[Robert O'Brien]

Thanks and just to confirm that when doing this you no longer need the Package 
/ element Platform attribute setting, i.e. Package InstallerVersion=200 
Compressed=yes / is all you need or should I be using Package 
InstallerVersion=200 Compressed=yes Platform=$(var.Platform) / ?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Ginchereau
Sent: Monday, September 08, 2008 10:25 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] using a Variable for Plaform setting causes undesired 
build warning

 adding a new solution platform type = x64
Yes, that is the recommended approach. Use the VS Configuration Manager tool to 
add an x64 platform to the project, and optionally an x64 solution platform.

When using that method, if you need to check the current platform within the 
WiX source code, the corresponding variable that's autogenerated during the 
build is $(var.Platform).

-Jason-

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Monday, September 08, 2008 7:35 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] using a Variable for Plaform setting causes undesired 
build warning

When I use the current wix project templates by default it creates projects 
with Debug|x86 and Release|x86 configurations.

I'm interpreting the bug closure details below to suggest that I no longer need 
to use Package InstallerVersion=200 Compressed=yes 
Platform=$(var.TargetPlatform) / to set the package platform type and 
can/should instead use Package InstallerVersion=200 Compressed=yes / and 
let the build configuration manager | project | platform setting control 
whether I'm getting an x64 or x86 msi output.

If that is correct then is it correct that users wanting x64 output are 
responsible for adding a new solution platform type = x64 after the default 
new wix project wizard completes and select that as the platform type when the 
wix project gets built in order to product x64 msi output?



Date: 2008-09-07 12:40
Sender: barnson
Logged In: YES
user_id=26581
Originator: NO

The message comes from VS trying to validate the source against the
schema, which can't represent the preprocessor. Instead of using
preprocessor variables, you can set the architecture in project properties
and let it automatically set the package and component bitness.



Using a Variable for Plaform setting causes undesired build warning.

?ifndef TargetPlatform ?
?define TargetPlatform = x64 ?
!--?define TargetPlatform = intel ?-- !-- == x86 --
?endif?

Package InstallerVersion=200 Compressed=yes
Platform=$(var.TargetPlatform) /

Warning 1 The 'Platform' attribute is invalid - The value
'$(var.TargetPlatform)' is invalid according to its datatype 'NmToken' -
The '$' character, hexadecimal value 0x24, cannot be included in a
name. D:\tfswf\ws0\RXD_RXG_PTF\RXP
Eventing\Main\Setup\Setup\Product.wxs 15 68 Setup (Setup\Setup)


The reason I want to use a variable for Platform setting is so I can maintain 
wix
sources that like the following for Components that reference Any CPU output.

Component Id=Counter Guid=2A14A83A-F0F0-407D-8A4D-DA58242325C6 
Win64=$(var.Win64)

based on following variable settings

?if $(var.TargetPlatform) = x64 ?
?define ProcessorArchitecture = amd64 ?
?define ProcessorType = x64 ?
?define ProgramFilesFolder = ProgramFiles64Folder ?
?define ProgramFilesFolderX86 = ProgramFilesFolder ?
?define SystemFolder = System64Folder ?
?define SystemFolderX86 = SystemFolder ?
?define SoftwareKey = Software ?
?define SoftwareKeyX86 = Software\Wow6432Node ?
?define DotNetFramework20Folder =
[%SystemRoot]\Microsoft.NET\Framework64\v2.0.50727\ ?
?define DotNetFramework35Folder =
[%SystemRoot]\Microsoft.NET\Framework64\v3.5\ ?
?define Win64 = yes ?
?else?
?define ProcessorArchitecture = x86 ?
?define ProcessorType = x86 ?
?define ProgramFilesFolder = ProgramFilesFolder ?
?define ProgramFilesFolderX86 = ProgramFilesFolder ?
?define SystemFolder = SystemFolder ?
?define SystemFolderX86 = SystemFolder ?
?define DotNetFramework20Folder =
[%SystemRoot]\Microsoft.NET\Framework\v2.0.50727\ ?
?define DotNetFramework35Folder =
[%SystemRoot]\Microsoft.NET\Framework\v3.5\ ?
?define SoftwareKey = Software ?
?define SoftwareKeyX86 = Software ?
?define Win64 = no ?
?endif?
-
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

Re: [WiX-users] does running upgrade msi or patch msi still require additional command line switches?

[Robert O'Brien]

Awesome thanks...so with this in place one should be able to just double click 
on the My deliverable Small Update or Minor Upgrade Patch.msp and get the 
desired result?

To set these required flags in the case of using a My Deliverable Small Update 
or Minor Upgrade.msi approach to update an existing install would I include 
similar CustomActions but use the condition UPGRADE and Installed versus 
PATCH and Installed?

In an earlier response it was suggested that to execute a minor upgrade you 
need reinstallmode=vomus not omus for this to work.  Is that only for the 
case of applying a minor upgrade using a My Deliverable Small Update or Minor 
Upgrade.msi approach to update an existing install?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Tuesday, September 09, 2008 7:32 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] does running upgrade msi or patch msi still require 
additional command line switches?

In our installs, we don't utilize a patch wrapper.

Instead, we set the REINSTALL and REINSTALLMODES appropriately within our 
installation(s)...

CustomAction Id='Patch_SetReinstall'   
Property='REINSTALL'Value='ALL'/
CustomAction Id='Patch_SetReinstallMode'   
Property='REINSTALLMODE'Value='omus'/

InstallExecuteSequence
...
LaunchConditions/
Custom Action='Patch_SetReinstall' 
After=LaunchConditionsPATCH and Installed/Custom
Custom Action='Patch_SetReinstallMode' 
After=Patch_SetReinstallPATCH and Installed/Custom
...
/InstallExecuteSequence


With respect to multiple instances, the customer applies the patch via the 
command line passing in the instance product code to patch if they don't want 
all relevant instances updated by double clicking on the MSP file.



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pally Sandher
Sent: Tuesday, September 09, 2008 5:54 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] does running upgrade msi or patch msi still require 
additional command line switches?

Bob Arnson wrote:
Robert O'Brien wrote:
 q2 - do the same REINSTALLMODE switch settings apply when trying to
use a patch to carry out a minor or major upgrade?

Yes, though usually MSI picks the right values for you. Though patches
aren't generally double-click installable; you usually need to provide a
wrapper.

I've yet to find a way to generate an MSP which doesn't need a wrapper
executable or be launched using msiexec /p to work as one would expect.
If anyone knows how, please share so we can update the WiX 3.0
documentation accordingly.

Palbinder Sandher
Software Deployment and IT Administrator

T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com

**Design, Simulate + Innovate with the Virtual Environment**

Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP

Email Disclaimer


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: 07 September 2008 21:16
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] does running upgrade msi or patch msi still
require additional command line switches?

Robert O'Brien wrote:
 q2 - do the same REINSTALLMODE switch settings apply when trying to
use a patch to carry out a minor or major upgrade?

Yes, though usually MSI picks the right values for you. Though patches
aren't generally double-click installable; you usually need to provide a
wrapper.

 Our understanding at this point of a patch vs and upgrade is the patch
provides rollback to prior release support where a upgrade does not...is
that correct?


Only for minor upgrade patches. Major upgrade patches are discouraged
and aren't uninstallable.

 q3 - Would the following be something that you'd expect to work in
terms of providing a way for users NOT to have to enter the required
command line switch settings to get a minor upgrade to work?


No, that would be a major upgrade.

--
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=100url=/
___
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

[WiX-users] using a Variable for Plaform setting causes undesired build warning

[Robert O'Brien]

When I use the current wix project templates by default it creates projects 
with Debug|x86 and Release|x86 configurations.

I'm interpreting the bug closure details below to suggest that I no longer need 
to use Package InstallerVersion=200 Compressed=yes 
Platform=$(var.TargetPlatform) / to set the package platform type and 
can/should instead use Package InstallerVersion=200 Compressed=yes / and 
let the build configuration manager | project | platform setting control 
whether I'm getting an x64 or x86 msi output.

If that is correct then is it correct that users wanting x64 output are 
responsible for adding a new solution platform type = x64 after the default 
new wix project wizard completes and select that as the platform type when the 
wix project gets built in order to product x64 msi output?



Date: 2008-09-07 12:40
Sender: barnson
Logged In: YES
user_id=26581
Originator: NO

The message comes from VS trying to validate the source against the
schema, which can't represent the preprocessor. Instead of using
preprocessor variables, you can set the architecture in project properties
and let it automatically set the package and component bitness.



Using a Variable for Plaform setting causes undesired build warning.

?ifndef TargetPlatform ?
?define TargetPlatform = x64 ?
!--?define TargetPlatform = intel ?-- !-- == x86 --
?endif?

Package InstallerVersion=200 Compressed=yes
Platform=$(var.TargetPlatform) /

Warning 1 The 'Platform' attribute is invalid - The value
'$(var.TargetPlatform)' is invalid according to its datatype 'NmToken' -
The '$' character, hexadecimal value 0x24, cannot be included in a
name. D:\tfswf\ws0\RXD_RXG_PTF\RXP
Eventing\Main\Setup\Setup\Product.wxs 15 68 Setup (Setup\Setup)


The reason I want to use a variable for Platform setting is so I can maintain 
wix
sources that like the following for Components that reference Any CPU output.

Component Id=Counter Guid=2A14A83A-F0F0-407D-8A4D-DA58242325C6 
Win64=$(var.Win64)

based on following variable settings

?if $(var.TargetPlatform) = x64 ?
?define ProcessorArchitecture = amd64 ?
?define ProcessorType = x64 ?
?define ProgramFilesFolder = ProgramFiles64Folder ?
?define ProgramFilesFolderX86 = ProgramFilesFolder ?
?define SystemFolder = System64Folder ?
?define SystemFolderX86 = SystemFolder ?
?define SoftwareKey = Software ?
?define SoftwareKeyX86 = Software\Wow6432Node ?
?define DotNetFramework20Folder =
[%SystemRoot]\Microsoft.NET\Framework64\v2.0.50727\ ?
?define DotNetFramework35Folder =
[%SystemRoot]\Microsoft.NET\Framework64\v3.5\ ?
?define Win64 = yes ?
?else?
?define ProcessorArchitecture = x86 ?
?define ProcessorType = x86 ?
?define ProgramFilesFolder = ProgramFilesFolder ?
?define ProgramFilesFolderX86 = ProgramFilesFolder ?
?define SystemFolder = SystemFolder ?
?define SystemFolderX86 = SystemFolder ?
?define DotNetFramework20Folder =
[%SystemRoot]\Microsoft.NET\Framework\v2.0.50727\ ?
?define DotNetFramework35Folder =
[%SystemRoot]\Microsoft.NET\Framework\v3.5\ ?
?define SoftwareKey = Software ?
?define SoftwareKeyX86 = Software ?
?define Win64 = no ?
?endif?
-
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=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

what setting causes current wix build output to land in 
bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used to 
land?

I have an existing solution deliverable containing a wix project created 
initially using 4004.   After migrating the file to contain the wixproj file 
settings that I could see differ in the current wix3_x64.msi drop I find that 
my build output now lands in bin\$(Configuration)\en-us.

If I create a new wix project from scratch and build it the build output lands 
in the expected bin\$(Configuration).

The difference is causing me gyrations with our tfs automated build processing 
since with tfs the expection is all automated build output gets redirected into 
a flat $(OutDir) directory structure.

Any thoughts on what setting(s) in my existing wix project that I've migrated 
to work with current wix is causing build output to land in 
bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used to 
land?
-
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=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] does running upgrade msi or patch msi still require additional command line switches?

[Robert O'Brien]

Thanks for the response.

q1 - So is minor upgrade depicted just by a wix sources change such as the 
following Product Version=1.0.0.0 - 1.1.0.0 /
and minor upgrade is depicted just by a wix sources change such as the 
following Product Version=1.1.0.0 - 2.0.0.0 /?

q2 - do the same REINSTALLMODE switch settings apply when trying to use a patch 
to carry out a minor or major upgrade?   Our understanding at this point of a 
patch vs and upgrade is the patch provides rollback to prior release support 
where a upgrade does not...is that correct?

q3 - Would the following be something that you'd expect to work in terms of 
providing a way for users NOT to have to enter the required command line switch 
settings to get a minor upgrade to work?

Upgrade Id=D1652FA2-32AC-4D5B-8DCF-5DF11FE128BA
   UpgradeVersion Minimum=1.1.0.0 IncludeMinimum=no OnlyDetect=yes 
Property=NEWERVERSIONFOUND /
   UpgradeVersion Minimum=1.0.0.0 IncludeMinimum=yes Maximum=1.1.0.0 
IncludeMaximum=no Property=OLDERVERSIONFOUND /
/Upgrade

CustomAction Id=PreventDowngrading Error=Newer version already installed. 
/
CustomAction Id=SetReInstallProperty Property=REINSTALL Value=all 
Execute=firstSequence /
CustomAction Id=SetReInstallModeProperty Property=REINSTALLMODE 
Value=vomus Execute=firstSequence /

InstallExecuteSequence
Custom Action=PreventDowngrading 
After=FindRelatedProductsNEWERVERSIONFOUND/Custom
Custom Action=SetReInstallProperty 
After=FindRelatedProductsOLDERVERSIONFOUND/Custom
Custom Action=SetReInstallModeProperty 
After=FindRelatedProductsOLDERVERSIONFOUND/Custom
RemoveExistingProducts 
After=InstallFinalizeOLDERVERSIONFOUND/RemoveExistingProducts


-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] does running upgrade msi or patch msi still require 
additional command line switches?

Robert O'Brien wrote:
 Q1 - does running upgrade msi or patch msi still require additional command 
 line switches?


Minor upgrades must be applied with arguments. Major upgrades don't need
them.

 Q2 - I seem to recall running into upgrade capable msi's and patch msp's that 
 I could simple double click on and successfully upgrade or patch an existing 
 msi install w/o the need for launching from a command line and including the 
 noted switch settings.   Are those upgrade msi and patch msp's doing 
 something custom to avoid the need for that command line parameter?


They're major upgrades.

 Q3 - Is the tutorial denoted difference in the REINSTALLMODE switch setting 
 for a upgrade msi and patch msp, i.e. vomus versus omus, a typo or is the 
 v some kind of verbose reinstall mode flag?


See the MSI SDK doc for REINSTALLMODE. You need the 'v' for minor
upgrades but can't have it for the initial install.

--
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=100url=/
___
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=100url=/
___
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]

If I clear my wixProject | properties | build | cultures to build field and 
rebuild I'm still getting output in the bin\$(Configuration)\en-us folder.   Is 
there a way to restore build output landing in bin\$(Configuration) ?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Sunday, September 07, 2008 1:34 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:
 what setting causes current wix build output to land in 
 bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
 to land?


The Cultures setting. Every culture results in a culture-specific output
in the specified subdirectory.

--
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=100url=/
___
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=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users