Re: [WiX-users] How to create only installer for 32 Bit and 64 bit OS

[Robert O'Brien]

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































  

 



   
   




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

Hi,

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


Regards
Sandeep

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Populating Data into List Box.

[pavan gadam]

Hi all,

I am facing a problem in populating data into ListBox.

I am using 2 buttons viz., " Add" and "Remove" to insert and remove Values
into ListBox.

I am calling a Custom Action to achieve this.

After Adding few values into ListBox. If i try to remove any element in the
ListBox and then try adding Again,
I am getting an error as *Function failed during execution. Database:
Table(s) Update failed.*

The code i am using in the Custom Action are as given below:

[ Add Button ]
___

i = s.Database.CountRows("ListBox");

View v;

v = s.Database.OpenView("INSERT INTO `ListBox`
(`Property`,`Order`,`Value`,`Text`) VALUES ('MACLIST'," + (i) + ",'" + s[
"MACNAME"] + "','" + s["MACNAME"] + "')TEMPORARY");

v.Execute();

v.Close();


[Remove
Button]

View v;

v = s.Database.OpenView("DELETE FROM `ListBox` WHERE (`Value`='"+s["MACLIST"
]+"')");

v.Execute();

v.Close();

___

Please let me know where i might be going wrong.

Thanks,

Pavan
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

[Neil Enns]

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

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

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



The result in my test project is this:

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

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

Neil


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

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

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

Robert,

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

Neil


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

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

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

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

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


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

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

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

Neil

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

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

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

For now since we only build Language="1033" setup outp

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

[Robert O'Brien]

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

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

Robert,

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

Neil


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

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

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

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

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


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

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

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

Neil

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

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

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

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

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

Robert,

This happens when you have multiple .wxl files in your project with different 
cultures in them. Setting the Cultures field in properties will control which 
languages get built, but the output will still go into the sub-folder (this is 
so you can set up different configurations, for example, to co

[WiX-users] How to create only installer for 32 Bit and 64 bit OS

[Sandeep Gautam (HCL Technologies Ltd)]

Hi,

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


Regards
Sandeep

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

[Sandeep Gautam (HCL Technologies Ltd)]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 11, 2008 6:35 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] getting working v1.0 -> v1.0 minor update using msp & msi 
solutions pulled together

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

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

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

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

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

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

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

-

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

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

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

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

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

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

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

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

-



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
__

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

[Robert O'Brien]

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

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

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

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

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





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

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

-

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

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

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

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

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

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

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

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

-


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

[Neil Enns]

Robert,

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

Neil


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

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

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

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

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


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

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

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

Neil

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

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

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

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

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

Robert,

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

Re: [WiX-users] multiple languages in single installer

[Neil Sleightholm]

I haven't found a way to do it with a single msi that is supported. The 
approach I take is to not embed the files in your MSI but put them in an 
external cab file. Then I build each language variant, as they only contain the 
install code and not the files they tend to be quite small. I then use a 
bootstrapper that loads the appropriate MSI for the current language.
 
Neil
 
Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]  
 



From: [EMAIL PROTECTED] on behalf of Jeb Remus
Sent: Wed 10/09/2008 12:47
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] multiple languages in single installer




Hello,

I understand how WIX can generate N installer for N different 
language files, which is really great.  I was wondering however if there is any 
functionality to combine N language files into a single installer, that would 
detect user or system locale at run time.  Any help or pointers would be 
awesome, thanks much.

-Jeb Remus
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Debugging C++ Custom Actions

[Neil Enns]

I've found the MsiBreak environment variable is a very useful tool for 
debugging custom actions. See 
http://msdn.microsoft.com/en-us/library/aa368264.aspx for the details, but in a 
nutshell:

1) Start a command prompt (if you are on Vista make sure it is elevated. XP 
make sure you are an admin)
2) Set the MsiBreak environment variable to the name of your custom action
3) Run the MSI from within the command prompt window

MSI will throw a dialog up before it runs your custom action with the process 
number you should attach to. Then attach to that process, click on on the MSI 
dialog, and it'll automatically break at the start of your custom action. You 
can then debug from there.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Tony Juricic [EMAIL 
PROTECTED]
Sent: Thursday, September 11, 2008 4:47 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Debugging C++ Custom Actions

I often encounter problems debugging deferred C++ DLL CAs. Most of the
time DebugBreak() works. Now and then it won't and then I use __asm {
int 3 } which, for some reason, tends to work more often than
DebugBreak.

Then I encounter situations when even int 3 won't work in the sense that
Vista (and 4.0 Installer) does not offer me a chance to break into the
debugger but, instead, shows a dialog box saying "Windows installer
stopped working and was closed".

In this dialog I can only press Close button and my installation appears
successful. I just appears so because the bunch of CA code that was
supposed to execute after int 3 didn't execute and that is fatal for my
apps.
If I remove int 3 (or DebugBreak()) then I don't see the dialog box
mentioned above and but that doesn't help my debugging.

Do you encounter similar problems and can anybody suggest reliable
method to break into deferred action DLL code?

Thanks!

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Debugging C++ Custom Actions

[Tony Juricic]

I often encounter problems debugging deferred C++ DLL CAs. Most of the
time DebugBreak() works. Now and then it won't and then I use __asm {
int 3 } which, for some reason, tends to work more often than
DebugBreak. 

Then I encounter situations when even int 3 won't work in the sense that
Vista (and 4.0 Installer) does not offer me a chance to break into the
debugger but, instead, shows a dialog box saying "Windows installer
stopped working and was closed". 

In this dialog I can only press Close button and my installation appears
successful. I just appears so because the bunch of CA code that was
supposed to execute after int 3 didn't execute and that is fatal for my
apps.
If I remove int 3 (or DebugBreak()) then I don't see the dialog box
mentioned above and but that doesn't help my debugging.

Do you encounter similar problems and can anybody suggest reliable
method to break into deferred action DLL code?

Thanks!

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

[Neil Enns]

Ok. Let me think about this tonight, there are likely a couple of solutions to 
this that will work.

Neil

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

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

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

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

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


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

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

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

Neil

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

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

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

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

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

Robert,

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

[WiX-users] WixUI_InstallMode not set properly with msiexec /qf /x

[jstanley0]

Using Wix 3.0.4318.  I built an installer based on WixUI_InstallDir.  Running
msiexec /qf /x [ProductCode] does uninstall the product correctly, but the
progress dialog makes it look like it is actually installing it.  It appears
WixUI_InstallMode isn't set to "Remove" like it should be.  Am I overlooking
something, or is this a bug in WiX?
-- 
View this message in context: 
http://n2.nabble.com/WixUI_InstallMode-not-set-properly-with-msiexec--qf--x-tp1083909p1083909.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error DARK0143

[GreBen]

I found a workaround. Open the Wise generated MSI with orca and right click
on the CustomActions table and select "Adjust Schema" now add a new column
at the bottom called ExtendedType (Short Int, Nullable).  Now you should be
able to use dark on the msi. You may want to remove the other Custom tables
Wise adds to minimize the size of you output source file.


~G

* Note: you may have to add or delete a row to get orca to save the change

Bob Arnson-6 wrote:
> 
> Mathur, Uttam (GTS) wrote:
>> I searched on this forum and got to know that its an bug. Just wondering
>> if we have any solution or workaround today? I am using latest WIX
>> 3.0.4311.0.
>>   
> 
> The only workaround is to use an older version. MSI 4.5 adds columns, 
> and Dark doesn't know how to deal with .msi packages with a different 
> number of columns than the current set.
> 
> -- 
> sig://boB
> http://joyofsetup.com/
> 
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 

-- 
View this message in context: 
http://n2.nabble.com/Error-DARK0143-tp710218p1083848.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Check Windows Installer Runtime Version in Wix v3

[Jason Ding]

Hello All,

 

Anyone has an idea about how to check Windows Installer Runtime Version
in Wix v3 as an install condition? Thanks for help.

 

Jason

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Has anybody got this to work??

[CHarker]

I have been having problems trying to install a service. I am the admin user
in this machine but I keep getting permission problems. I am using WIX
3.0.4429.0 

Without the  tag and the  tags it works
perfectly. 

I added serviceConfig and then PermissionEx to try and solve permission
issues with  

My question is. When you use a  inside a 
what permissions are you setting exactly?  Is this the user that is running
the msi job itself?  Does the Service changes take place using this user or
the user that run sthe MSI? 

Inside the  tag I have used "User", "Administrator",
"LocalSystem" and various others but I either ge "SID not found" or
"Permission Denied" when it runs the  section. 

I am running the MSI and I am an admin user. I can set the config through
the GUI so I should have permissions.  I used "Administrator" and I get SID
not found. 

 
 
 
 

 

http://schemas.microsoft.com/wix/UtilExtension"; 
User="Administrator" 
ServiceChangeConfig="yes" 
ServiceEnumerateDependents="yes" 
ChangePermission="yes" 
ServiceInterrogate="yes" 
ServicePauseContinue="yes" 
ServiceQueryConfig="yes" 
ServiceQueryStatus="yes" 
ServiceStart="yes" 
ServiceStop="yes" /> 

http://schemas.microsoft.com/wix/UtilExtension"; 
 RebootMessage ="Problem with Service requires a reboot" 
 ResetPeriodInDays="3" 
 RestartServiceDelayInSeconds="5" 
 FirstFailureActionType="restart" 
 SecondFailureActionType="restart" 
 ThirdFailureActionType="reboot"/> 

 
 

 
 

My MSIEXEC output is 

=== Logging started: 11/09/2008  10:19:26 === 
Action 10:19:26: INSTALL. 
Action start 10:19:26: INSTALL. 
Action 10:19:26: ValidateProductID. 
Action start 10:19:26: ValidateProductID. 
Action ended 10:19:26: ValidateProductID. Return value 1. 
Action 10:19:26: CostInitialize. Computing space requirements 
Action start 10:19:26: CostInitialize. 
Action ended 10:19:26: CostInitialize. Return value 1. 
Action 10:19:26: FileCost. Computing space requirements 
Action start 10:19:26: FileCost. 
Action ended 10:19:26: FileCost. Return value 1. 
Action 10:19:26: CostFinalize. Computing space requirements 
Action start 10:19:26: CostFinalize. 
Action ended 10:19:26: CostFinalize. Return value 1. 
Action 10:19:26: ExecuteAction. 
Action start 10:19:26: ExecuteAction. 
Action start 10:19:26: INSTALL. 
Action start 10:19:26: ValidateProductID. 
Action ended 10:19:26: ValidateProductID. Return value 1. 
Action start 10:19:26: CostInitialize. 
Action ended 10:19:26: CostInitialize. Return value 1. 
Action start 10:19:26: FileCost. 
Action ended 10:19:26: FileCost. Return value 1. 
Action start 10:19:26: CostFinalize. 
Action ended 10:19:26: CostFinalize. Return value 1. 
Action start 10:19:26: InstallValidate. 
Action ended 10:19:26: InstallValidate. Return value 1. 
Action start 10:19:26: InstallInitialize. 
Action ended 10:19:26: InstallInitialize. Return value 1. 
Action start 10:19:26: ProcessComponents. 
Action ended 10:19:26: ProcessComponents. Return value 1. 
Action start 10:19:26: UnpublishFeatures. 
Action ended 10:19:26: UnpublishFeatures. Return value 1. 
Action start 10:19:26: StopServices. 
Action ended 10:19:26: StopServices. Return value 1. 
Action start 10:19:26: DeleteServices. 
Action ended 10:19:26: DeleteServices. Return value 1. 
Action start 10:19:26: RemoveFiles. 
Action ended 10:19:26: RemoveFiles. Return value 0. 
Action start 10:19:26: InstallFiles. 
Action ended 10:19:26: InstallFiles. Return value 1. 
Action start 10:19:26: InstallServices. 
Action ended 10:19:26: InstallServices. Return value 1. 
Action start 10:19:26: SchedSecureObjects. 
Action start 10:19:27: ExecSecureObjects. 
Action ended 10:19:27: ExecSecureObjects. Return value 1. 
Action ended 10:19:27: SchedSecureObjects. Return value 1. 
Action start 10:19:27: SchedServiceConfig. 
Action start 10:19:27: RollbackServiceConfig. 
Action ended 10:19:27: RollbackServiceConfig. Return value 1. 
Action start 10:19:27: ExecServiceConfig. 
Action ended 10:19:27: ExecServiceConfig. Return value 1. 
Action ended 10:19:27: SchedServiceConfig. Return value 1. 
Action start 10:19:27: StartServices. 
Action ended 10:19:27: StartServices. Return value 1. 
Action start 10:19:27: RegisterUser. 
Action ended 10:19:27: RegisterUser. Return value 1. 
Action start 10:19:27: RegisterProduct. 
Action ended 10:19:27: RegisterProduct. Return value 1. 
Action start 10:19:27: PublishFeatures. 
Action ended 10:19:27: PublishFeatures. Return value 1. 
Action start 10:19:27: PublishProduct. 
Action ended 10:19:27: PublishProduct. Return value 1. 
Action start 10:19:27: InstallFinalize. 
ExecSecureObjects:  Error 0x80070534: failed to get sid for account:
Administrator 
Action ended 10:19:27: InstallFinalize. Return value 3. 
Ac

Re: [WiX-users] Wix Service - grant logon rights

[Richard]

In article <[EMAIL PROTECTED]>,
Rob Mensching <[EMAIL PROTECTED]>  writes:

> Services don't get logon rights.  Users do.

True, but services do run as a particular user.  By default this is
"system" IIRC, but its a gigantic security hole to run your services
as system.  Best practice is to create an account with the appropriate
privileges and permissions and then configure the service to run as
that account.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] multiple languages in single installer

[Rob Mensching]

Like pretty much everything else that looks like it works but isn't officially 
approved is due to the fact that "it" doesn't always work correctly.  I do not 
remember the specific case here but I'm pretty sure it had to do with some UI 
cases.

Anyway, using features that aren't documented to work creates one or both of 
the following problems:

1.  You app might break in the future (if the Windows Installer changes it's 
behavior).

2.  The platform gets stuck supporting poor designs because some "popular" 
application(s) decided to take a dependency on a non-supported feature.  If 
this doesn't make sense, go read Raymond Chen's blog for a while.  

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DEÁK JAHN, Gábor
Sent: Thursday, September 11, 2008 10:41
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] multiple languages in single installer

On Wed, 10 Sep 2008 12:47:57 -0700, Jeb Remus wrote:

Jeb,

> I understand how WIX can generate N installer for N different
> language files, which is really great.  I was wondering however if
> there is any functionality to combine N language files into a
> single installer, that would detect user or system locale at run time.

Yes, see 
http://www.installsite.org/pages/en/msi/articles/embeddedlang/index.htm . It 
isn't documented but MS itself uses it (actually, because it is very 
straightforward and I can't see any reason for abandoning this feature in any 
coming version of Windows Installer, I don't really understand why it isn't 
officially approved).

Bye,
   Gábor

---
DEÁK JAHN, Gábor -- Budapest, Hungary
E-mail: [EMAIL PROTECTED]

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] is there a way to get current wix vs08 project extensions to output a patch msp?

[Robert O'Brien]

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

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

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

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

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


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

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

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

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



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix Service - grant logon rights

[Rob Mensching]

Services don't get logon rights.  Users do.

Why are you installing a service with a CusotmAction?  The Windows Installer 
supports that natively.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yu, Brian
Sent: Thursday, September 11, 2008 09:39
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Wix Service - grant logon rights

How do u grant logon rights to services created by custom actions?




  Not
Installed OR REINSTALL
  


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX Burn bootstrapper

[Rob Mensching]

Thanks.

I feel like my "spidey-sense" has been ripped out through my spine.  I barely 
know which way is up right now.

But the future is incredibly cool.  


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Lewis
Sent: Thursday, September 11, 2008 11:42
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX Burn bootstrapper

Hi Rob,

Thanks for the fast reply, I think WiX is great and look forward to the
continuing developments.

I hope the first few days with the LiveMesh team are going well.

All the best,
Paul

Rob Mensching wrote:
> Burn is a thing that I dreamed would make it in WiX v3.0 but it didn't 
> (http://robmensching.com/blog/archive/2008/06/06/Proposed-adjustments-the-WiX-v2-and-WiX-v3-roadmap.aspx).
>  Since then Bob and I have kicked things about a little and now we are 
> thinking about making it the focus of a WiX v3.5.
>
> I'm working on a comprehensive write-up about thoughts for WiX v3.0 and v3.5 
> and v4.0 (i.e. roadmap for next couple years).  I've just been a little 
> buried lately 
> (http://robmensching.com/blog/archive/2008/08/15/When-it-changes-it-pours-again.aspx).
>   
>
> My current hope is that Burn is well under development by first month of next 
> year.  That is largely dependent on how quickly we kill off all of the WiX v3 
> bugs.  I don't want to lose focus on WiX v3.
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Lewis
> Sent: Thursday, September 11, 2008 08:34
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] WiX Burn bootstrapper
>
> Hi Folks,
>
> I'm quite new to WiX and I'm looking at using it to build an install
> project that requires chaining a couple of simple MSI's together.
>
> I've read a little about the Burn Bootstrapper, and that it has been
> dropped from the WiX v3 roadmap.
>
> http://sourceforge.net/mailarchive/message.php?msg_id=358106.95478.qm%40web36606.mail.mud.yahoo.com
> http://www.joyofsetup.com/2008/06/21/wix-burn-volume-1-layers/
>
> I was wondering what the current state of Burn is?
>
> I do not see it in the source repository (unless I missed it), would it
> be possible to get a copy of the work in progress?
>
> I was thinking it may be preferable as a starting point in any state
> than starting with the existing 'setupbld' and 'setupexe' projects in WiX.
>
> Any feedback is greatly appreciated.
>
> Best Regards,
> Paul
>
> --
> -
> Paul Lewis
> Software Engineer
> Wimba - People Teach People
>
> 10 East 40th Street, Floor 11
> New York, NY 10016
> [EMAIL PROTECTED]
> http://www.wimba.com
> -
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
-
Paul Lewis
Software Engineer
Wimba - People Teach People

10 East 40th Street, Floor 11
New York, NY 10016
[EMAIL PROTECTED]
http://www.wimba.com
-


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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)\$(TargetName) steps, e.g. 
$(TargetDir)en-us\$(TargetName).

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


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

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

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

Neil

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

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

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

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

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

Robert,

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

Re: [WiX-users] Install only on XP SP2 or better

[Vivek]

I am a newbie to Wix, I was trying to do the same this which you have
discussed a long time back.
I am facing problem when i put a check of VersionNT inside Condition
Element.
My code looks like this:

VersionNT >= 501 

and when i run it on Windows NT this condiotion newer comes as true.

Than i tried to check what version number i have for WinXP with following
code:

VersionNT = n 

this displays message with 501 in value field this means my Windows version
is 501. Can some one please help me out with this.

Thanks in Advance.
Vivek

-- 
View this message in context: 
http://n2.nabble.com/Install-only-on-XP-SP2-or-better-tp698937p1083699.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

[John Nannenga]

I believe it is the first time a given 'Product Code' is installed (not 100% 
certain).


I didn't believe that the FindRelatedProducts and RemoveExistingProducts 
actions had much of anything to do with a small update or minor upgrade 
delivered via an MSI because these scenarios are still reinstalls.  But before 
I said so, I thought I should confirm that so I built and tested my first ever 
minor upgrade (MSI based).  When run with logging this is confirmed...

msiexec /i %my.msi% /l*v log.log REINSTALL=ALL REINSTALLMODE=vomus

MSI (c) (F8:04) [16:03:42:699]: Doing action: FindRelatedProducts
MSI (c) (F8:04) [16:03:42:699]: Note: 1: 2205 2:  3: ActionText
Action 16:03:42: FindRelatedProducts. Searching for related applications
Action start 16:03:42: FindRelatedProducts.
==> MSI (c) (F8:04) [16:03:42:699]: Skipping FindRelatedProducts action: not 
run in maintenance mode
Action ended 16:03:42: FindRelatedProducts. Return value 0.
.
.
.
MSI (s) (BC:78) [16:03:43:120]: Doing action: RemoveExistingProducts
MSI (s) (BC:78) [16:03:43:120]: Note: 1: 2205 2:  3: ActionText
Action 16:03:43: RemoveExistingProducts. Removing applications
Action start 16:03:43: RemoveExistingProducts.
==> MSI (s) (BC:78) [16:03:43:120]: Skipping RemoveExistingProducts action: 
current configuration is maintenance mode or an uninstall
Action ended 16:03:43: RemoveExistingProducts. Return value 0.



I would expect the WiX CA's to behave correctly in patch, upgrade, uninstall, 
etc... scenarios (so if you're referring to WiX CA's for SQL items, websites, 
etc...) and your RemoveExistingProducts action is schedule appropriately (in an 
upgrade scenario), I believe that is a correct assumption to make (not saying 
there couldn't be bugs lurking somewhere, though [but I like to remain positive 
:) ]).



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

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 

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

[Neil Enns]

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

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

Neil

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

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

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

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

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

Robert,

This happens when you have multiple .wxl files in your project with different 
cultures in them. Setting the Cultures field in properties will control which 
languages get built, but the output will still go into the sub-folder (this 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  | 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 
 | 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  | 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=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a

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  file to your sources 
you can expect build output to start showing up in 
bin\$(Configuration)\.

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

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

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

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

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

Robert,

This happens when you have multiple .wxl files in your project with different 
cultures in them. Setting the Cultures field in properties will control which 
languages get built, but the output will still go into the sub-folder (this 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  | 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 
 | 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  | 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=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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?

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


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--

Re: [WiX-users] 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.
















NEWERVERSIONFOUND



PATCH AND Installed
PATCH AND Installed


NEWERVERSIONFOUND
OLDERVERSIONFOUND
OLDERVERSIONFOUND





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

  
  





. other custom actions ...
PATCHFOUND
  NEWERFOUND
Installed
Installed
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" 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)...





...

PATCH and Installed
PATCH and Installed
...
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 **

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 p

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

[Neil Enns]

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


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] 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?











NEWERVERSIONFOUND



NEWERVERSIONFOUND
OLDERVERSIONFOUND
OLDERVERSIONFOUND


Also evertying I read about the  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.p

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

[John Nannenga]

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?











NEWERVERSIONFOUND



NEWERVERSIONFOUND
OLDERVERSIONFOUND
OLDERVERSIONFOUND


Also evertying I read about the  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=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Permissions. How do I do it????

[CHarker]

CHarker wrote:
> 
> Also I did notice that if I put "Administrators" in the  it
> installs the service, fails the config, and then fails to rollback because
> I no longer have permission to uninstall system services!!
> 
> the only way out for that was to remove the services registry entry,
> reboot the machine and uninstall from "add remove programs"
> 
> Cliff
> 
> 

Could someone confirm that  works at all?

Cliff

-- 
View this message in context: 
http://n2.nabble.com/%3CServiceConfig%3E-Permissions.-How-do-I-do-it-tp1082369p1083554.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Wix Service - grant logon rights

[Yu, Brian]

How do u grant logon rights to services created by custom actions?




  Not
Installed OR REINSTALL
  
   

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] does 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?











NEWERVERSIONFOUND



NEWERVERSIONFOUND
OLDERVERSIONFOUND
OLDERVERSIONFOUND


Also evertying I read about the  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=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] WixGaming extension: adding tasks?

[Frank Richter]

Hi,
I'm pretty new to all that MSI stuff, so correct me if I'm wrong.

It's about tasks from the gaming extension. The manual says Play tasks
result in Shortcuts. These shortcuts are part of the component the game
executable is in - necessarly, since a  must go below a .
Now, from what I gathered, you can't change the shortcuts of a component
without giving it a new GUID and, most inconveniently, change the target
names of everything in it. In reverse, doesn't that mean once I picked a
set of Play (and Support) tasks for a game executable and ship some MSI,
I'm pretty much stuck with that set of tasks forever (or go through some
inconveniences to ensure component rules are not broken)?

Thanks,
-f.r.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX Burn bootstrapper

[Paul Lewis]

Hi Rob,

Thanks for the fast reply, I think WiX is great and look forward to the 
continuing developments.

I hope the first few days with the LiveMesh team are going well.

All the best,
Paul

Rob Mensching wrote:
> Burn is a thing that I dreamed would make it in WiX v3.0 but it didn't 
> (http://robmensching.com/blog/archive/2008/06/06/Proposed-adjustments-the-WiX-v2-and-WiX-v3-roadmap.aspx).
>  Since then Bob and I have kicked things about a little and now we are 
> thinking about making it the focus of a WiX v3.5.
>
> I'm working on a comprehensive write-up about thoughts for WiX v3.0 and v3.5 
> and v4.0 (i.e. roadmap for next couple years).  I've just been a little 
> buried lately 
> (http://robmensching.com/blog/archive/2008/08/15/When-it-changes-it-pours-again.aspx).
>   
>
> My current hope is that Burn is well under development by first month of next 
> year.  That is largely dependent on how quickly we kill off all of the WiX v3 
> bugs.  I don't want to lose focus on WiX v3.
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Lewis
> Sent: Thursday, September 11, 2008 08:34
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] WiX Burn bootstrapper
>
> Hi Folks,
>
> I'm quite new to WiX and I'm looking at using it to build an install
> project that requires chaining a couple of simple MSI's together.
>
> I've read a little about the Burn Bootstrapper, and that it has been
> dropped from the WiX v3 roadmap.
>
> http://sourceforge.net/mailarchive/message.php?msg_id=358106.95478.qm%40web36606.mail.mud.yahoo.com
> http://www.joyofsetup.com/2008/06/21/wix-burn-volume-1-layers/
>
> I was wondering what the current state of Burn is?
>
> I do not see it in the source repository (unless I missed it), would it
> be possible to get a copy of the work in progress?
>
> I was thinking it may be preferable as a starting point in any state
> than starting with the existing 'setupbld' and 'setupexe' projects in WiX.
>
> Any feedback is greatly appreciated.
>
> Best Regards,
> Paul
>
> --
> -
> Paul Lewis
> Software Engineer
> Wimba - People Teach People
>
> 10 East 40th Street, Floor 11
> New York, NY 10016
> [EMAIL PROTECTED]
> http://www.wimba.com
> -
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>   

-- 
-
Paul Lewis
Software Engineer
Wimba - People Teach People
 
10 East 40th Street, Floor 11
New York, NY 10016
[EMAIL PROTECTED]
http://www.wimba.com
-


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] aspnet_regiis domain user

[Chad Miles]

It appears like it does.  Try it out.


On Thu, Sep 11, 2008 at 1:32 PM, derekj <[EMAIL PROTECTED]> wrote:

>
> Hi,
>
> Does adding the user to the IIS_WPG also do the > aspnet_regiis -ga
> [domain]\user?
>
> regards
>
> Derek
>
> cemiles wrote:
> >
> > Yes.  If all you're having trouble with is figuring out how to add to the
> > IIS grp...
> >
> >   
> >   
> >
> > Then just groupref that Grp_IISWPG inside your User element.
> >
> > Are you trying to do more than that?
> >
> > On Thu, Sep 11, 2008 at 5:37 AM, derekj <[EMAIL PROTECTED]>
> wrote:
> >
> >>
> >> Hi,
> >>
> >> I am using WIX 2.0
> >>
> >> I have created a cmd line MSI to install an asp.net 2.0.
> >>
> >> I created an apppool with a user
> >>
> >>   >> Password='2Bdeleted'
> >> Domain='MYDOMAIN' >
> >>  
> >>
> >>
> >>
> >>   >> Guid="79351901-d5de-4491-ac35-2f43ceb52439"
> >> KeyPath="yes">
> >>
> >> >> Identity='other' User='TestTimeAppPoolUser'  >
> >>
> >>  
> >>
> >> I need to add this user to the IIS_WPG group, log on as service and
> >> ASP.Net
> >> 2.0
> >> eg
> >>
> >> aspnet_regiis -ga [domain]\user'
> >>
> >> Has anyone done this successfully
> >>
> >> regards
> >>
> >> Derekj
> >> --
> >> View this message in context:
> >> http://n2.nabble.com/aspnet_regiis-domain-user-tp1082311p1082311.html
> >> Sent from the wix-users mailing list archive at Nabble.com.
> >>
> >>
> >>
> -
> >> This SF.Net email is sponsored by the Moblin Your Move Developer's
> >> challenge
> >> Build the coolest Linux based applications with Moblin SDK & win great
> >> prizes
> >> Grand prize is a trip for two to an Open Source event anywhere in the
> >> world
> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> ___
> >> WiX-users mailing list
> >> WiX-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>
> > -
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> > challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> > prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> > world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/aspnet_regiis-domain-user-tp1082311p1083240.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Condition install and uninstall

[John Nannenga]

>wondering if you know where I can find information on amending the condition
>so it only fires on install and not on install.


* I'm assuming you mean only potentially fire on install and never fire when 
installed, if so, try this condition...

>DATABASEIPADDRESS OR Installedmailto:[EMAIL PROTECTED] On Behalf Of derekj
Sent: Thursday, September 11, 2008 2:02 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Condition install and uninstall


Hi,

thanks for your help,

wondering if you know where I can find information on amending the condition
so it only fires on install and not on install.

regards

Derekj

John Nannenga wrote:
>
> Launch conditions fire when the condition is false:
>http://msdn.microsoft.com/en-us/library/aa369752.aspx
>
> The property you likely mean to use is "Installed", not "INSTALLED".
>http://msdn.microsoft.com/en-us/library/aa369297(VS.85).aspx
>
>
> 
> From: [EMAIL PROTECTED]
> [EMAIL PROTECTED] On Behalf Of derekj
> [EMAIL PROTECTED]
> Sent: Wednesday, September 10, 2008 2:48 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users]  Condition install and uninstall
>
> Hi,
>
> I am doing a cmd line msi that has a number of input parameters.
>
> I have
>  DATABASEIPADDRESS AND NOT INSTALLED
>
> this condition is fires on both install and uninstall.
>
> can someone help
>
> regards
>
> --
> View this message in context:
> http://n2.nabble.com/Condition-install-and-uninstall-tp1079400p1079400.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>

--
View this message in context: 
http://n2.nabble.com/Condition-install-and-uninstall-tp1079400p1082087.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] multiple languages in single installer

[DE�K JAHN, G�bor]

On Wed, 10 Sep 2008 12:47:57 -0700, Jeb Remus wrote:

Jeb,

> I understand how WIX can generate N installer for N different
> language files, which is really great.  I was wondering however if
> there is any functionality to combine N language files into a
> single installer, that would detect user or system locale at run time.

Yes, see 
http://www.installsite.org/pages/en/msi/articles/embeddedlang/index.htm . It 
isn't documented but MS itself uses it (actually, because it is very 
straightforward and I can't see any reason for abandoning this feature in any 
coming version of Windows Installer, I don't really understand why it isn't 
officially approved).

Bye,
   Gábor

---
DEÁK JAHN, Gábor -- Budapest, Hungary
E-mail: [EMAIL PROTECTED]

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Condition install and uninstall

[derekj]

Thanks very much

John Nannenga wrote:
> 
>>wondering if you know where I can find information on amending the
condition
>>so it only fires on install and not on install.
> 
> 
> * I'm assuming you mean only potentially fire on install and never fire
> when installed, if so, try this condition...
> 
>>DATABASEIPADDRESS OR Installed 
> Recall:  Launch conditions fire when the condition is false.  So here's
> how this evaluates:
> 
> 
> * If the product is already installed, this launch condition will evaluate
> to TRUE (because Installed would be defined) and allow user to progress. 
> (FALSE || TRUE == TRUE), (TRUE || TRUE == TRUE)
> 
> * If the product is not installed and DATABASEIPADDRESS is not set, this
> launch condition will evaluate to FALSE and the user will get your error
> message and the install will end.  (FALSE || FALSE == FALSE)
> 
> * If the product is not installed and DATABASEIPADDRESS is set, this
> launch condition will evaluate to TRUE and allow user to progress. (TRUE
> || FALSE = TRUE).
> 
> 
> 
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of derekj
> Sent: Thursday, September 11, 2008 2:02 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Condition install and uninstall
> 
> 
> Hi,
> 
> thanks for your help,
> 
> wondering if you know where I can find information on amending the
> condition
> so it only fires on install and not on install.
> 
> regards
> 
> Derekj
> 
> John Nannenga wrote:
>>
>> Launch conditions fire when the condition is false:
>>http://msdn.microsoft.com/en-us/library/aa369752.aspx
>>
>> The property you likely mean to use is "Installed", not "INSTALLED".
>>http://msdn.microsoft.com/en-us/library/aa369297(VS.85).aspx
>>
>>
>> 
>> From: [EMAIL PROTECTED]
>> [EMAIL PROTECTED] On Behalf Of derekj
>> [EMAIL PROTECTED]
>> Sent: Wednesday, September 10, 2008 2:48 AM
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users]  Condition install and uninstall
>>
>> Hi,
>>
>> I am doing a cmd line msi that has a number of input parameters.
>>
>> I have
>>  DATABASEIPADDRESS AND NOT INSTALLED
>>
>> this condition is fires on both install and uninstall.
>>
>> can someone help
>>
>> regards
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/Condition-install-and-uninstall-tp1079400p1079400.html
>> Sent from the wix-users mailing list archive at Nabble.com.
>>
>>
>> -
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>> -
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
> 
> --
> View this message in context:
> http://n2.nabble.com/Condition-install-and-uninstall-tp1079400p1082087.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 

-- 
View this message in context: 
http://n2.nabble.com/Condition-install-and-uninstall-tp1079400p1083260.htm

Re: [WiX-users] How to invoke InstallUtil.exe

[Wilson, Phil]

If you're installing a service you don't need InstallUtil.exe. Use the 
ServiceInstall and ServiceControl features in WiX.

Phil Wilson

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sandeep Gautam 
(HCL Technologies Ltd)
Sent: Tuesday, September 09, 2008 11:59 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to invoke InstallUtil.exe

Hi ,

I want to invoke installUtil.exe. How can I do the same.

Thanks in advance.

Regards
Sandeep

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] aspnet_regiis domain user

[derekj]

Hi,

Does adding the user to the IIS_WPG also do the > aspnet_regiis -ga
[domain]\user?

regards

Derek

cemiles wrote:
> 
> Yes.  If all you're having trouble with is figuring out how to add to the
> IIS grp...
> 
>   
>   
> 
> Then just groupref that Grp_IISWPG inside your User element.
> 
> Are you trying to do more than that?
> 
> On Thu, Sep 11, 2008 at 5:37 AM, derekj <[EMAIL PROTECTED]> wrote:
> 
>>
>> Hi,
>>
>> I am using WIX 2.0
>>
>> I have created a cmd line MSI to install an asp.net 2.0.
>>
>> I created an apppool with a user
>>
>>  > Password='2Bdeleted'
>> Domain='MYDOMAIN' >
>>  
>>
>>
>>
>>  > Guid="79351901-d5de-4491-ac35-2f43ceb52439"
>> KeyPath="yes">
>>
>>> Identity='other' User='TestTimeAppPoolUser'  >
>>
>>  
>>
>> I need to add this user to the IIS_WPG group, log on as service and
>> ASP.Net
>> 2.0
>> eg
>>
>> aspnet_regiis -ga [domain]\user'
>>
>> Has anyone done this successfully
>>
>> regards
>>
>> Derekj
>> --
>> View this message in context:
>> http://n2.nabble.com/aspnet_regiis-domain-user-tp1082311p1082311.html
>> Sent from the wix-users mailing list archive at Nabble.com.
>>
>>
>> -
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 

-- 
View this message in context: 
http://n2.nabble.com/aspnet_regiis-domain-user-tp1082311p1083240.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] multiple languages in single installer

[Clemmer, Everette]

Jeb Remus wrote:
> I understand how WIX can generate N installer for N different language
files, which is really great.  I was wondering however if there is any
functionality to combine N language files into a single installer, that
would detect user or system locale at run time.  Any help or pointers
would be awesome, thanks much.
> 

It's possible to use a third party tool such as PaquetBuilder
(http://www.gdgsoft.com/pb/) that will embed all of the .msi and local
files into a single .exe that can detect the OS locale. Be warned,
however, that the behavior can be unpredictable when using these types
of tools, especially on Vista. We've been using this approach for the
past year and have spent a great deal of time debugging some very
strange installation failures and successes that were actually failures
in disguise.

Everette


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix Add Dialog to prompt for username and pwd

[Richard]

In article <[EMAIL PROTECTED]>,
Bob Arnson <[EMAIL PROTECTED]>  writes:

> Richard wrote:
> > Where is this extension documented?  I get a file not found when
> > attemping to access this URL.
> >   
> 
> In WiX.chm. The schema namespace is just for uniqueness.

OK, looking at the  element, it doesn't let you identify a
group by its well-known SID so attempting to reference the
"Administrators" group on non-English distributions of Windows will
fail because the name of the groups are localized, but the SIDs are
always the same.

While this follows the model of permissions that Windows Installer
has, its still the wrong model.  To be honest, the small amount of
permissions stuff that is in Windows Installer itself just feels not
very well thought out to me.  Its one of the weaker areas of Windows
Installer.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Condition install and uninstall

[Alexander Shevchuk]

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



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of derekj
Sent: Thursday, September 11, 2008 12:02 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Condition install and uninstall


Hi,

thanks for your help,

wondering if you know where I can find information on amending the condition
so it only fires on install and not on install.

regards

Derekj

John Nannenga wrote:
>
> Launch conditions fire when the condition is false:
>http://msdn.microsoft.com/en-us/library/aa369752.aspx
>
> The property you likely mean to use is "Installed", not "INSTALLED".
>http://msdn.microsoft.com/en-us/library/aa369297(VS.85).aspx
>
>
> 
> From: [EMAIL PROTECTED]
> [EMAIL PROTECTED] On Behalf Of derekj
> [EMAIL PROTECTED]
> Sent: Wednesday, September 10, 2008 2:48 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users]  Condition install and uninstall
>
> Hi,
>
> I am doing a cmd line msi that has a number of input parameters.
>
> I have
>  DATABASEIPADDRESS AND NOT INSTALLED
>
> this condition is fires on both install and uninstall.
>
> can someone help
>
> regards
>
> --
> View this message in context:
> http://n2.nabble.com/Condition-install-and-uninstall-tp1079400p1079400.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>

--
View this message in context: 
http://n2.nabble.com/Condition-install-and-uninstall-tp1079400p1082087.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX Burn bootstrapper

[Rob Mensching]

Burn is a thing that I dreamed would make it in WiX v3.0 but it didn't 
(http://robmensching.com/blog/archive/2008/06/06/Proposed-adjustments-the-WiX-v2-and-WiX-v3-roadmap.aspx).
 Since then Bob and I have kicked things about a little and now we are thinking 
about making it the focus of a WiX v3.5.

I'm working on a comprehensive write-up about thoughts for WiX v3.0 and v3.5 
and v4.0 (i.e. roadmap for next couple years).  I've just been a little buried 
lately 
(http://robmensching.com/blog/archive/2008/08/15/When-it-changes-it-pours-again.aspx).
  

My current hope is that Burn is well under development by first month of next 
year.  That is largely dependent on how quickly we kill off all of the WiX v3 
bugs.  I don't want to lose focus on WiX v3.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Lewis
Sent: Thursday, September 11, 2008 08:34
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX Burn bootstrapper

Hi Folks,

I'm quite new to WiX and I'm looking at using it to build an install
project that requires chaining a couple of simple MSI's together.

I've read a little about the Burn Bootstrapper, and that it has been
dropped from the WiX v3 roadmap.

http://sourceforge.net/mailarchive/message.php?msg_id=358106.95478.qm%40web36606.mail.mud.yahoo.com
http://www.joyofsetup.com/2008/06/21/wix-burn-volume-1-layers/

I was wondering what the current state of Burn is?

I do not see it in the source repository (unless I missed it), would it
be possible to get a copy of the work in progress?

I was thinking it may be preferable as a starting point in any state
than starting with the existing 'setupbld' and 'setupexe' projects in WiX.

Any feedback is greatly appreciated.

Best Regards,
Paul

--
-
Paul Lewis
Software Engineer
Wimba - People Teach People

10 East 40th Street, Floor 11
New York, NY 10016
[EMAIL PROTECTED]
http://www.wimba.com
-


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Creating using Heat.

[BOB1981]

Hi All,

I know there must be a way to do it. I am using following Command.. to
create Wxs file as per the directory structure and files.

heat dir -ag -ke -nologo -sreg -sfrag c:\temp\bin -out c:\test1.wxs
Below is the Birectory Structure.

C:\Temp\Bin   (4 files at this location)
C:\Temp\Bin\obj  (2 files here)
C:\Temp\Bin\exe  (2 files here)

when i open the Wxs file created by Heat, it created the structure and files
everything fine. But All of the Components are in one Component group.
 
I want them to be grouped according to the Directories they are in.
like
for component under Bin
for component under obj
for component under exe

IS there a way, My Problem is much more bigger then this , i just made this
up to explain it in clear language so its not confusing. becasue this is the
root cause of my problem. I have already tried Running Heat on all the
subfolders diffrently which creates multile wxs files for me to take care of
the problem But that way dublicate files in these directories create
trouble. So that is not an option , I have to run Heat on C:\temp\Bin Not
indivisual folders inside.

Any ideas... pls... actually this process is part of Build that is why it
need to be  automated otherwise i could have manually updated.

thanks...
-- 
View this message in context: 
http://n2.nabble.com/Creating--%3CComponentGroup-Id%3D%22ComponentGroup2%22%3E-using-Heat.-tp1083059p1083059.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Reading the registry entries - Facing an interesting problem

[Mukesh Agrawal]

Hi,

Refer to the attached image.

In a registry entry, we can have many Registry Values for a key.
For example, I have 3 values for the key Softwares\Microsoft\Microsoft SQL 
Server\Instance Names\SQL.
I don't know the "Names" of these Registry Values and I want to check every 
Values of this key. Also, I don't know the number of such values for a 
particular key beforehand. Is there any way to get these Values in wix?

In my investigation what I have found is, in this case, I can get the Names for 
all possible values of this key from another registry entry.
But the problem is, all these names are stored in "space separated string"  or 
REG_MULTI_SZ  format. Is there any way to parse this string and get names from 
this (in wix). Also, how do I know the count of such names because I will need 
those many properties for making a registry search.

Thanks
Mukesh Agrawal.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] WiX Burn bootstrapper

[Paul Lewis]

Hi Folks,

I'm quite new to WiX and I'm looking at using it to build an install 
project that requires chaining a couple of simple MSI's together.

I've read a little about the Burn Bootstrapper, and that it has been 
dropped from the WiX v3 roadmap.

http://sourceforge.net/mailarchive/message.php?msg_id=358106.95478.qm%40web36606.mail.mud.yahoo.com
http://www.joyofsetup.com/2008/06/21/wix-burn-volume-1-layers/

I was wondering what the current state of Burn is?

I do not see it in the source repository (unless I missed it), would it 
be possible to get a copy of the work in progress?

I was thinking it may be preferable as a starting point in any state 
than starting with the existing 'setupbld' and 'setupexe' projects in WiX.

Any feedback is greatly appreciated.

Best Regards,
Paul

-- 
-
Paul Lewis
Software Engineer
Wimba - People Teach People
 
10 East 40th Street, Floor 11
New York, NY 10016
[EMAIL PROTECTED]
http://www.wimba.com
-


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] aspnet_regiis domain user

[Chad Miles]

Yes.  If all you're having trouble with is figuring out how to add to the
IIS grp...

  
  

Then just groupref that Grp_IISWPG inside your User element.

Are you trying to do more than that?

On Thu, Sep 11, 2008 at 5:37 AM, derekj <[EMAIL PROTECTED]> wrote:

>
> Hi,
>
> I am using WIX 2.0
>
> I have created a cmd line MSI to install an asp.net 2.0.
>
> I created an apppool with a user
>
>   Domain='MYDOMAIN' >
>  
>
>
>
>   Guid="79351901-d5de-4491-ac35-2f43ceb52439"
> KeyPath="yes">
>
> Identity='other' User='TestTimeAppPoolUser'  >
>
>  
>
> I need to add this user to the IIS_WPG group, log on as service and ASP.Net
> 2.0
> eg
>
> aspnet_regiis -ga [domain]\user'
>
> Has anyone done this successfully
>
> regards
>
> Derekj
> --
> View this message in context:
> http://n2.nabble.com/aspnet_regiis-domain-user-tp1082311p1082311.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MSIEXEC installlevel feature

[dschmitz]

Great!

That was exactly what I needed!

Thanks a lot again
Daniel


Pally Sandher wrote:
> 
> You can use Conditions on your Features to set the Level.
> 
> e.g.
> 
> 
>   
> 
>   
>   
> 
> 
> 
>   
> 
> 
> If you ran your MSI as "msiexec /i myproduct.msi INSTALLELEVEL=2000
> ONLYB=true" it would only install Feature B as Feature A would have it's
> Level set to  since the public Property ONLYB has a value assigned. 
> 
> Thus to install it for your cases:
> Only A = "msiexec /i myproduct.msi INSTALLELEVEL=1000"
> A+B= "msiexec /i myproduct.msi INSTALLELEVEL=2000"
> Only B = "msiexec /i myproduct.msi INSTALLELEVEL=2000 ONLYB=true"
> 
> 
> 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 **
> 
> 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 dschmitz
> Sent: 11 September 2008 14:29
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] MSIEXEC installlevel feature
> 
> 
> Hello,
> 
> I'm just wondering if it is possible with MSI and with Wix to have 2
> features and to choose via msiexec command line which of the two
> features should be installed. If I give a feature a "Level" attribute in
> Wix msi installs everything with a feature LEVEL <=  the specified
> INSTALLLEVEL. But I want to choose exactly one feature, so just "equal"
> instead of "<=".
> 
> So if I have:
> A: Configuration 1 LEVEL=1000
> B: Configuration 2 LEVEL=2000
> 
> I can either install A or A+B but not just B.
> 
> Does anybody know, if there is another possibility?
> 
> Thanks
> Daniel
> 
> --
> View this message in context:
> http://n2.nabble.com/MSIEXEC-installlevel-feature-tp1082699p1082699.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 

-- 
View this message in context: 
http://n2.nabble.com/MSIEXEC-installlevel-feature-tp1082699p1082817.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MSIEXEC installlevel feature

[John Nannenga]

You may also be able to make use of the following properties:
 http://msdn.microsoft.com/en-us/library/aa367536(VS.85).aspx




From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Pally Sandher [EMAIL 
PROTECTED]
Sent: Thursday, September 11, 2008 8:46 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] MSIEXEC installlevel feature

You can use Conditions on your Features to set the Level.

e.g.


  

  
  



  


If you ran your MSI as "msiexec /i myproduct.msi INSTALLELEVEL=2000
ONLYB=true" it would only install Feature B as Feature A would have it's
Level set to  since the public Property ONLYB has a value assigned.

Thus to install it for your cases:
Only A = "msiexec /i myproduct.msi INSTALLELEVEL=1000"
A+B= "msiexec /i myproduct.msi INSTALLELEVEL=2000"
Only B = "msiexec /i myproduct.msi INSTALLELEVEL=2000 ONLYB=true"


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

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 dschmitz
Sent: 11 September 2008 14:29
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] MSIEXEC installlevel feature


Hello,

I'm just wondering if it is possible with MSI and with Wix to have 2
features and to choose via msiexec command line which of the two
features should be installed. If I give a feature a "Level" attribute in
Wix msi installs everything with a feature LEVEL <=  the specified
INSTALLLEVEL. But I want to choose exactly one feature, so just "equal"
instead of "<=".

So if I have:
A: Configuration 1 LEVEL=1000
B: Configuration 2 LEVEL=2000

I can either install A or A+B but not just B.

Does anybody know, if there is another possibility?

Thanks
Daniel

--
View this message in context:
http://n2.nabble.com/MSIEXEC-installlevel-feature-tp1082699p1082699.html
Sent from the wix-users mailing list archive at Nabble.com.



-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Check whether VS.NET is installed.

[Neil Enns]

You don't even have to that much. WiX includes a library to do this for you, 
which you can just include and then reference the property with a .

See the How To: Check for .NET Framework Versions in the WiX CHM file for the 
general approach, but substitute in WixVSExtension instead of WiXNetExtension. 
The "WixVSExtension" topic lists the available properties.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Sergey Abakumoff [EMAIL 
PROTECTED]
Sent: Wednesday, September 10, 2008 11:27 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Check whether VS.NET is installed.


Found the answer myself:
* Define the following properties:

  



  



  


Then use these properties to block the installation of the certain
components..
--
View this message in context: 
http://n2.nabble.com/Check-whether-VS.NET-is-installed.-tp1082028p1082052.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Help using Heat of WiX v3

[BOB1981]

Hi,

I am also is the Same exact Situation in which you are, I am using Heat to
generate the Fragment file to be able to include in my Build which has to be
dynamic , so i foudnt eh best way to do it by using heat, but , i manually
had to update the file and add directoryref tag and Also change the
Componentgroup name as per the directoryname. Here is wht i am doing.

I run heat on 4 different directory locations, because of this I run into
the following situation.

1) Mannually adding Directoryref tag between ...

2) because i am running heat on 4 diffrent directory, the name of the
Component Group is always coming same like , so name of the component group also i have to
mannally updated so  it can be used in the featuretree. 

My msi package needs to have 4 features based on the directories, that is
why i am using heat 4 diffrent times on these folders to generate .wxs file
, But because of this limitation m not able to make is a part pf build. M
sure there has to be some way people are doing it. pls anybody share some
ideas?

Is there a way we could use heat to make components groups as per the
directory it harvests.

and Dfox let me point you to another future problem which i found after
getting through this , If there is a file having same name in two diffrent
Fragment files that is going to break the build as well in future.

Let me know peple 
thanks.



dfox wrote:
> 
> Hi,
> 
> I am new to WiX and Heat, I need to make a dynamic linking of files (I
> think the best solution as mallow, but i guess this can also be done using
> Heat). My problem is how to use the output of Heat without modifying the
> file.
> 
> I need to use heat in our build system, i just need to harvest directories
> for the project.
> The output of the Heat looks like this:
> 
> http://schemas.microsoft.com/wix/2006/wi";>
> 
> 
>   
> ...
> ...
> 
> 
> 
> 
> 
>   ...
> 
> 
> 
> 
> Is it possible not to modify this file? We need to update this file every
> time we build, meaning we need to run Heat every time we build, so all
> changes made will be lost.
> 
> My question is how to use this file 'coz i'm getting:
> error CNDL0205: The Directory with Id 'dir1' is not a valid root
> directory. Blah blah blah
> 
> I fixed this by change 
> 
> INSTALLDIR is inside the Directory with Id = TargetDir
> What we want is to use this file without having to change/modify 'coz when
> we run Heat again, the changes will be lost. BTW, we use msbuild for this.
> 
> Any help or idea is highly appreaciated. Thanks in advance! More Power!
> 
> Best Regards,
> dfox
> 

-- 
View this message in context: 
http://n2.nabble.com/Help-using-Heat-of-WiX-v3-tp711926p1082772.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Help using Heat of WiX v3

[BOB1981]

Hi,

I am also is the Same exact Situation in which you are, I am using Heat to
generate the Fragment file to be able to include in my Build which has to be
dynamic , so i foudnt eh best way to do it by using heat, but , i manually
had to update the file and add directoryref tag and Also change the
Componentgroup name as per the directoryname. Here is wht i am doing.

I run heat on 4 different directory locations, because of this I run into
the following situation.

1) Mannually adding Directoryref tag between ...

2) because i am running heat on 4 diffrent directory, the name of the
Component Group is always coming same like , so name of the component group also i have to
mannally updated so  it can be used in the featuretree. 

My msi package needs to have 4 features based on the directories, that is
why i am using heat 4 diffrent times on these folders to generate .wxs file
, But because of this limitation m not able to make is a part pf build. M
sure there has to be some way people are doing it. pls anybody share some
ideas?

Is there a way we could use heat to make components groups as per the
directory it harvests.

and Dfox let me point you to another future problem which i found after
getting through this , If there is a file having same name in two diffrent
Fragment files that is going to break the build as well in future.

Let me know peple 
thanks.



dfox wrote:
> 
> Hi,
> 
> I am new to WiX and Heat, I need to make a dynamic linking of files (I
> think the best solution as mallow, but i guess this can also be done using
> Heat). My problem is how to use the output of Heat without modifying the
> file.
> 
> I need to use heat in our build system, i just need to harvest directories
> for the project.
> The output of the Heat looks like this:
> 
> http://schemas.microsoft.com/wix/2006/wi";>
> 
> 
>   
> ...
> ...
> 
> 
> 
> 
> 
>   ...
> 
> 
> 
> 
> Is it possible not to modify this file? We need to update this file every
> time we build, meaning we need to run Heat every time we build, so all
> changes made will be lost.
> 
> My question is how to use this file 'coz i'm getting:
> error CNDL0205: The Directory with Id 'dir1' is not a valid root
> directory. Blah blah blah
> 
> I fixed this by change 
> 
> INSTALLDIR is inside the Directory with Id = TargetDir
> What we want is to use this file without having to change/modify 'coz when
> we run Heat again, the changes will be lost. BTW, we use msbuild for this.
> 
> Any help or idea is highly appreaciated. Thanks in advance! More Power!
> 
> Best Regards,
> dfox
> 

-- 
View this message in context: 
http://n2.nabble.com/Help-using-Heat-of-WiX-v3-tp711926p1082769.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MSIEXEC installlevel feature

[Pally Sandher]

You can use Conditions on your Features to set the Level.

e.g.


  

  
  



  


If you ran your MSI as "msiexec /i myproduct.msi INSTALLELEVEL=2000
ONLYB=true" it would only install Feature B as Feature A would have it's
Level set to  since the public Property ONLYB has a value assigned. 

Thus to install it for your cases:
Only A = "msiexec /i myproduct.msi INSTALLELEVEL=1000"
A+B= "msiexec /i myproduct.msi INSTALLELEVEL=2000"
Only B = "msiexec /i myproduct.msi INSTALLELEVEL=2000 ONLYB=true"


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

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 dschmitz
Sent: 11 September 2008 14:29
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] MSIEXEC installlevel feature


Hello,

I'm just wondering if it is possible with MSI and with Wix to have 2
features and to choose via msiexec command line which of the two
features should be installed. If I give a feature a "Level" attribute in
Wix msi installs everything with a feature LEVEL <=  the specified
INSTALLLEVEL. But I want to choose exactly one feature, so just "equal"
instead of "<=".

So if I have:
A: Configuration 1 LEVEL=1000
B: Configuration 2 LEVEL=2000

I can either install A or A+B but not just B.

Does anybody know, if there is another possibility?

Thanks
Daniel

--
View this message in context:
http://n2.nabble.com/MSIEXEC-installlevel-feature-tp1082699p1082699.html
Sent from the wix-users mailing list archive at Nabble.com.



-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] integrating two msi s problems

[Pally Sandher]

1. As Bob says on the post you linked, you need to write a chainer for
this functionality as it is not supported by the Windows Installer.

2. 
   ...
   

3. It depends on your upgrade. I've released 1.0, 1.1 & 1.2 MSI's of one
of our releases all of which upgrade fine using correctly authored
Upgrade tags. The MSIs can be double clicked on & they works fine.
If however you wish to release a 1.0 MSI & then release a 1.0.1 or
1.0.0.1 MSI & have it behave the same I suspect the tutorial is correct
that it won't upgrade simply by double clicking on it (this is certainly
what I have experienced with the release I'm working on currently as it
is a 1.0.0.1). I handle these releases by using patches (MSP).

4. WiX != Windows Installer. If the Windows Installer doesn't support
something it's not a failing of the WiX toolset.


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

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 Raj P
Sent: 11 September 2008 12:46
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] integrating two msi s problems

Hi all,

   The problem that I am currently facing was,

I have two msi s, say AppA and AppB. AppB requires AppA to be installed
on the target machine ( treat AppB as some plugins, with out having base
application installed on the machine, having plugins is meaning less).
To verify this dependency, a registry entry will be created at the time
of installation of AppA. The problems that I am facing currently are,

1. At the time of uninstallation of AppA of AppB should also get
uinstalled.
   For this some of the suggestions are
   a. Merging AppA and AppB and creation of new single msi will do the
job.
But the problem is here if I want to upgrade/update either of the
applications ( not both)  is not possible ( why because they are in the
form of msm). Even if I create a new msi of either of the applications
and do the modifications, because it is another msi it won't get
uinistall at the time of uinstallation of single merged msi. ( meaning
of upgradation of plugins lost here) refer this post :
http://sourceforge.net/mailarchive/message.php?msg_id=48BF4FA5.9020607%4
0joyofsetup.com

 b. Creation of an exe for launching the individual msi s is a good
option, but I need an msi ( it makes everything simple right).

2. Is there any way to uninstall a previous version before installing
the application. if so can any one please give me the wix statement.

3. How can we execute an upgraded msi by double clicking ( according to
the tutorial lesson 4, its not possbile right).

   I don't understand why we are unable to support plugins
concept by using wix.  Please help me,  Waiting for your valuable
suggestions.
Thanks alot for your support.

 -Raj

-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge Build the coolest Linux based applications with Moblin SDK &
win great prizes Grand prize is a trip for two to an Open Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] MSIEXEC installlevel feature

[dschmitz]

Hello,

I'm just wondering if it is possible with MSI and with Wix to have 2
features and to choose via msiexec command line which of the two features
should be installed. If I give a feature a "Level" attribute in Wix msi
installs everything with a feature LEVEL <=  the specified INSTALLLEVEL. But
I want to choose exactly one feature, so just "equal" instead of "<=".

So if I have:
A: Configuration 1 LEVEL=1000
B: Configuration 2 LEVEL=2000

I can either install A or A+B but not just B.

Does anybody know, if there is another possibility?

Thanks
Daniel

-- 
View this message in context: 
http://n2.nabble.com/MSIEXEC-installlevel-feature-tp1082699p1082699.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Gaming ext: adding tasks

[Frank Richter]

Hi,
I'm pretty new to all that MSI stuff, so correct me if I'm wrong.

It's about tasks from the gaming extension. The manual says Play tasks
result in Shortcuts. These shortcuts are part of the component the game
executable is in - necessarly, since a  must go below a .
Now, from what I gathered, you can't change the shortcuts of a component
without giving it a new GUID and, most inconveniently, change the target
names of everything in it. In reverse, doesn't that mean once I picked a
set of Play (and Support) tasks for a game executable and ship some MSI,
I'm pretty much stuck with that set of tasks forever (or go through some
inconveniences to ensure component rules are not broken)?

Thanks,
-f.r.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX 3 Shortcut Points to the Wrong File

[Pally Sandher]

There's a "How To:" in the WiX 3.0 documentation which describes how to
create shortcuts without any problems.


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

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 Buddell,
James
Sent: 11 September 2008 11:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX 3 Shortcut Points to the Wrong File

The shortcut points to the keypath of the component.

Just use the component of your main shortcut, that is always either
installed or uninstalled and that the app won't function without, or if
you like you can set multiple RemoveFile entries for each shortcut
Component. So long as the FileName column is blank it only removes empty
folders so it's not a problem to have multiple entries.

Cheers,
James

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tan, Tom
(Shanghai)
Sent: 11 September 2008 08:49
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX 3 Shortcut Points to the Wrong File

I am facing the same problem as described here:
http://blog.benday.com/archive/2007/08/09/23155.aspx

Now that I split each file into one component, I face another problem,
since all components are place into one folder I created. I am in a
dilemma to put the  tag.
Can anyone help me out? Thanks. 


-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge Build the coolest Linux based applications with Moblin SDK &
win great prizes Grand prize is a trip for two to an Open Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
This e-mail is confidential and the information contained in it may be
privileged.  It should not be read, copied or used by anyone other than
the intended recipient.  If you have received it in error, please
contact the sender immediately by telephoning +44 (0)20 7623 8000 or by
return email, and delete the e-mail and do not disclose its contents to
any person.  We believe, but do not warrant, that this e-mail and any
attachments are virus free, but you must take full responsibility for
virus checking.  Please refer to
http://www.dresdnerkleinwort.com/disc/email/ and read our e-mail
disclaimer statement and monitoring policy.

Dresdner Kleinwort is the trading name of the investment banking
division of Dresdner Bank AG, and operates through Dresdner Bank AG,
Dresdner Kleinwort Limited and their affiliated or associated companies.
Dresdner Bank AG is a company incorporated in Germany with limited
liability and registered in England (registered no. FC007638, place of
business 30 Gresham Street, London EC2V 7PG), and is authorised by the
German Federal Financial Supervisory Authority and by the Financial
Services Authority ('FSA') and regulated by the FSA for the conduct of
designated business in the UK.  Dresdner Kleinwort Limited is a company
incorporated in England (registered no. 551334, registered office 30
Gresham Street, London EC2V 7PG), and is authorised and regulated by the
FSA.  



-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge Build the coolest Linux based applications with Moblin SDK &
win great prizes Grand prize is a trip for two to an Open Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Jetty-Service.exe and

[Andy2k8]

Is there any way i can use  and  elements to
deal with a Jetty-Service?

I see that to register and start the jetty service,we should use the
following command lines:
To register:
Jetty-Service.exe -i jetty-service.conf
To start:
Jetty-Service.exe -t jetty-service.conf

I'm thinking of creating a console application jettyservice.exe that runs
these commands and call it from a type 18 CA 
OR Create a CA that launches these commands from the command line..

Do i have a better option here? any help?
  

-
Andy
MSI Developer
Schneider Electric:working:
-- 
View this message in context: 
http://n2.nabble.com/Jetty-Service.exe-and-%3CServiceInstall%3E-tp1082516p1082516.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] integrating two msi s problems

[Raj P]

Hi all,

   The problem that I am currently facing was,

I have two msi s, say AppA and AppB. AppB requires AppA to be installed on
the target machine ( treat AppB as some plugins, with out having base
application installed on the machine, having plugins is meaning less). To
verify this dependency, a registry entry will be created at the time of
installation of AppA. The problems that I am facing currently are,

1. At the time of uninstallation of AppA of AppB should also get uinstalled.
   For this some of the suggestions are
   a. Merging AppA and AppB and creation of new single msi will do the job.
But the problem is here if I want to upgrade/update either of the
applications ( not both)  is not possible ( why because they are in the form
of msm). Even if I create a new msi of either of the applications and do the
modifications, because it is another msi it won't get uinistall at the time
of uinstallation of single merged msi. ( meaning of upgradation of plugins
lost here)
refer this post :
http://sourceforge.net/mailarchive/message.php?msg_id=48BF4FA5.9020607%40joyofsetup.com

 b. Creation of an exe for launching the individual msi s is a good option,
but I need an msi ( it makes everything simple right).

2. Is there any way to uninstall a previous version before installing the
application. if so can any one please give me the wix statement.

3. How can we execute an upgraded msi by double clicking ( according to the
tutorial lesson 4, its not possbile right).

   I don't understand why we are unable to support plugins concept
by using wix.  Please help me,  Waiting for your valuable suggestions.
Thanks alot for your support.

 -Raj
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] WIX Upgrade code

[Yu, Brian]

Hi there

 

I've set up 3 msi. One base install(309) and 2 minor upgrades (499 and
599)

I expect that 599.msi can only br run when 499 is previously patched. 

However, I am able to run 599.msi straight after installing 309.msi

How do u specify this range?

 

309.wxs







 

499.wxs



   

  





599.wxs



   

  





 

 

 

Brian Yu

EasyScreen (Marex Financial)

155 Bishopsgate

London

EC2M 3TQ

0207 650 4410

 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX 3 Shortcut Points to the Wrong File

[Buddell, James]

The shortcut points to the keypath of the component.

Just use the component of your main shortcut, that is always either
installed or uninstalled and that the app won't function without, or if
you like you can set multiple RemoveFile entries for each shortcut
Component. So long as the FileName column is blank it only removes empty
folders so it's not a problem to have multiple entries.

Cheers,
James

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tan, Tom
(Shanghai)
Sent: 11 September 2008 08:49
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX 3 Shortcut Points to the Wrong File

I am facing the same problem as described here:
http://blog.benday.com/archive/2007/08/09/23155.aspx

Now that I split each file into one component, I face another problem,
since all components are place into one folder I created. I am in a
dilemma to put the  tag.
Can anyone help me out? Thanks. 


-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge Build the coolest Linux based applications with Moblin SDK &
win great prizes Grand prize is a trip for two to an Open Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
This e-mail is confidential and the information contained in it may be 
privileged.  It should not be read, copied or used by anyone other than the 
intended recipient.  If you have received it in error, please contact the 
sender immediately by telephoning +44 (0)20 7623 8000 or by return email, and 
delete the e-mail and do not disclose its contents to any person.  We believe, 
but do not warrant, that this e-mail and any attachments are virus free, but 
you must take full responsibility for virus checking.  Please refer to 
http://www.dresdnerkleinwort.com/disc/email/ and read our e-mail disclaimer 
statement and monitoring policy.

Dresdner Kleinwort is the trading name of the investment banking division of 
Dresdner Bank AG, and operates through Dresdner Bank AG, Dresdner Kleinwort 
Limited and their affiliated or associated companies.  Dresdner Bank AG is a 
company incorporated in Germany with limited liability and registered in 
England (registered no. FC007638, place of business 30 Gresham Street, London 
EC2V 7PG), and is authorised by the German Federal Financial Supervisory 
Authority and by the Financial Services Authority ('FSA') and regulated by the 
FSA for the conduct of designated business in the UK.  Dresdner Kleinwort 
Limited is a company incorporated in England (registered no. 551334, registered 
office 30 Gresham Street, London EC2V 7PG), and is authorised and regulated by 
the FSA.  


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] WiX 3 Shortcut Points to the Wrong File

[Tan, Tom (Shanghai)]

I am facing the same problem as described here:
http://blog.benday.com/archive/2007/08/09/23155.aspx

Now that I split each file into one component, I face another problem,
since all components are place into one folder I created. I am in a
dilemma to put the  tag.
Can anyone help me out? Thanks. 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] aspnet_regiis domain user

[derekj]

Hi, 

I am using WIX 2.0 

I have created a cmd line MSI to install an asp.net 2.0. 

I created an apppool with a user

 
  



 



  

I need to add this user to the IIS_WPG group, log on as service and ASP.Net
2.0
eg

aspnet_regiis -ga [domain]\user’

Has anyone done this successfully

regards

Derekj
-- 
View this message in context: 
http://n2.nabble.com/aspnet_regiis-domain-user-tp1082311p1082311.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Amending config file on install

[derekj]

Hi,

I am using WIX 2.0

I have created a cmd line MSI to install an asp.net 2.0.

One of the parameter inputs is the IP address of the respective application
database.

I would like to update my connections.config file with this IP  eg of config

I have seen examples where the wix user is updating a single xml value but i
want to just replace the ip a substring of connectionString value.


  
 


any help would be appreciated
-- 
View this message in context: 
http://n2.nabble.com/Amending-config-file-on-install-tp1082305p1082305.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Install components to the existing folder.

[Sergey Abakumoff]

Hello,
I try to install VS.NET templates as part of the setup package.
To do that I first read the path to VS.NET:

  

Then try to install the templates using:

  

  


Indeed, Wix compiler providers the error:
The DirectoryRef/@Id attribute's value,
'[VSNET2005]ItemTemplates\CSharp\1033', is not a legal identifier. 
Identifiers may contain ASCII characters A-Z, a-z, digits, underscores (_),
or periods (.).  Every identifier must begin with either a letter or an
underscore.

However, I don't have ideas about how to refer to the directory with path
that read from the registry.
Can anyone help to solve this problem?

-- 
View this message in context: 
http://n2.nabble.com/Install-components-to-the-existing-folder.-tp1082233p1082233.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Install components to the existing folder.

[Rob Hamflett]

You need to have a directory with an Id the same as the property, then have the 
sub-directories as 
child elements.  When the property changes, all the sub-directories will get 
updated as well.

Rob

Sergey Abakumoff wrote:
> Hello,
> I try to install VS.NET templates as part of the setup package.
> To do that I first read the path to VS.NET:
> 
>  Root="HKLM"
>   Key="SOFTWARE\Microsoft\VisualStudio\8.0"
>   Name="InstallDir"
>   Type="raw" />
> 
> Then try to install the templates using:
> 
>Guid="C2BD250B-E804-4932-ACF7-B48C62747F24">
>  Source="$(var.DDRProgramFiles)\Visual
> Studio\Templates\CSharpProjectItem\report.zip"/>
>   
> 
> 
> Indeed, Wix compiler providers the error:
> The DirectoryRef/@Id attribute's value,
> '[VSNET2005]ItemTemplates\CSharp\1033', is not a legal identifier. 
> Identifiers may contain ASCII characters A-Z, a-z, digits, underscores (_),
> or periods (.).  Every identifier must begin with either a letter or an
> underscore.
> 
> However, I don't have ideas about how to refer to the directory with path
> that read from the registry.
> Can anyone help to solve this problem?
> 


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Condition install and uninstall

[derekj]

Hi,

thanks for your help,

wondering if you know where I can find information on amending the condition
so it only fires on install and not on install. 

regards

Derekj

John Nannenga wrote:
> 
> Launch conditions fire when the condition is false:
>http://msdn.microsoft.com/en-us/library/aa369752.aspx
> 
> The property you likely mean to use is "Installed", not "INSTALLED".
>http://msdn.microsoft.com/en-us/library/aa369297(VS.85).aspx
> 
> 
> 
> From: [EMAIL PROTECTED]
> [EMAIL PROTECTED] On Behalf Of derekj
> [EMAIL PROTECTED]
> Sent: Wednesday, September 10, 2008 2:48 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users]  Condition install and uninstall
> 
> Hi,
> 
> I am doing a cmd line msi that has a number of input parameters.
> 
> I have
>  DATABASEIPADDRESS AND NOT INSTALLED
> 
> this condition is fires on both install and uninstall.
> 
> can someone help
> 
> regards
> 
> --
> View this message in context:
> http://n2.nabble.com/Condition-install-and-uninstall-tp1079400p1079400.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 

-- 
View this message in context: 
http://n2.nabble.com/Condition-install-and-uninstall-tp1079400p1082087.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users