Re: [WiX-users] SchedSecureObjectsRollback: Failed to store ACL rollback information with error 0x80070003 - continuing

[Steven Ogilvie]

Thanks John phew :)

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com] 
Sent: November-01-13 6:33 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] SchedSecureObjectsRollback: Failed to store ACL 
rollback information with error 0x80070003 - continuing

Pretty standard as I see it in all of my logs.  Permission/ACL's don't really 
rollback.  Noise.

--
John Merryweather Cooper
Build  Install Engineer -- ESA
Jack Henry  Associates, Inc.(r)
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com




-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Friday, November 1, 2013 5:06 PM
To: General discussion about the WiX toolset.
Subject: [WiX-users] SchedSecureObjectsRollback: Failed to store ACL rollback 
information with error 0x80070003 - continuing

Hi all,

I have seen this in my MSI log files but not really sure what this means:

MSI (s) (D8:28) [17:59:01:448]: Doing action: SchedSecureObjectsRollback Action 
17:59:01: SchedSecureObjectsRollback.
Action start 17:59:01: SchedSecureObjectsRollback.
MSI (s) (D8:68) [17:59:01:525]: Invoking remote custom action. DLL: 
C:\Windows\Installer\MSI1B3F.tmp, Entrypoint: SchedSecureObjectsRollback
SchedSecureObjectsRollback:  Entering SchedSecureObjectsRollback in 
C:\Windows\Installer\MSI1B3F.tmp, version 3.7.1224.0
SchedSecureObjectsRollback:  Failed to store ACL rollback information with 
error 0x80070003 - continuing MSI (s) (D8!A8) [17:59:01:533]: Note: 1: 2753 2: 
file_TitusSDF
SchedSecureObjectsRollback:  Error 0x8007007b: Unable to schedule rollback for 
object:
SchedSecureObjectsRollback:  Failed to store ACL rollback information with 
error 0x8007007b - continuing Action ended 17:59:01: 
SchedSecureObjectsRollback. Return value 1.

Any idea what it means?

Thanks,

Steve
--
Android is increasing in popularity, but the open development platform that 
developers love is also attractive to malware creators. Download this white 
paper to learn more about secure code signing practices that can help keep 
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are 
intended exclusively for the individual or entity to which it is addressed. The 
message, together with any attachment, may contain confidential and/or 
privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution is strictly prohibited. If you have received this message in 
error, please immediately advise the sender by reply email and delete all 
copies.


--
Android is increasing in popularity, but the open development platform that 
developers love is also attractive to malware creators. Download this white 
paper to learn more about secure code signing practices that can help keep 
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Custom action was working now it isn't.... HELP...

[Steven Ogilvie]

So weird...

Was working before, stopped working... function name had 26 characters removed 
7 characters now it works...

Go figure...

Steve

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] 
Sent: October-31-13 3:18 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Custom action was working now it isn't HELP...

http://stackoverflow.com/questions/3560370/custom-action-in-c-sharp-used-via-wix-fails-with-error-1154

Chris has quite a few suggestions on what could cause that error.

-Original Message-
From: StevenOgilvie [mailto:sogil...@msn.com]
Sent: Thursday, October 31, 2013 2:05 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Custom action was working now it isn't HELP...

A different pair of eyes should help...
I have a custom action that reads the registry and goes through the SQL Server 
Instances to get the last instance name (if there are more than one)... Was 
working like a charm, now for about a week it stopped working and I am getting 
this error:

Action ended 14:57:56: CostFinalize. Return value 1.
MSI (c) (A4:80) [14:57:56:213]: Doing action: CA_GetSQLServerInstanceName 
Action 14:57:56: CA_GetSQLServerInstanceName. CA: Getting SQL Server instance 
name...
Action start 14:57:56: CA_GetSQLServerInstanceName.
MSI (c) (A4:80) [14:57:56:240]: Creating MSIHANDLE (1) of type 790542 for 
thread 7552 MSI (c) (A4:2C) [14:57:56:241]: Invoking remote custom action. DLL:
C:\Users\STEVEN~1.OGI\AppData\Local\Temp\MSIF66D.tmp, Entrypoint:
GetSQLExpressInstanceName
MSI (c) (A4:A4) [14:57:56:242]: Cloaking enabled.
MSI (c) (A4:A4) [14:57:56:242]: Attempting to enable all disabled privileges 
before calling Install on Server MSI (c) (A4:A4) [14:57:56:242]: Connected to 
service for CA interface.
CustomAction CA_GetSQLServerInstanceName returned actual error code 1154 but 
will be translated to success due to continue marking MSI (c) (A4:2C) 
[14:57:56:375]: Closing MSIHANDLE (1) of type 790542 for thread 7552 Action 
ended 14:57:56: CA_GetSQLServerInstanceName. Return value 1.


The custom action is straight forward:
CustomAction Id=CA_GetSQLServerInstanceName BinaryKey=BIN_CustomAction
DllEntry=GetSQLExpressInstanceName Impersonate=no Execute=immediate
Return=ignore /
UI
  ProgressText Action=CA_GetSQLServerInstanceNameCA: Getting SQL Server 
instance name.../ProgressText
/UI

InstallExecuteSequence
  Custom Action=CA_GetSQLServerInstanceName After=InstallInitializeNOT 
Installed/Custom

InstallUISequence
  Custom Action=CA_GetSQLServerInstanceName
Before=MigrateFeatureStatesNOT Installed/Custom

Using a DTF custom action dll:

/// summary
/// Gets the SQL Server Express instance name for the SERVER_NAME /// 
/summary /// Session session /// returnsActionResult Success/returns 
[CustomAction] public static ActionResult GetSQLExpressInstanceName(Session 
session) {
try
{
if (session == null)
{
throw new ArgumentNullException(session);
}

SetSessionProperty(session, SQLSERVEREXPRESS_INSTANCE, 
string.Empty);

const string Key = @SOFTWARE\\Microsoft\\Microsoft SQL 
Server\\Instance Names\\SQL;
var localMachine = RegistryKey.OpenBaseKey(
RegistryHive.LocalMachine,
Environment.Is64BitOperatingSystem ?
RegistryView.Registry64 : RegistryView.Registry32);
var regKey = localMachine.OpenSubKey(Key);
if (regKey != null)
{
foreach (var valueName in regKey.GetValueNames())
{
if (!string.Equals(valueName, MSSQLSERVER))
{
var expressKey = @SOFTWARE\\Microsoft\\Microsoft 
SQL Server\\ + valueName;
var expressRegKey = 
localMachine.OpenSubKey(expressKey);
if (expressRegKey != null)
{
SetSessionProperty(session, 
SQLSERVEREXPRESS_INSTANCE, \\ + valueName);
}
}
}
}
}
catch (Exception ex)
{
WriteErrorLogInstall(session, GetSQLExpressInstanceName
failed: , ex, true);
}

return ActionResult.Success; }

Any ideas why this isn't working?

thanks,

Steve



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-action-was-working-now-it-isn-t-HELP-tp7590194.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Android is increasing in popularity, but the open development platform that 
developers love is also attractive to malware creators. Download this white 
paper to learn more 

Re: [WiX-users] Custom action was working now it isn't.... HELP...

[Steven Ogilvie]

Wasn't a compile error, was a runtime error...

Well it is working now, very strange was doing diffs between the custom action 
cs file and the product.wxs file and can't see what could have broken it, like 
I said it was working until a few days ago...

Strange

-Original Message-
From: Christopher Painter [mailto:chr...@iswix.com] 
Sent: October-31-13 4:18 PM
To: General discussion about the WiX toolset.; General discussion about the WiX 
toolset.
Subject: Re: [WiX-users] Custom action was working now it isn't HELP...

Hmmm... I'm guessing there was something else at play.  DTF can handle entry 
points up to 72 characters in length before it'll throw a compile error. 


 From: Steven Ogilvie steven.ogil...@titus.com
Sent: Thursday, October 31, 2013 2:57 PM
To: General discussion about the WiX toolset. 
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Custom action was working now it isn't 
HELP...

So weird...

Was working before, stopped working... function name had 26 characters removed 
7 characters now it works...

Go figure...

Steve

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: October-31-13 3:18 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Custom action was working now it isn't 
HELP...

http://stackoverflow.com/questions/3560370/custom-action-in-c-sharp-used-via
-wix-fails-with-error-1154

Chris has quite a few suggestions on what could cause that error.

-Original Message-
From: StevenOgilvie [mailto:sogil...@msn.com]
Sent: Thursday, October 31, 2013 2:05 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Custom action was working now it isn't HELP...

A different pair of eyes should help...
I have a custom action that reads the registry and goes through the SQL Server 
Instances to get the last instance name (if there are more than one)... Was 
working like a charm, now for about a week it stopped working and I am getting 
this error:

Action ended 14:57:56: CostFinalize. Return value 1.
MSI (c) (A4:80) [14:57:56:213]: Doing action: CA_GetSQLServerInstanceName 
Action 14:57:56: CA_GetSQLServerInstanceName. CA: Getting SQL Server instance 
name...
Action start 14:57:56: CA_GetSQLServerInstanceName.
MSI (c) (A4:80) [14:57:56:240]: Creating MSIHANDLE (1) of type 790542 for 
thread 7552 MSI (c) (A4:2C) [14:57:56:241]: Invoking remote custom action. 
DLL:
C:\Users\STEVEN~1.OGI\AppData\Local\Temp\MSIF66D.tmp, Entrypoint:
GetSQLExpressInstanceName
MSI (c) (A4:A4) [14:57:56:242]: Cloaking enabled.
MSI (c) (A4:A4) [14:57:56:242]: Attempting to enable all disabled privileges 
before calling Install on Server MSI (c) (A4:A4) [14:57:56:242]: 
Connected to service for CA interface.
CustomAction CA_GetSQLServerInstanceName returned actual error code 1154 but 
will be translated to success due to continue marking MSI (c) (A4:2C)
[14:57:56:375]: Closing MSIHANDLE (1) of type 790542 for thread 7552 Action 
ended 14:57:56: CA_GetSQLServerInstanceName. Return value 1.

The custom action is straight forward:
CustomAction Id=CA_GetSQLServerInstanceName 
BinaryKey=BIN_CustomAction
DllEntry=GetSQLExpressInstanceName Impersonate=no Execute=immediate
Return=ignore /
UI
  ProgressText Action=CA_GetSQLServerInstanceNameCA: Getting SQL Server 
instance name.../ProgressText
/UI

InstallExecuteSequence
  Custom Action=CA_GetSQLServerInstanceName 
After=InstallInitializeNOT Installed/Custom

InstallUISequence
  Custom Action=CA_GetSQLServerInstanceName
Before=MigrateFeatureStatesNOT Installed/Custom

Using a DTF custom action dll:

/// summary
/// Gets the SQL Server Express instance name for the SERVER_NAME /// 
/summary /// Session session /// returnsActionResult Success/returns 
[CustomAction] public static ActionResult GetSQLExpressInstanceName(Session
session) {
try
{
if (session == null)
{
throw new ArgumentNullException(session);
}

SetSessionProperty(session, SQLSERVEREXPRESS_INSTANCE, 
string.Empty);

const string Key = @SOFTWARE\\Microsoft\\Microsoft SQL 
Server\\Instance Names\\SQL;
var localMachine = RegistryKey.OpenBaseKey(
RegistryHive.LocalMachine,
Environment.Is64BitOperatingSystem ?
RegistryView.Registry64 : RegistryView.Registry32);
var regKey = localMachine.OpenSubKey(Key);
if (regKey != null)
{
foreach (var valueName in regKey.GetValueNames())
{
if (!string.Equals(valueName, MSSQLSERVER))
{
var expressKey = @SOFTWARE\\Microsoft\\Microsoft 
SQL Server\\ + valueName;
var expressRegKey = 
localMachine.OpenSubKey(expressKey);
if (expressRegKey

Re: [WiX-users] Burn Question

[Steven Ogilvie]

Depending on what your custom environment is like as well... some gov shops 
don't give out internet access... so downloading is not an option...

-Original Message-
From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com] 
Sent: October-30-13 2:38 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Burn Question

2013/10/30 Christopher Painter chr...@iswix.com:
 One approach would be that 1.1 is a web download installer that 
 contains all 25 packages  but will only download 5 of them.  I'm not sure if 
 Big
 product will buy into this or not though.

As far as I know, shipping packages in the bundle vs downloading them is not 
all-or-nothing. You can ship some packages in the bundle and download others on 
demand. In this case, you can ship those 5 packages in the bundle, and leave 
the others to be downloaded, which in most cases they won't be.

--
Nicolás

--
Android is increasing in popularity, but the open development platform that 
developers love is also attractive to malware creators. Download this white 
paper to learn more about secure code signing practices that can help keep 
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Fwd: GUI for wix

[Steven Ogilvie]

I use Sharp Develop for creating my Dialogs in WIX:
http://www.icsharpcode.net/OpenSource/SD/Default.aspx

Course you could just use Visual Studio 2010/2012?

Steve

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] 
Sent: October-29-13 12:26 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Fwd: GUI for wix

http://iswix.codeplex.com/ might be an option, however you will still need to 
know the Xml format for debugging and advanced options.

-Original Message-
From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com]
Sent: Tuesday, October 29, 2013 11:18 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Fwd: GUI for wix

El martes, 29 de octubre de 2013, Александр Смагин escribió:

 Hello,
 I'm sorry for my stupid question. Can anyone tell me is there a GUI 
 (graphic user interface) tool to visualize wxs script, or all content 
 is written by hands?

 I found WixEdit editor but it craches on my Win 8.1.


What do you expect in such a GUI beyond a specialized text editor?

Either way nothing will really let you skip understanding how WiX and MSI works.

--
Nicolás
--
Android is increasing in popularity, but the open development platform that 
developers love is also attractive to malware creators. Download this white 
paper to learn more about secure code signing practices that can help keep 
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Android is increasing in popularity, but the open development platform that 
developers love is also attractive to malware creators. Download this white 
paper to learn more about secure code signing practices that can help keep 
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Fwd: GUI for wix

[Steven Ogilvie]

Nope, it is all XML based,

Here are a few websites that can help:

http://wix.tramontana.co.hu/
http://wixtoolset.org/documentation/manual/v3/main%5Cwix_learning.html

http://stackoverflow.com/questions/310418/good-resources-for-learning-how-to-create-msi-installers-from-wix

these should help you out :)

Steve

-Original Message-
From: Александр Смагин [mailto:smagin.alexan...@gmail.com] 
Sent: October-29-13 5:26 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Fwd: GUI for wix

HI Steve,

Could you provide tutorial how to use wix in VS2012? I modify already created 
project in VS2012 and they used wix as installation. in my version of VS, just 
xml is opened. there is no any interface to create/modify it more easily. I'm 
beginner in VS, sorry

Thanks.

Alex.
--
Android is increasing in popularity, but the open development platform that 
developers love is also attractive to malware creators. Download this white 
paper to learn more about secure code signing practices that can help keep 
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Need help with the error A DLL required for this install to complete could not be run

[Steven Ogilvie]

Open up the MSI in ORCA and goto InstallExecuteSequence element. Sort the 
sequences in numeric order and see where your custom action is being called 
now, perhaps it has been moved before the removefiles sequence (which is 
sequence order 3500)?

Steve

-Original Message-
From: Suryadeep Biswal [mailto:surya6...@hotmail.com] 
Sent: October-24-13 3:24 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Need help with the error A DLL required for this install 
to complete could not be run

Hi,

 

During uninstallation path, Our MSI executes a custom action say RemoveXX which 
executes RemoveYY method from the dll MyDLL.
This custom action is scheduled before RemoveFiles in Install Execute 
sequence. The MSI been tested many times over the past 6 months and has always 
worked without any issues. Recently, we saw a very strange issue on a VM 
running on Windows Server 2008 R2, where MyDLL gets removed by the time the 
custom action RemoveXX executes. As a result, the CA fails resulting in the 
uninstallation failure with a dialog that contains this message - 

 

A DLL required for this install to complete could not be run.

 

The log file indicates the same issue - 

 

CustomAction RemoveXX returned actual error code
1157 (note this may not be 100% accurate if translation happened inside
sandbox)

MSI (s) (C8:28) [12:14:56:354]: Product: MyProduct -- Error 1723. There is a 
problem with this Windows Installer package. A DLL required for this install to 
complete could not be run. Contact your support personnel or package vendor.  
Action RemoveXX, entry: RemoveYY, library:
InstallPath\MyDLL.dll

 

After repair/reinstallation, I verified that MyDLL exists under InstallPath but 
the during uninstallation it gets removed by the time I see the dialog. Please 
note that other files are still present under InstallPath.

I have tried analyzing the log file (that was generated using /l*vx, containing 
extra debugging information), but I see no information regarding MyDLL getting 
removed before the Custom action scheduling.

 

I would appreciate in any help with - 

1.  
A way to debug this issue.

2.  
Any ideas/theories on what might be going on here.

 

Regards,

Surya 
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register  
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Setup Testing

[Steven Ogilvie]

I think the only way you could do this (if you can)
Is once the app is installed run a custom action to call your application with 
the credentials entered in Step 3 (assign them to properties) depending on the 
return code handle the error code, and continue on. 

I am not really sure how you will ask to re-enter the credentials if the creds 
are incorrect... you would have to run this custom action after the 
installfiles execute sequence (does this app require registry settings/com 
etc.?)

Steve

-Original Message-
From: Rob Emanuele [mailto:robert.emanu...@rackspace.com] 
Sent: October-24-13 5:23 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Setup Testing

Hi,

Let me try to be as clear about this as possible.  We're using WiX to create 
our MSI.  We are looking to make a flow like this:

1. Welcome
2. EULA
3. Credentials
4. Install (directories, copy files)
5. Run app with creds on command line (our app has no GUI) 6. Handle return 
code from app 6a. Ask for creds again if needed based on return code 6b. Handle 
other return codes 7. Install Service 8. Finish

Can I bend WiX to our needs or do we look at another plan?

Thanks,

Rob




From: Hoover, Jacob [jacob.hoo...@greenheck.com]
Sent: Thursday, October 24, 2013 8:56 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Setup Testing

If the EXE is installed by the MSI, then you would need burn and a fake Exe 
package later in the chain in order to be able to interact with the installed 
exe.  From there, you could interpret the return code.

If this is simply for installing and configuring the service, I would avoid the 
exe altogether and utilize existing service functionality of Wix/Windows 
Installer, and configure it with existing file operations (XmlFile and the 
likes).

-Original Message-
From: Wesley Manning [mailto:wmann...@dynagen.ca]
Sent: Thursday, October 24, 2013 8:11 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Setup Testing

So you are using MSI?  If you are using burn you can use ExePackage element.  
Have burn run your MSI using MsiPackage to install service/etc and then run 
your exe using ExePackage.  Not an expert in what you're trying to do but a 
thought.

Wes

-Original Message-
From: Rob Emanuele [mailto:robert.emanu...@rackspace.com]
Sent: October-24-13 3:56 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Setup Testing

Hi Blair,

I wish it was that simple.  It isn't a GUI application, it is a service (which 
you can control from the command line).  It has no GUI.  We can write one, but 
hoped we could just use the easy to develop GUI in the installer using WiX to 
configure the service's config file.  On top of that we hoped to validate the 
credentials supplied.

This is for the Rackspace Monitoring Agent, an on-host agent, which we are 
looking to improve the installation and configuring process for our Windows 
users.  My work-in-progress on revising this installer: 
https://github.com/racker/virgo-base/blob/b46ff4e8f004654ecd07a3f2f5742c80337aee8a/pkg/windows/virgo.wxs

The service's exe can create the setup file and validate it exiting with a 
non-zero error code on failure.  What I am asking is can a WiX created 
installer execute an installed exe and act on its return code.

This may not be as simple as I hoped.  My initial research looks like there are 
ways to run an exe but not interpret its return code.  Other options look like 
I can use WcaUtil to hook into a wrapper.  It doesn't look simple either way, 
maybe someone will either tell me I'm wrong or give me another way to look it.

Thank you for your help,

Rob

From: Blair Murri [os...@live.com]
Sent: Wednesday, October 23, 2013 8:35 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Setup Testing

I'm not sure I understand what you are asking.

The simple answer is: install the app, then run the app passing the supplied 
credentials on the command line. It seems to me that it would be easier to not 
involve the installer in the credentials because there isn't much difference 
between that and simply installing and launching and letting the application 
ask for the credentials.

Every other possibility requires knowing more details about your application 
and your need/goals in having the installer gather the credentials in the first 
place.

Blair


Rob Emanuele robert.emanu...@rackspace.com wrote:

Hi!

We're creating an installer and would like the user to enter their account 
credentials into the installer.  I have a dialog to do that and that part is 
looking good.  I'd like use those credentials to run a test of our application 
in the installer.  Can I run my application and act on the return code within 
the installer?

Thank you,

Rob

--

[WiX-users] returned actual error code 1154 from custom action

[Steven Ogilvie]

Hi,

I am calling a custom action on uninstall just to ensure that our 5 services 
are actually stopped before we try to remove them...

However I am getting an error that confuses me since everything looks kosher...

Anyone see any issues with what I am doing?

Here is the error from the log file:
MSI (s) (6C:D4) [23:30:16:875]: Executing op: 
ActionStart(Name=CA_STOPESSERVICE.A54690A6_C7B5_477D_ADAF_916A4A173FDF,Description=CA:
 Stopping TITUS Enterprise Settings Service...,)
MSI (s) (6C:D4) [23:30:16:875]: Executing op: 
CustomActionSchedule(Action=CA_STOPESSERVICE.A54690A6_C7B5_477D_ADAF_916A4A173FDF,ActionType=3137,Source=BinaryData,Target=StopServiceForUninstall,CustomActionData=TITUS.Enterprise.Settings.Host|)
MSI (s) (6C:28) [23:30:16:937]: Invoking remote custom action. DLL: 
C:\Windows\Installer\MSIF6FB.tmp, Entrypoint: StopServiceForUninstall
CustomAction CA_STOPESSERVICE.A54690A6_C7B5_477D_ADAF_916A4A173FDF returned 
actual error code 1154 but will be translated to success due to continue marking


Custom Action:
CustomAction Id=SetStopESService Property=CA_STOPESSERVICE 
Value=TITUS.Enterprise.Settings.Host| /
CustomAction Id=CA_STOPESSERVICE BinaryKey=BIN_CustomActionMM 
DllEntry=StopServiceForUninstall Impersonate=no Execute=deferred 
Return=ignore /

InstallExecuteSequence
Custom Action=SetStopESService After=InstallValidateInstalled/Custom
Custom Action=CA_STOPESSERVICE After=StopServicesInstalled/Custom

DTF Custom Action DLL C#

public static ActionResult StopServiceForUninstall(Session session)
{
var serviceName = string.Empty;
try
{
if (session == null)
{
throw new ArgumentNullException(session);
}

var tempString = GetSessionProperty(session, 
CustomActionData, false);
var parts = tempString.Split(new[] { '|' });
serviceName = parts[0];

var sc = new ServiceController { ServiceName = serviceName };

if (sc.Status == ServiceControllerStatus.Running)
{
// Stop the service
try
{
// Stop the service.
sc.Stop();
sc.WaitForStatus(ServiceControllerStatus.StopPending, 
TimeSpan.FromSeconds(30));
}
catch (TimeoutException exception)
{
WriteErrorLogInstall(session, TimeoutException: could 
not stop the  + serviceName +  service., exception, true);
}
}
}
catch (Exception ex)
{
WriteErrorLogInstall(session, Could not stop service:  + 
serviceName +  ., ex, true);
}
return ActionResult.Success;
}

Thanks,

Steve


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX Toolset installer (Wix36.exe, Wix37.exe)

[Steven Ogilvie]

Most likely because the installer is installing pre requisites and other tools, 
it is also using its burn technology.
There are multiple MSI's being run.

steve

-Original Message-
From: Jens Teutenberg [mailto:jens.teutenb...@t-online.de] 
Sent: October-18-13 8:30 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX Toolset installer (Wix36.exe, Wix37.exe)

I don’t like the installer which is used since V3.6 (Wix36.exe, Wix37.exe).
Why it isn’t possible to release a MSI file as used before V3.6 (Wix2.msi, 
Wix3.msi, Wix35.msi)?
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register  
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] returned actual error code 1154 from custom action

[Steven Ogilvie]

I am following the DTF guidelines...

I am using service control:
ServiceControl Id=StartSettingsService Name=TITUS.Enterprise.Settings.Host 
Stop=both Wait=yes /

But there are some instances where a service(s) hasn't stopped so this is an 
extra fail safe...

Steve

-Original Message-
From: David Watson [mailto:dwat...@sdl.com] 
Sent: October-18-13 9:34 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] returned actual error code 1154 from custom action

Check out this 
http://stackoverflow.com/questions/3560370/custom-action-in-c-sharp-used-via-wix-fails-with-error-1154

Why are you not using the service control element to ensure the service is 
stopped?
http://wixtoolset.org/documentation/manual/v3/xsd%5Cwix%5Cservicecontrol.html


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 18 October 2013 13:37
To: General discussion about the WiX toolset.
Subject: [WiX-users] returned actual error code 1154 from custom action

Hi,

I am calling a custom action on uninstall just to ensure that our 5 services 
are actually stopped before we try to remove them...

However I am getting an error that confuses me since everything looks kosher...

Anyone see any issues with what I am doing?

Here is the error from the log file:
MSI (s) (6C:D4) [23:30:16:875]: Executing op: 
ActionStart(Name=CA_STOPESSERVICE.A54690A6_C7B5_477D_ADAF_916A4A173FDF,Description=CA:
 Stopping TITUS Enterprise Settings Service...,) MSI (s) (6C:D4) 
[23:30:16:875]: Executing op: 
CustomActionSchedule(Action=CA_STOPESSERVICE.A54690A6_C7B5_477D_ADAF_916A4A173FDF,ActionType=3137,Source=BinaryData,Target=StopServiceForUninstall,CustomActionData=TITUS.Enterprise.Settings.Host|)
MSI (s) (6C:28) [23:30:16:937]: Invoking remote custom action. DLL: 
C:\Windows\Installer\MSIF6FB.tmp, Entrypoint: StopServiceForUninstall 
CustomAction CA_STOPESSERVICE.A54690A6_C7B5_477D_ADAF_916A4A173FDF returned 
actual error code 1154 but will be translated to success due to continue marking


Custom Action:
CustomAction Id=SetStopESService Property=CA_STOPESSERVICE 
Value=TITUS.Enterprise.Settings.Host| / CustomAction Id=CA_STOPESSERVICE 
BinaryKey=BIN_CustomActionMM DllEntry=StopServiceForUninstall 
Impersonate=no Execute=deferred Return=ignore /

InstallExecuteSequence
Custom Action=SetStopESService After=InstallValidateInstalled/Custom
Custom Action=CA_STOPESSERVICE After=StopServicesInstalled/Custom

DTF Custom Action DLL C#

public static ActionResult StopServiceForUninstall(Session session)
{
var serviceName = string.Empty;
try
{
if (session == null)
{
throw new ArgumentNullException(session);
}

var tempString = GetSessionProperty(session, 
CustomActionData, false);
var parts = tempString.Split(new[] { '|' });
serviceName = parts[0];

var sc = new ServiceController { ServiceName = serviceName };

if (sc.Status == ServiceControllerStatus.Running)
{
// Stop the service
try
{
// Stop the service.
sc.Stop();
sc.WaitForStatus(ServiceControllerStatus.StopPending, 
TimeSpan.FromSeconds(30));
}
catch (TimeoutException exception)
{
WriteErrorLogInstall(session, TimeoutException: could 
not stop the  + serviceName +  service., exception, true);
}
}
}
catch (Exception ex)
{
WriteErrorLogInstall(session, Could not stop service:  + 
serviceName +  ., ex, true);
}
return ActionResult.Success;
}

Thanks,

Steve


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register  
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK

Re: [WiX-users] returned actual error code 1154 from custom action

[Steven Ogilvie]

Aha, looked at it again and I noticed I didn't' have 
[CustomAction]
public static ActionResult StopServiceForUninstall(Session session)

I only had
public static ActionResult StopServiceForUninstall(Session session)

sigh...

I am not using WIX to create the service(s) we are using NServiceBus, so I am 
using NServiceBus.host.exe to create/uninstall the services

Steve

-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com] 
Sent: October-18-13 10:59 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] returned actual error code 1154 from custom action

The problem appears to be as described in that stackoverflow link. You may be 
calling the managed Dll directly from the installer, Windows is expecting an 
unmanaged Dll, and so it describes the Dll as corrupt.

It might be worthwhile figuring out why the standard StopServices doesn't 
always work. It might be that the Services are slow to stop. Sometimes that 
code in a service can be less than optimal if it doesn't follow the protocol 
nicely, and if necessary explicitly say that it needs more time to shut down.

Phil Wilson


On Fri, Oct 18, 2013 at 6:46 AM, Steven Ogilvie steven.ogil...@titus.comwrote:

 I am following the DTF guidelines...

 I am using service control:
 ServiceControl Id=StartSettingsService
 Name=TITUS.Enterprise.Settings.Host Stop=both Wait=yes /

 But there are some instances where a service(s) hasn't stopped so this 
 is an extra fail safe...

 Steve

 -Original Message-
 From: David Watson [mailto:dwat...@sdl.com]
 Sent: October-18-13 9:34 AM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] returned actual error code 1154 from custom 
 action

 Check out this
 http://stackoverflow.com/questions/3560370/custom-action-in-c-sharp-us
 ed-via-wix-fails-with-error-1154

 Why are you not using the service control element to ensure the 
 service is stopped?

 http://wixtoolset.org/documentation/manual/v3/xsd%5Cwix%5Cservicecontr
 ol.html


 -Original Message-
 From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
 Sent: 18 October 2013 13:37
 To: General discussion about the WiX toolset.
 Subject: [WiX-users] returned actual error code 1154 from custom 
 action

 Hi,

 I am calling a custom action on uninstall just to ensure that our 5 
 services are actually stopped before we try to remove them...

 However I am getting an error that confuses me since everything looks 
 kosher...

 Anyone see any issues with what I am doing?

 Here is the error from the log file:
 MSI (s) (6C:D4) [23:30:16:875]: Executing op:
 ActionStart(Name=CA_STOPESSERVICE.A54690A6_C7B5_477D_ADAF_916A4A173FDF,Description=CA:
 Stopping TITUS Enterprise Settings Service...,) MSI (s) (6C:D4)
 [23:30:16:875]: Executing op:
 CustomActionSchedule(Action=CA_STOPESSERVICE.A54690A6_C7B5_477D_ADAF_9
 16A4A173FDF,ActionType=3137,Source=BinaryData,Target=StopServiceForUni
 nstall,CustomActionData=TITUS.Enterprise.Settings.Host|)
 MSI (s) (6C:28) [23:30:16:937]: Invoking remote custom action. DLL:
 C:\Windows\Installer\MSIF6FB.tmp, Entrypoint: StopServiceForUninstall 
 CustomAction CA_STOPESSERVICE.A54690A6_C7B5_477D_ADAF_916A4A173FDF 
 returned actual error code 1154 but will be translated to success due 
 to continue marking


 Custom Action:
 CustomAction Id=SetStopESService Property=CA_STOPESSERVICE
 Value=TITUS.Enterprise.Settings.Host| / CustomAction 
 Id=CA_STOPESSERVICE BinaryKey=BIN_CustomActionMM
 DllEntry=StopServiceForUninstall Impersonate=no Execute=deferred
 Return=ignore /

 InstallExecuteSequence
 Custom Action=SetStopESService
 After=InstallValidateInstalled/Custom
 Custom Action=CA_STOPESSERVICE 
 After=StopServicesInstalled/Custom

 DTF Custom Action DLL C#

 public static ActionResult StopServiceForUninstall(Session session)
 {
 var serviceName = string.Empty;
 try
 {
 if (session == null)
 {
 throw new ArgumentNullException(session);
 }

 var tempString = GetSessionProperty(session, 
 CustomActionData, false);
 var parts = tempString.Split(new[] { '|' });
 serviceName = parts[0];

 var sc = new ServiceController { ServiceName = 
 serviceName };

 if (sc.Status == ServiceControllerStatus.Running)
 {
 // Stop the service
 try
 {
 // Stop the service.
 sc.Stop();

 sc.WaitForStatus(ServiceControllerStatus.StopPending,
 TimeSpan.FromSeconds(30));
 }
 catch (TimeoutException exception)
 {
 WriteErrorLogInstall(session, TimeoutException:
 could not stop the  + serviceName +  service., exception, true);
 }
 }
 }
 catch (Exception

Re: [WiX-users] How to Make a Wix Installer for my Outlook Addin

[Steven Ogilvie]

Google how to create a simple WIX install

http://wix.tramontana.co.hu/tutorial

http://stackoverflow.com/questions/310418/good-resources-for-learning-how-to-create-msi-installers-from-wix

http://www.codeproject.com/Tips/105638/A-quick-introduction-Create-an-MSI-installer-with

Steve

-Original Message-
From: Sanju Thomas [mailto:sanju...@gmail.com] 
Sent: October-16-13 8:08 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to Make a Wix Installer for my Outlook Addin

I am a newbie to Wix Installer. I want to make an Installer for my Outlook 
Addin in Wix. How can I do it.

-- 

*Regards*
*
*
*Sanju Thomas
*
*91- 9945535476
*
*sanju...@gmail.com*
* http://www.intelligo.in/*

*
*CONFIDENTIALITY NOTICE: If you have received this e-mail in error, please 
immediately notify the sender by e-mail at the address shown. This e-mail 
transmission may contain confidential information. This information is intended 
only for the use of the individual(s) or entity to whom it is intended even if 
addressed incorrectly. Please delete it from your files if you are not the 
intended recipient. Thank you for your compliance.
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register  
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Set Registry for both 32 and 64 bit

[Steven Ogilvie]

http://insomniacgeek.com/target-32bit-and-64bit-net-applications/
http://stackoverflow.com/questions/13147498/how-to-deploy-64-bit-and-a-32-bit-windows-installer-package-as-a-single-setup


-Original Message-
From: Chaitanya [mailto:chaita...@pointcross.com] 
Sent: October-09-13 5:40 AM
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Set Registry for both 32 and 64 bit

Hi,
I am preparing multiple installers for 64 and 32 bit because of registry.Is 
there  any tag for creating one installer for both 32 and 64 bit

--
Thanks  Regards,
Chaitanya.


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error code is 2858

[Steven Ogilvie]

Is it an animated GIF?

If not why not use a BMP instead? I believe dialogs can only use BMP...

Steve

-Original Message-
From: Tunney, Stephen [mailto:stephen.tun...@nuance.com] 
Sent: October-09-13 12:20 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Error code is 2858

Hello everyone,

I'm getting this error as a debug message when attempting to display two GIF 
images in a UI.

I have attached them to this email.  Below is the dialog utilizing those files. 
 Some OSes show the images ok.  Others do not.  Any suggestions would be 
helpful as I have Google'd and nothing is coming up yet:

?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
  Fragment
Binary Id=FirewallEnabledBmp 
SourceFile=$(var.SolutionDir)Enabled-transparent.gif /
Binary Id=FirewallDisabledBmp 
SourceFile=$(var.SolutionDir)Disabled-transparent.gif /

Property Id=SET_FIREWALL_RULES Value=0 Admin=yes Secure=yes/

UI
  PropertyRef Id=SET_FIREWALL_RULES/
  Dialog Id=EQ_FirewallQuestionDlg Width=370 Height=270
Control Id=Back Type=PushButton X=180 Y=243 Width=56 
Height=17 Text=!(loc.WixUIBack) /
Control Id=Next Type=PushButton X=236 Y=243 Width=56 
Height=17 Default=yes Text=!(loc.WixUINext) /
Control Id=Cancel Type=PushButton X=304 Y=243 Width=56 
Height=17 Cancel=yes Text=!(loc.WixUICancel)
  Publish Event=SpawnDialog Value=CancelDlg1/Publish
/Control
Control Id=Description Type=Text X=25 Y=23 Width=280 
Height=15 Transparent=yes NoPrefix=yes 
Text=!(loc.EQ_FirewallQuestionDlg_SubTitle) /
Control Id=Title Type=Text X=15 Y=6 Width=200 Height=15 
Transparent=yes NoPrefix=yes Text=!(loc.EQ_FirewallQuestionDlg_Title) /
Control Id=BannerBitmap Type=Bitmap X=0 Y=0 Width=370 
Height=44 TabSkip=no Text=!(loc.EQ_FirewallQuestionDlg_BannerBitmap) /
Control Id=BannerLine Type=Line X=0 Y=44 Width=370 
Height=0 /
Control Id=BottomLine Type=Line X=0 Y=234 Width=370 
Height=0 /
Control Type=Bitmap Id=EnableFirewall Width=48 Height=48 
X=15 Y=65 Text=FirewallEnabledBmp /
Control Type=Bitmap Id=DisableFirewall Width=48 Height=48 
X=15 Y=136 Text=FirewallDisabledBmp /
Control Type=RadioButtonGroup Property=SET_FIREWALL_RULES 
Id=FirewallSelectionRadioButtonGroup Width=290 Height=100 X=70 Y=65
  RadioButtonGroup Property=SET_FIREWALL_RULES
RadioButton 
Text=!(loc.EQ_FirewallQuestionDlg_EnabledRadioButtonText) Height=17 
Value=1 Width=200 X=0 Y=0 /
RadioButton 
Text=!(loc.EQ_FirewallQuestionDlg_DisabledRadioButtonText) Height=17 
Value=0 Width=200 X=0 Y=70 /
  /RadioButtonGroup
/Control
Control Type=Text Id=EnabledDescription Width=260 Height=40 
X=90 Y=90 Text=!(loc.EQ_FirewallQuestionDlg_EnabledDescription_Text) /
Control Type=Text Id=DisabledDescription Width=260 Height=50 
X=90 Y=160 Text=!(loc.EQ_FirewallQuestionDlg_DisabledDescription_Text) /
  /Dialog
/UI
  /Fragment
/Wix

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Can't compile Install getting ICE30 error...

[Steven Ogilvie]

Solved it...

I created a customaction to populate a property with the powershell folder

CustomAction Id=CA_Set_PowerShellx86_Path Directory=POWERSHELLX86_DIR 
Value=[POWERSHELLPATH_X86]/
CustomAction Id=CA_Set_PowerShellx64_Path Directory=POWERSHELLX64_DIR 
Value=[POWERSHELLPATH_X64]/

I use the Directory property Directory=POWERSHELLX86_DIR as the directory 
for the component...

Sigh..

Steve

-Original Message-
From: StevenOgilvie [mailto:sogil...@msn.com] 
Sent: October-08-13 1:05 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Can't compile Install getting ICE30 error...

Hi guys,

I am trying to install 1 file to 2 different locations by using 2 different 
directory elements, 2 different component elements and 2 different file 
elements.

Before I do this I have a custom action that copies the powershell.exe.config 
to powershell.exe.config.bak (I try both the system32 and the SysWOW64 
powershell folders.

Here is my WIX code for the file copy..

 Property Id=POWERSHELLPATH_X86 Value=0
  RegistrySearch Id=Find_POWERSHELLPATH_x86
  Type=directory
  Root=HKLM
 
Key=SOFTWARE\Wow6432Node\Microsoft\PowerShell\1\PowerShellEngine
  Name=ApplicationBase
  Win64=no/
/Property
Property Id=POWERSHELLPATH_X64 Value=0
  RegistrySearch Id=Find_POWERSHELLPATH_x64
  Type=directory
  Root=HKLM
  Key=SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine
  Name=ApplicationBase
  Win64=yes/
/Property

ComponentRef Id=cmp_PSConfig_System32/ ComponentRef 
Id=cmp_PSConfig_SysWOW64/

Directory Id=TARGETDIR Name=SourceDir

Directory Id=POWERSHELLPATH_X64 Name=PowerShell X64 DiskId=1
Component Id=cmp_PSConfig_System32
Guid={BC51F641-03C1-4477-9976-F464A61A3921} KeyPath=yes Permanent=yes
Shared=no
File Id=file_PSConfig_System32 Name=powershell.exe.config
Source=$(var.resourcePath)\powershell.exe.config /
/Component
  /Directory
  Directory Id=POWERSHELLPATH_X86 Name=PowerShell x86 DiskId=1
Component Id=cmp_PSConfig_SysWOW64
Guid={51F24D8C-FE09-4FEA-8F8D-5C645A3F9D40} KeyPath=yes Permanent=yes
Shared=no
File Id=file_PSConfig_SysWOW64 Name=powershell.exe.config
Source=$(var.resourcePath)\powershell.exe.config /
/Component
  /Directory

here are the two errors:

Error   13  ICE30: The target file 'j47lduzx.con|powershell.exe.config' is
installed in '0' by two different components on an LFN system:
'cmp_PSConfig_System32' and 'cmp_PSConfig_SysWOW64'. This breaks component
reference counting. C:\Dev\Core
Technologies\Main\Setup\Services_Setup_x64\Product.wxs  290 1
Services_Setup_x64
Error   14  ICE30: The target file 'j47lduzx.con|powershell.exe.config' is
installed in '0' by two different components on an LFN system:
'cmp_PSConfig_System32' and 'cmp_PSConfig_SysWOW64'. This breaks component
reference counting. C:\Dev\Core
Technologies\Main\Setup\Services_Setup_x64\Product.wxs  285 1
Services_Setup_x64


What the heck am I doing wrong?

thanks,

STeve



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Can-t-compile-Install-getting-ICE30-error-tp7589530.html
Sent from the wix-users mailing list archive at Nabble.com.

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register  
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Can't compile Install getting ICE30 error...

[Steven Ogilvie]

Well it compiles now but won't overwrite the file :(

How do I force a file to be overwritten when it is a system file...

I am adding .net 2.0 and 4.0 to the powershell.exe.config file so I can run a 
powershell script that requires .NET 4.0 (i.e. on Windows 2008R2 server)

Steve

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com] 
Sent: October-08-13 1:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Can't compile Install getting ICE30 error...

It is.  On my Server 2012 install, that is exactly how Windows place PowerShell 
3.0.  I have both x86 and x64 versions installed.

--
John Merryweather Cooper
Build  Install Engineer -- ESA
Jack Henry  Associates, Inc.(r)
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com




-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Tuesday, October 8, 2013 12:21 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Can't compile Install getting ICE30 error...

Or install to a common location this file, and utilize the CopyFile element to 
stick it in the destination based on bitness. I'm not 100% certain, but is it 
not possible to have both X86 and X64 versions of powershell on the same system?

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Tuesday, October 08, 2013 12:15 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Can't compile Install getting ICE30 error...

Solved it...

I created a customaction to populate a property with the powershell folder

CustomAction Id=CA_Set_PowerShellx86_Path Directory=POWERSHELLX86_DIR 
Value=[POWERSHELLPATH_X86]/
CustomAction Id=CA_Set_PowerShellx64_Path Directory=POWERSHELLX64_DIR 
Value=[POWERSHELLPATH_X64]/

I use the Directory property Directory=POWERSHELLX86_DIR as the directory 
for the component...

Sigh..

Steve

-Original Message-
From: StevenOgilvie [mailto:sogil...@msn.com]
Sent: October-08-13 1:05 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Can't compile Install getting ICE30 error...

Hi guys,

I am trying to install 1 file to 2 different locations by using 2 different 
directory elements, 2 different component elements and 2 different file 
elements.

Before I do this I have a custom action that copies the powershell.exe.config 
to powershell.exe.config.bak (I try both the system32 and the SysWOW64 
powershell folders.

Here is my WIX code for the file copy..

 Property Id=POWERSHELLPATH_X86 Value=0
  RegistrySearch Id=Find_POWERSHELLPATH_x86
  Type=directory
  Root=HKLM
 
Key=SOFTWARE\Wow6432Node\Microsoft\PowerShell\1\PowerShellEngine
  Name=ApplicationBase
  Win64=no/
/Property
Property Id=POWERSHELLPATH_X64 Value=0
  RegistrySearch Id=Find_POWERSHELLPATH_x64
  Type=directory
  Root=HKLM
  Key=SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine
  Name=ApplicationBase
  Win64=yes/
/Property

ComponentRef Id=cmp_PSConfig_System32/ ComponentRef 
Id=cmp_PSConfig_SysWOW64/

Directory Id=TARGETDIR Name=SourceDir

Directory Id=POWERSHELLPATH_X64 Name=PowerShell X64 DiskId=1
Component Id=cmp_PSConfig_System32
Guid={BC51F641-03C1-4477-9976-F464A61A3921} KeyPath=yes Permanent=yes
Shared=no
File Id=file_PSConfig_System32 Name=powershell.exe.config
Source=$(var.resourcePath)\powershell.exe.config /
/Component
  /Directory
  Directory Id=POWERSHELLPATH_X86 Name=PowerShell x86 DiskId=1
Component Id=cmp_PSConfig_SysWOW64
Guid={51F24D8C-FE09-4FEA-8F8D-5C645A3F9D40} KeyPath=yes Permanent=yes
Shared=no
File Id=file_PSConfig_SysWOW64 Name=powershell.exe.config
Source=$(var.resourcePath)\powershell.exe.config /
/Component
  /Directory

here are the two errors:

Error   13  ICE30: The target file 'j47lduzx.con|powershell.exe.config' is
installed in '0' by two different components on an LFN system:
'cmp_PSConfig_System32' and 'cmp_PSConfig_SysWOW64'. This breaks component
reference counting. C:\Dev\Core
Technologies\Main\Setup\Services_Setup_x64\Product.wxs  290 1
Services_Setup_x64
Error   14  ICE30: The target file 'j47lduzx.con|powershell.exe.config' is
installed in '0' by two different components on an LFN system:
'cmp_PSConfig_System32' and 'cmp_PSConfig_SysWOW64'. This breaks component
reference counting. C:\Dev\Core
Technologies\Main\Setup\Services_Setup_x64\Product.wxs  285 1
Services_Setup_x64


What the heck am I doing wrong?

thanks,

STeve



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Can-t-compile-Install-getting-ICE30-error-tp7589530.html
Sent from the wix-users mailing list

Re: [WiX-users] Can't compile Install getting ICE30 error...

[Steven Ogilvie]

The installer is not blowing anything away...

I have a custom action that first backs up any powershell.exe.config to .bak 
(both x86/x64) then I try to copy over the modified version over it is set as 
perm so it won't remove it

Steve

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] 
Sent: October-08-13 2:13 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Can't compile Install getting ICE30 error...

The more I think about this the more I think the right way is to try to 
modify the existing file (if it exists) using XmlFile/XmlConfig.  If the file 
doesn't exist, I would want to create an empty one and then have the custom 
actions run to modify it.

As an end user, I know I would be angry if I had a few other applications which 
politely modified the config, and then had your installer blow it away.

With that, I would have a bare minimum config file and a component condition on 
it to only install if the file doesn't exist.

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Tuesday, October 08, 2013 1:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Can't compile Install getting ICE30 error...

Well it compiles now but won't overwrite the file :(

How do I force a file to be overwritten when it is a system file...

I am adding .net 2.0 and 4.0 to the powershell.exe.config file so I can run a 
powershell script that requires .NET 4.0 (i.e. on Windows 2008R2 server)

Steve

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: October-08-13 1:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Can't compile Install getting ICE30 error...

It is.  On my Server 2012 install, that is exactly how Windows place PowerShell 
3.0.  I have both x86 and x64 versions installed.

--
John Merryweather Cooper
Build  Install Engineer -- ESA
Jack Henry  Associates, Inc.(r)
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com




-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Tuesday, October 8, 2013 12:21 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Can't compile Install getting ICE30 error...

Or install to a common location this file, and utilize the CopyFile element to 
stick it in the destination based on bitness. I'm not 100% certain, but is it 
not possible to have both X86 and X64 versions of powershell on the same system?

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Tuesday, October 08, 2013 12:15 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Can't compile Install getting ICE30 error...

Solved it...

I created a customaction to populate a property with the powershell folder

CustomAction Id=CA_Set_PowerShellx86_Path Directory=POWERSHELLX86_DIR 
Value=[POWERSHELLPATH_X86]/
CustomAction Id=CA_Set_PowerShellx64_Path Directory=POWERSHELLX64_DIR 
Value=[POWERSHELLPATH_X64]/

I use the Directory property Directory=POWERSHELLX86_DIR as the directory 
for the component...

Sigh..

Steve

-Original Message-
From: StevenOgilvie [mailto:sogil...@msn.com]
Sent: October-08-13 1:05 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Can't compile Install getting ICE30 error...

Hi guys,

I am trying to install 1 file to 2 different locations by using 2 different 
directory elements, 2 different component elements and 2 different file 
elements.

Before I do this I have a custom action that copies the powershell.exe.config 
to powershell.exe.config.bak (I try both the system32 and the SysWOW64 
powershell folders.

Here is my WIX code for the file copy..

 Property Id=POWERSHELLPATH_X86 Value=0
  RegistrySearch Id=Find_POWERSHELLPATH_x86
  Type=directory
  Root=HKLM
 
Key=SOFTWARE\Wow6432Node\Microsoft\PowerShell\1\PowerShellEngine
  Name=ApplicationBase
  Win64=no/
/Property
Property Id=POWERSHELLPATH_X64 Value=0
  RegistrySearch Id=Find_POWERSHELLPATH_x64
  Type=directory
  Root=HKLM
  Key=SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine
  Name=ApplicationBase
  Win64=yes/
/Property

ComponentRef Id=cmp_PSConfig_System32/ ComponentRef 
Id=cmp_PSConfig_SysWOW64/

Directory Id=TARGETDIR Name=SourceDir

Directory Id=POWERSHELLPATH_X64 Name=PowerShell X64 DiskId=1
Component Id=cmp_PSConfig_System32
Guid={BC51F641-03C1-4477-9976-F464A61A3921} KeyPath=yes Permanent=yes
Shared=no
File Id=file_PSConfig_System32 Name=powershell.exe.config
Source=$(var.resourcePath)\powershell.exe.config /
/Component
  /Directory
  Directory Id

Re: [WiX-users] Merge Module question...

[Steven Ogilvie]

Its annoying because the files will NEVER be installed on top of each other...

So you install the files to subfolders, then use DuplicateFile table to put the 
right files into the proper folder?

I looked at the DuplicateFile element but it didn't make any sense to me?

Do you have an example?

Thanks,

Steve


-Original Message-
From: Christopher Painter [mailto:chr...@iswix.com] 
Sent: September-24-13 5:22 PM
To: General discussion for Windows Installer XML toolset.; 
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Merge Module question...

It's a warning not an error.  The way I get around this is to set the Directory 
to subfolders like x86 and x64 and then use the DuplicateFile table to get the 
right file installed to the right directory.


 From: StevenOgilvie sogil...@msn.com
Sent: Tuesday, September 24, 2013 1:26 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Merge Module question...

I have added it back to 1 WIXLIB

when I compile it works but I get this error twice for each merge module:
Warning 22  ICE30: The target file 'kd1er3dy.dll|SQLite.Interop.dll' might 
be
installed in '[TARGETDIR]\EnterpriseAuditLogService\' by two different 
conditionalized components on an LFN system:
'cmp_SQLite.Interop_x86.9EFC3F5B_3D47_4233_A162_371DEF5D8E92' and 
'cmp_SQLite.Interop_x64.9EFC3F5B_3D47_4233_A162_371DEF5D8E92'. If the 
conditions are not mutually exclusive, this will break the component
reference counting system.  C:\Dev\Core
Technologies\Main\Setup\TitusServices\TitusSQLiteLib\Library.wxs18  
1
TitusEnterpriseAuditLogServicesMergeModule

each component (2 components each x 1 for x86 and 1 for x64)

i.e.

Component Id=cmp_SystemDataSQLite_x86 Guid={some GUID} File 
Id=file_SystemDataSQLite_x86 KeyPath=yes
Source=$(var.sourcePath)ThirdParty\SQLite\x86\System.Data.SQLite.dll / 
Condition ! [ CDATA [NOT Installed AND NOT VersionNT64 ] ]
/Condition
/Component
have to put spaces on the condition or nabble removes the whole line :( for x64 
take the NOT VersionNT64 to just VersionNT64

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Merge-Module-q
uestion-tp7589180p7589182.html
Sent from the wix-users mailing list archive at Nabble.com.


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register  
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk


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


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register  
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Merge Module question...

[Steven Ogilvie]

Sigh 4 warnings x 6 merge modules :(

Okay thanks all :)

Steve

-Original Message-
From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com] 
Sent: September-24-13 10:41 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module question...

On Tuesday, September 24, 2013, StevenOgilvie wrote:

 I have added it back to 1 WIXLIB

 when I compile it works but I get this error twice for each merge module:
 Warning 22  ICE30: The target file 'kd1er3dy.dll|SQLite.Interop.dll'
 might be
 installed in '[TARGETDIR]\EnterpriseAuditLogService\' by two different 
 conditionalized components on an LFN system:
 'cmp_SQLite.Interop_x86.9EFC3F5B_3D47_4233_A162_371DEF5D8E92' and 
 'cmp_SQLite.Interop_x64.9EFC3F5B_3D47_4233_A162_371DEF5D8E92'. If the 
 conditions are not mutually exclusive, this will break the component
 reference counting system.  C:\Dev\Core
 Technologies\Main\Setup\TitusServices\TitusSQLiteLib\Library.wxs18
  1
 TitusEnterpriseAuditLogServicesMergeModule


 each component (2 components each x 1 for x86 and 1 for x64)

 i.e.

 Component Id=cmp_SystemDataSQLite_x86 Guid={some GUID}
   File Id=file_SystemDataSQLite_x86 KeyPath=yes
 Source=$(var.sourcePath)ThirdParty\SQLite\x86\System.Data.SQLite.dll /
   Condition ! [ CDATA [NOT Installed AND NOT VersionNT64 ] 
 ]
 /Condition
 /Component
 have to put spaces on the condition or nabble removes the whole line 
 :( for x64 take the NOT VersionNT64 to just VersionNT64


It's not an error, it's a warning. As the message says, if the conditionals are 
not mutually exclusive, things will break. Your conditions *are* mutually 
exclusive, so there is no problem.

Adding Microsoft's Visual C++ Runtime merge modules to your MSI will trigger 
the same ICE, by the way; and it's safe there too.


--
Nicolás
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register  
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] install only on server 2012 and server 2008

[Steven Ogilvie]

Check out VersionNT and NTProductType (Google them to get the proper values for 
the two OS's you want)

-Original Message-
From: nkshirsagar [mailto:nkshirsa...@gmail.com] 
Sent: September-23-13 12:05 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] install only on server 2012 and server 2008

I know i need to use versionnt64, but how do I specifically limit the 
installation OS's to server 2012 and server 2008  R2 ? I dont want to allow 
installation on xp,vista,win7,win8, etc..




--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/install-only-on-server-2012-and-server-2008-tp7589112p7589142.html
Sent from the wix-users mailing list archive at Nabble.com.

--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes 
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Add text to final window in burn bootstrapper/installer

[Steven Ogilvie]

So it is not currently supported?

-Original Message-
From: Bruce Cran [mailto:br...@cran.org.uk] 
Sent: September-18-13 3:15 AM
To: General discussion for Windows Installer XML toolset.
Cc: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Add text to final window in burn bootstrapper/installer

That's another feature I'm hoping to implement: Burn should support 'Modifying' 
the installation, displaying the options page during maintenance.

--
Bruce

Sent from my iPhone

On 16 Sep 2013, at 15:59, Steven Ogilvie steven.ogil...@titus.com wrote:

 Did I send you updated code?
 
 Different question...
 
 If I have two check boxes, each one a different installer, if I install one, 
 how can I run the boostrapper again and choose to install the other?
 Currently it installs the 1 I have checked, run bootstrapper again and 
 it wants to uninstall :(
 
 Steve
 
 -Original Message-
 From: Neil Sleightholm [mailto:n...@x2systems.com]
 Sent: August-31-13 5:02 AM
 To: General discussion for Windows Installer XML toolset.
 Cc: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Add text to final window in burn 
 bootstrapper/installer
 
 If you like to post diff on the code plea site I'll add it to the extended 
 BA. 
 
 Neil
 
 On 30 Aug 2013, at 14:48, Steven Ogilvie steven.ogil...@titus.com wrote:
 
 No sorry
 
 I am not using 3.8 I am using 3.7 with the Extended BA from Neil
 
 -Original Message-
 From: Bruce Cran [mailto:br...@cran.org.uk]
 Sent: August-30-13 9:00 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Add text to final window in burn 
 bootstrapper/installer
 
 Do you have a diff (e.g. using 'git diff') you can attach?
 
 --
 Bruce
 
 Sent from my iPhone
 
 On 28 Aug 2013, at 18:29, Steven Ogilvie steven.ogil...@titus.com wrote:
 
 Here is the code from BA
 
 Theme wxl file
 String Id=SuccessHeaderSetup Successful/String  String 
 Id=SuccessSetupHeaderSetup Successful/String  String 
 Id=SuccessUninstallHeaderUninstall Successful/String
 
 String Id=FailureHeaderSetup Failed/String  String 
 Id=FailureSetupHeaderSetup Failed/String  String 
 Id=FailureUninstallHeaderUninstall Failed/String
 
 Theme xml file
 Page Name=Success
  Text Name=SuccessHeader X=11 Y=80 Width=-11 Height=30 
 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.SuccessHeader)/Text
  Text Name=SuccessSetupHeader X=11 Y=80 Width=-11 
 Height=30 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.SuccessSetupHeader)/Text
  Text Name=SuccessUninstallHeader X=11 Y=80 Width=-11 
 Height=30 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.SuccessUninstallHeader)/Text
 
 Page Name=Failure
  Text Name=FailureHeader X=11 Y=80 Width=-11 Height=30 
 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.FailureHeader)/Text
  Text Name=FailureSetupHeader X=11 Y=80 Width=-11 
 Height=30 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.FailureSetupHeader)/Text
  Text Name=FailureUninstallHeader X=11 Y=80 Width=-11 
 Height=30 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.FailureUninstallHeader)/Text
 
 WixStandardBootstrapperApplication.cpp
 
 // Success page
  WIXSTDBA_CONTROL_SUCCESS_HEADER,
  WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER,
  WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER,
 
 // Failure page
  WIXSTDBA_CONTROL_FAILURE_HEADER,
  WIXSTDBA_CONTROL_FAILURE_SETUP_HEADER,
  WIXSTDBA_CONTROL_FAILURE_UNINSTALL_HEADER,
 
 { WIXSTDBA_CONTROL_SUCCESS_HEADER, LSuccessHeader },  { 
 WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER, LSuccessSetupHeader },  { 
 WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER,
 LSuccessUninstallHeader },
 
 { WIXSTDBA_CONTROL_FAILURE_HEADER, LFailureHeader },  { 
 WIXSTDBA_CONTROL_FAILURE_SETUP_HEADER, LFailureSetupHeader },  { 
 WIXSTDBA_CONTROL_FAILURE_UNINSTALL_HEADER,
 LFailureUninstallHeader },
 
 In method OnChangeState:
 ..
 else if (m_rgdwPageIds[WIXSTDBA_PAGE_SUCCESS] == dwNewPageId) // on the 
 Success page, check if the restart or launch button should be enabled.
 ...
 // Set the header of the failure page to either Setup or Uninstall
  if (ThemeControlExists(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER))
  {
  ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER, BOOTSTRAPPER_ACTION_UNINSTALL  
 m_plannedAction);
  ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_HEADER, FALSE);
  }
  else
  {
  ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_HEADER, TRUE);
  }
  if (ThemeControlExists(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER))
  {
  ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER, BOOTSTRAPPER_ACTION_INSTALL  
 m_plannedAction);
  ThemeControlEnable(m_pTheme

Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

[Steven Ogilvie]

Alain,

One thing you have to remember, this is a FREE product.
It is not a full time job for the main developers, they do this on their 
spare time and other developers add stuff on their spare time as well.

Burn/Boostrapper was added in 3.6 (or was it 3.5) as add on tool for WIX and is 
an awesome tool.

Sure it has some pros and cons, but once again it is a FREE tool.

I have done some work on my own by using Neil Sleighthom's WixExtendedBA tool 
(which I hear has been incorporated into 3.8) I did this to make it a little 
more useful for me.
https://wixextba.codeplex.com/

Yes it took me a little while to grasp what the Extended BA is doing...

Steve

-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu] 
Sent: September-18-13 4:02 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

Which I think reinforces my point. It's not clear to me why it needs to take 
lots of time and effort just to suppress a UI, or make minor changes to an 
existing UI.

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Wednesday, September 18, 2013 15:58
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

It's not trivial to create a custom BA. It takes time and effort.


On Wed, Sep 18, 2013 at 12:51 PM, Alain Forget afor...@cmu.edu wrote:

 I don't mean compile and setup time. I mean time and effort for 
 someone completely unfamiliar with the WiX source and whatever may be 
 involved in rolling a custom bootstrapper (like myself and most other 
 people on here who ask how to do what doesn't seem like a complex request).

 Sure, for you and other WiX pros working on it for years, building the 
 code and rolling your own custom BA is trivial. But for the rest of us 
 non-WiX devs, especially those of us relatively new to it, it's far 
 from trivial, and it seems like a lot (read: too much) to learn and 
 figure out just a little UI change, like removing the UI, or adding a 
 field, checkbox, label, or window/wizard step.

 My point is that you might want to consider making WiX-built installers'
 UIs easier for developers to customise without having to crack open 
 and customise the source code (which I can only imagine can create 
 problems when trying to keep up with updates to the main code).

 Alain

 -Original Message-
 From: Rob Mensching [mailto:r...@robmensching.com]
 Sent: Wednesday, September 18, 2013 15:42
 To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

 On my 5 year old machine it takes 5 minutes to build all of the WiX 
 toolset source. That isn't *that* long is it? Seems like a reasonable 
 amount of time to build a project of our size. There is documentation 
 in the WiX.chm with instructions how to build.


 On Wed, Sep 18, 2013 at 12:29 PM, Alain Forget afor...@cmu.edu wrote:


 Is there a tutorial somewhere on where to get the stock BA's 
 source, and how to make various changes to it? The only tutorial I 
 found involved cracking open Visual Studio, and seemed to involve 
 recompiling the whole source and...yeah, a big hurdle to jump.



 -Original Message-
 From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com]
 Sent: Wednesday, September 18, 2013 15:25
 To: afor...@cmu.edu; General discussion for Windows Installer 
 XML toolset.

 Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be 
 UI-less?

 The stock BA is open source. You don't need to start from scratch,
 just modify the stock one.

 --
 Nicolás

 2013/9/18 Alain Forget afor...@cmu.edu:
  It just seems like going from the stock BA to rolling your 
 own custom BA just to either get rid of the UI or add a single text 
 box, radio button, or window/step seems extremely costly in time and 
 effort for what seems like a minor modification.
 
  -Original Message-
  From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
  Sent: Wednesday, September 18, 2013 12:40
  To: afor...@cmu.edu; General discussion for Windows 
 Installer XML toolset.
  Subject: RE: [WiX-users] [SPAM] Re: Bootstrapper -- Can it 
 be UI-less?
 
I believe the mantra is don't use installer UI's, use a BA UI.
  As such, if you need a custom UI then generate a BA to give the look 
 and feel that you want.  The reasoning behind having a BA UI is so you 
 can have a single unified installation experience. Having a chain of 5 
 MSI's all exposing their own UI's would result in a choppy and subpar user 
 experience.
 
That being said, WiX is open source, so anyone is free to
 contribute enhancements.
 
  -Original Message-
  From: 

Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

[Steven Ogilvie]

Alain,

You can't expect someone to hold your hand!

You have to dive in, figure out the code, and try to add some stuff to it, 
trial and error, and by doing this you are gaining knowledge on how the code 
works...

As Wesley stated you can change minor things by the theme wxl/xml files

But what you are suggesting is NOT minor, it is a major code change...

Once again for checkboxes/radio buttons etc.. check out Neil's extended BA I 
have already included his codeplex link

Steve



-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu] 
Sent: September-18-13 4:35 PM
To: 'Wesley Manning'; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

Minor changes = adding a text field, a check box, a window in the wizard steps, 
something like that. I never figured out how to do that without needing a 
custom BA, at which point, I gave up (thankfully, because apparently it's very 
time and effort intensive!).

-Original Message-
From: Wesley Manning [mailto:wmann...@dynagen.ca]
Sent: Wednesday, September 18, 2013 16:22
To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

What do you mean by minor changes?  I do that using the stdba by changing the 
templates.   But my minor changes are adding graphics, adding installer 
version, changing text size, etc.

-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: September-18-13 5:02 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

Which I think reinforces my point. It's not clear to me why it needs to take 
lots of time and effort just to suppress a UI, or make minor changes to an 
existing UI.

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Wednesday, September 18, 2013 15:58
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

It's not trivial to create a custom BA. It takes time and effort.


On Wed, Sep 18, 2013 at 12:51 PM, Alain Forget afor...@cmu.edu wrote:

 I don't mean compile and setup time. I mean time and effort for 
 someone completely unfamiliar with the WiX source and whatever may be 
 involved in rolling a custom bootstrapper (like myself and most other 
 people on here who ask how to do what doesn't seem like a complex request).

 Sure, for you and other WiX pros working on it for years, building the 
 code and rolling your own custom BA is trivial. But for the rest of us 
 non-WiX devs, especially those of us relatively new to it, it's far 
 from trivial, and it seems like a lot (read: too much) to learn and 
 figure out just a little UI change, like removing the UI, or adding a 
 field, checkbox, label, or window/wizard step.

 My point is that you might want to consider making WiX-built installers'
 UIs easier for developers to customise without having to crack open 
 and customise the source code (which I can only imagine can create 
 problems when trying to keep up with updates to the main code).

 Alain

 -Original Message-
 From: Rob Mensching [mailto:r...@robmensching.com]
 Sent: Wednesday, September 18, 2013 15:42
 To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

 On my 5 year old machine it takes 5 minutes to build all of the WiX 
 toolset source. That isn't *that* long is it? Seems like a reasonable 
 amount of time to build a project of our size. There is documentation 
 in the WiX.chm with instructions how to build.


 On Wed, Sep 18, 2013 at 12:29 PM, Alain Forget afor...@cmu.edu wrote:


 Is there a tutorial somewhere on where to get the stock BA's 
 source, and how to make various changes to it? The only tutorial I 
 found involved cracking open Visual Studio, and seemed to involve 
 recompiling the whole source and...yeah, a big hurdle to jump.



 -Original Message-
 From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com]
 Sent: Wednesday, September 18, 2013 15:25
 To: afor...@cmu.edu; General discussion for Windows Installer 
 XML toolset.

 Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be 
 UI-less?

 The stock BA is open source. You don't need to start from scratch,
 just modify the stock one.

 --
 Nicolás

 2013/9/18 Alain Forget afor...@cmu.edu:
  It just seems like going from the stock BA to rolling your 
 own custom BA just to either get rid of the UI or add a single text 
 box, radio button, or window/step seems extremely costly in time and 
 effort for what seems like a minor modification.
 
  -Original Message-
  From: Hoover, Jacob 

Re: [WiX-users] ** SPAM ** [SPAM] Re: [SPAM] Re: Bootstrapper -- Can it be UI-less?

[Steven Ogilvie]

Awesome Rob, I logged that Internal MSI UI and the progress not moving bug, 
glad its fixed I will look forward to 3.8 :)

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: September-18-13 4:41 PM
To: General discussion for Windows Installer XML toolset.
Subject: ** SPAM **[WiX-users] [SPAM] Re: [SPAM] Re: Bootstrapper -- Can it be 
UI-less?

Note: I don't know that all the developers on the WiX toolset believe that Burn 
based installs should display single unified UI by suppressing internal MSI UI, 
but I do.

However, Burn certainly supports showing internal MSI UI. In fact, in
v3.8 FireGiant found and fixed a bug related to showing progress during 
internal MSI UI (
https://wix.codeplex.com/SourceControl/network/forks/firegiant/dev/contribution/5197
).


On Wed, Sep 18, 2013 at 1:24 PM, Nicolás Alvarez
nicolas.alva...@gmail.comwrote:

 As far as I know, suppressing the Burn UI and using only the MSI UI is 
 not how Burn is *supposed* to be used. Why would the WiX developers 
 spend time and effort to make it easier to use in that way?

 --
 Nicolás

 2013/9/18 Alain Forget afor...@cmu.edu:
  Which I think reinforces my point. It's not clear to me why it needs 
  to
 take lots of time and effort just to suppress a UI, or make minor 
 changes to an existing UI.
 
  -Original Message-
  From: Rob Mensching [mailto:r...@robmensching.com]
  Sent: Wednesday, September 18, 2013 15:58
  To: General discussion for Windows Installer XML toolset.
  Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?
 
  It's not trivial to create a custom BA. It takes time and effort.
 
 
  On Wed, Sep 18, 2013 at 12:51 PM, Alain Forget afor...@cmu.edu wrote:
 
  I don't mean compile and setup time. I mean time and effort for 
  someone completely unfamiliar with the WiX source and whatever may 
  be involved
 in
  rolling a custom bootstrapper (like myself and most other people on 
  here who ask how to do what doesn't seem like a complex request).
 
  Sure, for you and other WiX pros working on it for years, building 
  the code and rolling your own custom BA is trivial. But for the 
  rest of us non-WiX devs, especially those of us relatively new to 
  it, it's far from trivial, and it seems like a lot (read: too much) 
  to learn and figure
 out
  just a little UI change, like removing the UI, or adding a field,
 checkbox,
  label, or window/wizard step.
 
  My point is that you might want to consider making WiX-built installers'
  UIs easier for developers to customise without having to crack open 
  and customise the source code (which I can only imagine can create 
  problems when trying to keep up with updates to the main code).
 
  Alain
 
  -Original Message-
  From: Rob Mensching [mailto:r...@robmensching.com]
  Sent: Wednesday, September 18, 2013 15:42
  To: afor...@cmu.edu; General discussion for Windows Installer XML
 toolset.
  Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?
 
  On my 5 year old machine it takes 5 minutes to build all of the WiX 
  toolset source. That isn't *that* long is it? Seems like a 
  reasonable amount of time to build a project of our size. There is 
  documentation in the WiX.chm with instructions how to build.
 
 
  On Wed, Sep 18, 2013 at 12:29 PM, Alain Forget afor...@cmu.edu wrote:
 
 
  Is there a tutorial somewhere on where to get the stock 
  BA's source, and how to make various changes to it? The only 
  tutorial I found involved cracking open Visual Studio, and seemed 
  to involve recompiling
 the
  whole source and...yeah, a big hurdle to jump.


 --
  LIMITED TIME SALE - Full Year of Microsoft Training For Just 
 $49.99!
 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, 
 SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library 
 Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price 
 ever! Ends 9/20/13.
 http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.c
 lktrk ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes 
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
LIMITED TIME SALE - Full Year of Microsoft 

Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

[Steven Ogilvie]

I was able to add checkboxes/radiobuttons on Welcome Page, then fool 
WixExtendedBA to think the Options button was Next and the options page to 
be the rich text EULA page, so I have 2 pages now... select the product to 
install, click next agree to the EULA and click Install, most of that was 
through the theme files :)

Steve

-Original Message-
From: Wesley Manning [mailto:wmann...@dynagen.ca] 
Sent: September-18-13 4:49 PM
To: afor...@cmu.edu; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

You can do a text field/check box using Niel's wixstba if using 3.7, it's in 
3.8 I believe.  A new window needs a custom BA.  

-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: September-18-13 5:35 PM
To: Wesley Manning; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

Minor changes = adding a text field, a check box, a window in the wizard steps, 
something like that. I never figured out how to do that without needing a 
custom BA, at which point, I gave up (thankfully, because apparently it's very 
time and effort intensive!).

-Original Message-
From: Wesley Manning [mailto:wmann...@dynagen.ca]
Sent: Wednesday, September 18, 2013 16:22
To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

What do you mean by minor changes?  I do that using the stdba by changing the 
templates.   But my minor changes are adding graphics, adding installer 
version, changing text size, etc.

-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: September-18-13 5:02 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

Which I think reinforces my point. It's not clear to me why it needs to take 
lots of time and effort just to suppress a UI, or make minor changes to an 
existing UI.

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Wednesday, September 18, 2013 15:58
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

It's not trivial to create a custom BA. It takes time and effort.


On Wed, Sep 18, 2013 at 12:51 PM, Alain Forget afor...@cmu.edu wrote:

 I don't mean compile and setup time. I mean time and effort for 
 someone completely unfamiliar with the WiX source and whatever may be 
 involved in rolling a custom bootstrapper (like myself and most other 
 people on here who ask how to do what doesn't seem like a complex request).

 Sure, for you and other WiX pros working on it for years, building the 
 code and rolling your own custom BA is trivial. But for the rest of us 
 non-WiX devs, especially those of us relatively new to it, it's far 
 from trivial, and it seems like a lot (read: too much) to learn and 
 figure out just a little UI change, like removing the UI, or adding a 
 field, checkbox, label, or window/wizard step.

 My point is that you might want to consider making WiX-built installers'
 UIs easier for developers to customise without having to crack open 
 and customise the source code (which I can only imagine can create 
 problems when trying to keep up with updates to the main code).

 Alain

 -Original Message-
 From: Rob Mensching [mailto:r...@robmensching.com]
 Sent: Wednesday, September 18, 2013 15:42
 To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

 On my 5 year old machine it takes 5 minutes to build all of the WiX 
 toolset source. That isn't *that* long is it? Seems like a reasonable 
 amount of time to build a project of our size. There is documentation 
 in the WiX.chm with instructions how to build.


 On Wed, Sep 18, 2013 at 12:29 PM, Alain Forget afor...@cmu.edu wrote:


 Is there a tutorial somewhere on where to get the stock BA's 
 source, and how to make various changes to it? The only tutorial I 
 found involved cracking open Visual Studio, and seemed to involve 
 recompiling the whole source and...yeah, a big hurdle to jump.



 -Original Message-
 From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com]
 Sent: Wednesday, September 18, 2013 15:25
 To: afor...@cmu.edu; General discussion for Windows Installer 
 XML toolset.

 Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be 
 UI-less?

 The stock BA is open source. You don't need to start from scratch,
 just modify the stock one.

 --
 Nicolás

 2013/9/18 Alain Forget afor...@cmu.edu:
  It just seems like going from the stock BA to rolling your 
 own custom BA just to either get rid of the UI or add a single text 
 

Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

[Steven Ogilvie]

I am using Neil's WixExtendedBA which is not part of Wix 3.7 (it is in Wix 3.8)

You can get it from: https://wixextba.codeplex.com/ for this you need to 
customize your theme files xml/wxl
i.e.
HyperLinkTheme.xml
  Page Name=Install
Text X=11 Y=80 Width=-11 Height=30 FontId=2 
DisablePrefix=yes#(loc.InstallHeader)/Text
Text X=11 Y=-11 Width=-11 Height=-129 FontId=3 
DisablePrefix=yes#(loc.InstallMessage)/Text
!-- BS_AUTORADIOBUTTON - HexStyle=0x09 --
Button Name=RadioButton1 X=120 Y=170 Width=-11 Height=17 
TabStop=yes FontId=3 HideWhenDisabled=no 
HexStyle=0x09#(loc.InstallRadioButton1)/Button
Button Name=RadioButton2 X=120 Y=190 Width=-11 Height=17 
TabStop=yes FontId=3 HideWhenDisabled=no 
HexStyle=0x09#(loc.InstallRadioButton2)/Button
Button Name=RadioButton3 X=120 Y=210 Width=-11 Height=17 
TabStop=yes FontId=3 HideWhenDisabled=no 
HexStyle=0x09#(loc.InstallRadioButton3)/Button
Hypertext Name=EulaHyperlink X=11 Y=260 Width=-11 Height=17 
TabStop=yes FontId=3 
HideWhenDisabled=yes#(loc.InstallLicenseLinkText)/Hypertext
Checkbox Name=EulaAcceptCheckbox X=11 Y=280 Width=246 Height=17 
TabStop=yes FontId=3 
HideWhenDisabled=yes#(loc.InstallAcceptCheckbox)/Checkbox
Text X=11 Y=-11 Width=246 Height=17 FontId=3 
DisablePrefix=yes#(loc.InstallVersion)/Text
Hypertext Name=UpgradeHyperlink X=11 Y=-73 Width=-11 Height=17 
TabStop=yes FontId=3 
HideWhenDisabled=yes#(loc.InstallUpgradeLinkText)/Hypertext
Button Name=OptionsButton X=-171 Y=-11 Width=75 Height=23 
TabStop=yes FontId=0 
HideWhenDisabled=yes#(loc.InstallOptionsButton)/Button
Button Name=InstallButton X=-91 Y=-11 Width=75 Height=23 
TabStop=yes FontId=0#(loc.InstallInstallButton)/Button
Button Name=WelcomeCancelButton X=-11 Y=-11 Width=75 Height=23 
TabStop=yes FontId=0#(loc.InstallCloseButton)/Button

Bundle.wxs
WixVariable Id=WixExtbaThemeXml Value=$(var.SolutionDir)HyperlinkTheme.xml 
/
  WixVariable Id=WixExtbaThemeWxl 
Value=$(var.SolutionDir)HyperlinkTheme_Enterprise.wxl /

And has info here on how to customize UI: 
http://neilsleightholm.blogspot.co.uk/2008/08/customised-uis-for-wix.html


-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu] 
Sent: September-18-13 5:00 PM
To: Steven Ogilvie; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

Wow, what black magic is this? :-P Somehow I completely failed to do something 
similar in the theme files a few weeks ago. If I need to tackle it again, I 
hope you won't mind if I ask for advice.

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Wednesday, September 18, 2013 16:55
To: General discussion for Windows Installer XML toolset.; afor...@cmu.edu
Subject: RE: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

I was able to add checkboxes/radiobuttons on Welcome Page, then fool 
WixExtendedBA to think the Options button was Next and the options page to 
be the rich text EULA page, so I have 2 pages now... select the product to 
install, click next agree to the EULA and click Install, most of that was 
through the theme files :)

Steve

-Original Message-
From: Wesley Manning [mailto:wmann...@dynagen.ca]
Sent: September-18-13 4:49 PM
To: afor...@cmu.edu; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

You can do a text field/check box using Niel's wixstba if using 3.7, it's in 
3.8 I believe.  A new window needs a custom BA.  

-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: September-18-13 5:35 PM
To: Wesley Manning; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

Minor changes = adding a text field, a check box, a window in the wizard steps, 
something like that. I never figured out how to do that without needing a 
custom BA, at which point, I gave up (thankfully, because apparently it's very 
time and effort intensive!).

-Original Message-
From: Wesley Manning [mailto:wmann...@dynagen.ca]
Sent: Wednesday, September 18, 2013 16:22
To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

What do you mean by minor changes?  I do that using the stdba by changing the 
templates.   But my minor changes are adding graphics, adding installer 
version, changing text size, etc.

-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: September-18-13 5:02 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

Which I think reinforces my point. It's not clear to me why it needs to take 
lots of time and effort just to suppress a UI, or make minor changes to an 
existing UI.

-Original Message-
From

Re: [WiX-users] Add text to final window in burn bootstrapper/installer

[Steven Ogilvie]

Did I send you updated code?

Different question...

If I have two check boxes, each one a different installer, if I install one, 
how can I run the boostrapper again and choose to install the other?
Currently it installs the 1 I have checked, run bootstrapper again and it wants 
to uninstall :(

Steve

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com] 
Sent: August-31-13 5:02 AM
To: General discussion for Windows Installer XML toolset.
Cc: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Add text to final window in burn bootstrapper/installer

If you like to post diff on the code plea site I'll add it to the extended BA. 

Neil

On 30 Aug 2013, at 14:48, Steven Ogilvie steven.ogil...@titus.com wrote:

 No sorry
 
 I am not using 3.8 I am using 3.7 with the Extended BA from Neil
 
 -Original Message-
 From: Bruce Cran [mailto:br...@cran.org.uk]
 Sent: August-30-13 9:00 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Add text to final window in burn 
 bootstrapper/installer
 
 Do you have a diff (e.g. using 'git diff') you can attach?
 
 --
 Bruce
 
 Sent from my iPhone
 
 On 28 Aug 2013, at 18:29, Steven Ogilvie steven.ogil...@titus.com wrote:
 
 Here is the code from BA
 
 Theme wxl file
 String Id=SuccessHeaderSetup Successful/String  String 
 Id=SuccessSetupHeaderSetup Successful/String  String 
 Id=SuccessUninstallHeaderUninstall Successful/String
 
 String Id=FailureHeaderSetup Failed/String  String 
 Id=FailureSetupHeaderSetup Failed/String  String 
 Id=FailureUninstallHeaderUninstall Failed/String
 
 Theme xml file
 Page Name=Success
   Text Name=SuccessHeader X=11 Y=80 Width=-11 Height=30 
 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.SuccessHeader)/Text
   Text Name=SuccessSetupHeader X=11 Y=80 Width=-11 Height=30 
 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.SuccessSetupHeader)/Text
   Text Name=SuccessUninstallHeader X=11 Y=80 Width=-11 
 Height=30 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.SuccessUninstallHeader)/Text
 
 Page Name=Failure
   Text Name=FailureHeader X=11 Y=80 Width=-11 Height=30 
 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.FailureHeader)/Text
   Text Name=FailureSetupHeader X=11 Y=80 Width=-11 Height=30 
 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.FailureSetupHeader)/Text
   Text Name=FailureUninstallHeader X=11 Y=80 Width=-11 
 Height=30 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.FailureUninstallHeader)/Text
 
 WixStandardBootstrapperApplication.cpp
 
 // Success page
   WIXSTDBA_CONTROL_SUCCESS_HEADER,
   WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER,
   WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER,
 
 // Failure page
   WIXSTDBA_CONTROL_FAILURE_HEADER,
   WIXSTDBA_CONTROL_FAILURE_SETUP_HEADER,
   WIXSTDBA_CONTROL_FAILURE_UNINSTALL_HEADER,
 
 { WIXSTDBA_CONTROL_SUCCESS_HEADER, LSuccessHeader },
   { WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER, LSuccessSetupHeader },
   { WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER,
 LSuccessUninstallHeader },
 
 { WIXSTDBA_CONTROL_FAILURE_HEADER, LFailureHeader },
   { WIXSTDBA_CONTROL_FAILURE_SETUP_HEADER, LFailureSetupHeader },
   { WIXSTDBA_CONTROL_FAILURE_UNINSTALL_HEADER,
 LFailureUninstallHeader },
 
 In method OnChangeState:
 ..
 else if (m_rgdwPageIds[WIXSTDBA_PAGE_SUCCESS] == dwNewPageId) // on the 
 Success page, check if the restart or launch button should be enabled.
 ...
 // Set the header of the failure page to either Setup or Uninstall
   if (ThemeControlExists(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER))
   {
   ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER, BOOTSTRAPPER_ACTION_UNINSTALL  
 m_plannedAction);
   ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_HEADER, FALSE);
   }
   else
   {
   ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_HEADER, TRUE);
   }
   if (ThemeControlExists(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER))
   {
   ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER, BOOTSTRAPPER_ACTION_INSTALL  
 m_plannedAction);
   ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_HEADER, FALSE);
   }
   else
   {
   ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_HEADER, TRUE);
   }
 ...
 else if (m_rgdwPageIds[WIXSTDBA_PAGE_FAILURE] == dwNewPageId) // on the 
 Failure page, show error message and check if the restart button should be 
 enabled.
 ...
 // Set the header of the failure page to either Setup or Uninstall
   if (ThemeControlExists(m_pTheme, 
 WIXSTDBA_CONTROL_FAILURE_SETUP_HEADER

Re: [WiX-users] Custom Action, feature condition and silent install

[Steven Ogilvie]

Have you tried After CostFinalize

-Original Message-
From: Ralph [mailto:ralph.gu...@racelogic.co.uk] 
Sent: September-12-13 10:17 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Custom Action, feature condition and silent install

I have a custom action which detects the version of some installed third party 
library and assigns the version to some property.  Then I have a condition 
reading that property to enable or disable a feature.
If I put the custom action into InstallUISequence it works very well with the 
UI, but does not work in silent mode, because no InstallUISequence is executed.
I found a few similar issues discussed on this forum and the advice was to move 
the custom action to InstallExecuteSequence.  My question is: where exactly?  
If I write Before=LaunchConditions the custom action has no influence on the 
feature.

The code looks like this:




--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Action-feature-condition-and-silent-install-tp7588916.html
Sent from the wix-users mailing list archive at Nabble.com.

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT 2. 
Standardize and globalize service processes across IT 3. Implement zero-touch 
automation to replace manual, redundant tasks 
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Custom Action, feature condition and silent install

[Steven Ogilvie]

What does your log file say?

-Original Message-
From: Ralph [mailto:ralph.gu...@racelogic.co.uk] 
Sent: September-12-13 10:38 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Custom Action, feature condition and silent install

Steven Ogilvie wrote
 Have you tried After CostFinalize

Unfortunately it doesn't work either...




--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Action-feature-condition-and-silent-install-tp7588916p7588918.html
Sent from the wix-users mailing list archive at Nabble.com.

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT 2. 
Standardize and globalize service processes across IT 3. Implement zero-touch 
automation to replace manual, redundant tasks 
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Custom Action, feature condition and silent install

[Steven Ogilvie]

Turn logging on: Property Id=MsiLogging Value=voicewarmupx/

Run your MSI and look for CostFinalize and then check to see if the custom 
action is being properly run and that your MSI property is being set...



-Original Message-
From: Ralph [mailto:ralph.gu...@racelogic.co.uk] 
Sent: September-12-13 10:38 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Custom Action, feature condition and silent install

Steven Ogilvie wrote
 Have you tried After CostFinalize

Unfortunately it doesn't work either...




--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Action-feature-condition-and-silent-install-tp7588916p7588918.html
Sent from the wix-users mailing list archive at Nabble.com.

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT 2. 
Standardize and globalize service processes across IT 3. Implement zero-touch 
automation to replace manual, redundant tasks 
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Custom Action, feature condition and silent install

[Steven Ogilvie]

Okay lets get more info :)

Are you running this in a merge module or within the product.wxs file?
What does your code for the customaction look like please?

So the custom action and the installexecutesequence as well

Steve

-Original Message-
From: Ralph [mailto:ralph.gu...@racelogic.co.uk] 
Sent: September-12-13 11:44 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Custom Action, feature condition and silent install

No custom action is executed and no property is set:

Action start 16:32:54: CostFinalize.
MSI (s) (A0:CC) [16:32:54:363]: Doing action: InstallValidate MSI (s) (A0:CC) 
[16:32:54:363]: Note: 1: 2205 2:  3: ActionText Action ended 16:32:54: 
CostFinalize. Return value 1.
MSI (s) (A0:CC) [16:32:54:364]: PROPERTY CHANGE: Deleting 
MsiRestartManagerSessionKey property. Its current value is 
'03e76f63926bb84db170df7f84ed9635'.
MSI (s) (A0:CC) [16:32:54:364]: Feature: ABC; Installed: Absent;   Request:
Null;   Action: Null
...






--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Action-feature-condition-and-silent-install-tp7588916p7588924.html
Sent from the wix-users mailing list archive at Nabble.com.

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] help! How do I launch a file upon install ?

[Steven Ogilvie]

If you follow the example on that web url it should work for you...

You can just add the:
!-- Step 2: Add UI to your installer / Step 4: Trigger the custom action --
UI
UIRef Id=WixUI_Minimal /
Publish Dialog=ExitDialog 
Control=Finish 
Event=DoAction 
Value=LaunchApplicationWIXUI_EXITDIALOGOPTIONALCHECKBOX = 1 and 
NOT Installed/Publish
/UI

That must be within your Product element...

Follow the example and it should work :)

Steve

-Original Message-
From: nkshirsagar [mailto:nkshirsa...@gmail.com] 
Sent: September-04-13 2:28 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] help! How do I launch a file upon install ?

Hello folks..

I've looked at
http://wixtoolset.org/documentation/manual/v3/howtos/ui_and_localization/run_program_after_install.html
 

to see the proper way to launch an exe that I'm installing after the user 
clicks the finish button. I've used the minimal gui, but added it as a 
reference by right-clicking the references in the wix project in visual 
studio, so I don't have a 

UI
UIRef Id=WixUI_Minimal /
/UI

element in my wxs file. 

So where do I add this code ? 

Publish Dialog=ExitDialog
Control=Finish 
Event=DoAction 
Value=LaunchApplicationWIXUI_EXITDIALOGOPTIONALCHECKBOX = 1 and NOT 
Installed/Publish

The tutorial suggest I add it anywhere in the UI element, but as I've added 
the UI element as a reference through visual studio, I don't have it in my wxs 
file! Would really appreciate someone's help on this as I've been stuck here 
for quite some time, and I'm very new to wix !



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/help-How-do-I-launch-a-file-upon-install-tp7588736.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies and 
advance your career. Get an incredible 1,500+ hours of step-by-step tutorial 
videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Add text to final window in burn bootstrapper/installer

[Steven Ogilvie]

No sorry

I am not using 3.8 I am using 3.7 with the Extended BA from Neil

-Original Message-
From: Bruce Cran [mailto:br...@cran.org.uk] 
Sent: August-30-13 9:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Add text to final window in burn bootstrapper/installer

Do you have a diff (e.g. using 'git diff') you can attach?

--
Bruce

Sent from my iPhone

On 28 Aug 2013, at 18:29, Steven Ogilvie steven.ogil...@titus.com wrote:

 Here is the code from BA
 
 Theme wxl file
 String Id=SuccessHeaderSetup Successful/String  String 
 Id=SuccessSetupHeaderSetup Successful/String  String 
 Id=SuccessUninstallHeaderUninstall Successful/String
 
 String Id=FailureHeaderSetup Failed/String  String 
 Id=FailureSetupHeaderSetup Failed/String  String 
 Id=FailureUninstallHeaderUninstall Failed/String
 
 Theme xml file
  Page Name=Success
Text Name=SuccessHeader X=11 Y=80 Width=-11 Height=30 
 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.SuccessHeader)/Text
Text Name=SuccessSetupHeader X=11 Y=80 Width=-11 Height=30 
 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.SuccessSetupHeader)/Text
Text Name=SuccessUninstallHeader X=11 Y=80 Width=-11 
 Height=30 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.SuccessUninstallHeader)/Text
 
  Page Name=Failure
Text Name=FailureHeader X=11 Y=80 Width=-11 Height=30 
 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.FailureHeader)/Text
Text Name=FailureSetupHeader X=11 Y=80 Width=-11 Height=30 
 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.FailureSetupHeader)/Text
Text Name=FailureUninstallHeader X=11 Y=80 Width=-11 
 Height=30 FontId=2 HideWhenDisabled=yes 
 DisablePrefix=yes#(loc.FailureUninstallHeader)/Text
 
 WixStandardBootstrapperApplication.cpp
 
 // Success page
WIXSTDBA_CONTROL_SUCCESS_HEADER,
WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER,
WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER,
 
 // Failure page
WIXSTDBA_CONTROL_FAILURE_HEADER,
WIXSTDBA_CONTROL_FAILURE_SETUP_HEADER,
WIXSTDBA_CONTROL_FAILURE_UNINSTALL_HEADER,
 
 { WIXSTDBA_CONTROL_SUCCESS_HEADER, LSuccessHeader },
{ WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER, LSuccessSetupHeader },
{ WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER, 
 LSuccessUninstallHeader },
 
 { WIXSTDBA_CONTROL_FAILURE_HEADER, LFailureHeader },
{ WIXSTDBA_CONTROL_FAILURE_SETUP_HEADER, LFailureSetupHeader },
{ WIXSTDBA_CONTROL_FAILURE_UNINSTALL_HEADER, 
 LFailureUninstallHeader },
 
 In method OnChangeState:
 ..
 else if (m_rgdwPageIds[WIXSTDBA_PAGE_SUCCESS] == dwNewPageId) // on the 
 Success page, check if the restart or launch button should be enabled.
 ...
 // Set the header of the failure page to either Setup or Uninstall
if (ThemeControlExists(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER))
{
ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER, BOOTSTRAPPER_ACTION_UNINSTALL  
 m_plannedAction);
ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_HEADER, FALSE);
}
else
{
ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_HEADER, TRUE);
}
if (ThemeControlExists(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER))
{
ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER, BOOTSTRAPPER_ACTION_INSTALL  
 m_plannedAction);
ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_HEADER, FALSE);
}
else
{
ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_SUCCESS_HEADER, TRUE);
}
 ...
 else if (m_rgdwPageIds[WIXSTDBA_PAGE_FAILURE] == dwNewPageId) // on the 
 Failure page, show error message and check if the restart button should be 
 enabled.
 ...
 // Set the header of the failure page to either Setup or Uninstall
if (ThemeControlExists(m_pTheme, 
 WIXSTDBA_CONTROL_FAILURE_SETUP_HEADER))
{
ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_FAILURE_SETUP_HEADER, BOOTSTRAPPER_ACTION_UNINSTALL  
 m_plannedAction);
ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_FAILURE_HEADER, FALSE);
}
else
{
ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_FAILURE_HEADER, TRUE);
}
if (ThemeControlExists(m_pTheme, 
 WIXSTDBA_CONTROL_FAILURE_UNINSTALL_HEADER))
{
ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_FAILURE_UNINSTALL_HEADER, BOOTSTRAPPER_ACTION_INSTALL  
 m_plannedAction);
ThemeControlEnable(m_pTheme, 
 WIXSTDBA_CONTROL_FAILURE_HEADER

Re: [WiX-users] Add text to final window in burn bootstrapper/installer

[Steven Ogilvie]

Yes exactly

BA is using the same property for Setup/Uninstall for the success/failure string

I fixed this by changing the code in BA and adding a few extra string 
properties in the theme wxl file
String Id=SuccessHeaderSetup Successful/String
  String Id=SuccessSetupHeaderSetup Successful/String
  String Id=SuccessUninstallHeaderUninstall Successful/String
String Id=FailureHeaderSetup Failed/String
  String Id=FailureSetupHeaderSetup Failed/String
  String Id=FailureUninstallHeaderUninstall Failed/String

BA:

{ WIXSTDBA_CONTROL_SUCCESS_HEADER, LSuccessHeader },
{ WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER, LSuccessSetupHeader },
{ WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER, LSuccessUninstallHeader },

{ WIXSTDBA_CONTROL_FAILURE_HEADER, LFailureHeader },
{ WIXSTDBA_CONTROL_FAILURE_SETUP_HEADER, LFailureSetupHeader },
{ WIXSTDBA_CONTROL_FAILURE_UNINSTALL_HEADER, LFailureUninstallHeader },

The in OnChangeState is where I set the correct string


-Original Message-
From: Bruce Cran [mailto:br...@cran.org.uk] 
Sent: August-28-13 2:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Add text to final window in burn bootstrapper/installer

On 28/08/2013 06:07, Blair Murri wrote:
 As I understand it, page Success will be shown whenever the result of 
 bundle application is successful but not when a failure occurs (when instead 
 the Failure page will be shown). So, successful install, successful 
 removal, successful modification, etc.
 If you can set bundle properties you can use that property's value as your 
 text, maybe...

There was a discussion on wix-devs about this a few months ago: the WixStdBA 
bootstrapper needs changed to allow better text on the 'success' pages.  In 
particular, people have complained to me about the fact that when uninstall 
completes it reports Setup Success.

--
Bruce Cran

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies and 
advance your career. Get an incredible 1,500+ hours of step-by-step tutorial 
videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Setting a value XmlConfig

[Steven Ogilvie]

I am using a custom action for that (I set mine to false) however after our 
product was released I saw this post:

http://stackoverflow.com/questions/11687870/wix-installer-always-changes-apppool-to-enable-32bit-app

below is my custom action just in case...

[CustomAction]
public static ActionResult Enable32BitApplicationPool(Session session)
{
try
{
if (session == null)
{
throw new ArgumentNullException(session);
}

var tempString = GetSessionProperty(session, 
CustomActionData, false);
var parts = tempString.Split(new[] { '|' });
var applicationPool = parts[0];
const string Quote = \;
var cmdLineParameters = set apppool /apppool.name: + Quote + 
applicationPool + Quote +  /enable32BitAppOnWin64:false;

var cmdLineExe = 
Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.System), 
inetsrv\\appcmd.exe);

// Prepare the process to run
var startInfo = new ProcessStartInfo
{
UseShellExecute = true,
Arguments = cmdLineParameters,
FileName = cmdLineExe,
WindowStyle = ProcessWindowStyle.Hidden,
CreateNoWindow = true
};

// Run the external process  wait for it to finish
using (Process proc = Process.Start(startInfo))
{
proc.WaitForExit();
}
}
catch (Exception ex)
{
WriteErrorLogInstall(session, Enable32BitApplicationPool 
failed: , ex, true);
}

return ActionResult.Success;
}

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com] 
Sent: August-28-13 9:41 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Setting a value XmlConfig

Hi John,

I haven't done anything regarding permissions, although I am writing to it on a 
different component and that seems to be working. 

I am not trying to create a AppPool as I am using the default, I am just trying 
to change the enable32BitAppOnWin64 from false to true.

Thanks

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: 28 August 2013 14:19
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Setting a value XmlConfig

1) I assume you have previously obtained permissions to the IIS [7-8] 
applicationHost.config file.  Not just anybody can write to it.

2) It looks like you're creating an AppPool the hard way.  One of the things 
the IIS Extension does really well is create AppPools.  I would use the IIS 
Extension unless there's a compelling reason not to.

3) here's how I use util:XmlConfig:

lt;util:XmlConfig Id=DeleteErrorSinkSinks Action=delete
ElementPath=/logging/categories/error
File=[#FileEnterpriseLoggingConfig] Node=element On=install
Sequence=10 VerifyPath=/logging/categories/error/sinks /gt; 
lt;util:XmlConfig Id=WriteErrorSink Action=create
ElementPath=/logging/categories/error
File=[#FileEnterpriseLoggingConfig] Node=document On=install
Sequence=11 Value=[ERROR_INNERTEXT] /gt;

--
John Merryweather Cooper
Build  Install Engineer -- ESA
Jack Henry  Associates, Inc.(r)
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com




-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: Wednesday, August 28, 2013 5:16 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Setting a value XmlConfig

Hi I am trying to change a value setting in a config file using the
following:

Component Id=Enable32BitAppPoolComponent Guid=*
Directory=INSTALLLOCATION

CreateFolder/

util:XmlConfig Id=Enable32BitAppPool Node=value

 
ElementPath=//configuration/system.applicationHost/applicationPools/add[\[]
@name='DefaultAppPool'[\]]/@enable32BitAppOnWin64

  File=[inetsrv]\config\applicationHost.config

  Value=true On=install/

/Component

This code does not change the value in the applicationHost.config file. I tried 
adding the action=create but I then got the error during the setup that it 
could not open the XML file. What am I doing wrong?

 


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies and 
advance your career. Get an incredible 1,500+ hours of step-by-step tutorial 
videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
WiX-users mailing list

Re: [WiX-users] Setting a value XmlConfig

[Steven Ogilvie]

We support 7.5 and up

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com] 
Sent: August-28-13 10:11 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Setting a value XmlConfig

Steven,

Thanks I was using that but decided to try a different approach. Just a quick 
question as appcmd is not available on iis 6 do you use another method or do 
you not support it?

Thanks
Natalie

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 28 August 2013 14:56
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Setting a value XmlConfig

I am using a custom action for that (I set mine to false) however after our 
product was released I saw this post:

http://stackoverflow.com/questions/11687870/wix-installer-always-changes-app
pool-to-enable-32bit-app

below is my custom action just in case...

[CustomAction]
public static ActionResult Enable32BitApplicationPool(Session
session)
{
try
{
if (session == null)
{
throw new ArgumentNullException(session);
}

var tempString = GetSessionProperty(session, 
CustomActionData, false);
var parts = tempString.Split(new[] { '|' });
var applicationPool = parts[0];
const string Quote = \;
var cmdLineParameters = set apppool /apppool.name: + Quote
+ applicationPool + Quote +  /enable32BitAppOnWin64:false;

var cmdLineExe =
Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.System),
inetsrv\\appcmd.exe);

// Prepare the process to run
var startInfo = new ProcessStartInfo
{
UseShellExecute = true,
Arguments = cmdLineParameters,
FileName = cmdLineExe,
WindowStyle = ProcessWindowStyle.Hidden,
CreateNoWindow = true
};

// Run the external process  wait for it to finish
using (Process proc = Process.Start(startInfo))
{
proc.WaitForExit();
}
}
catch (Exception ex)
{
WriteErrorLogInstall(session, Enable32BitApplicationPool
failed: , ex, true);
}

return ActionResult.Success;
}

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: August-28-13 9:41 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Setting a value XmlConfig

Hi John,

I haven't done anything regarding permissions, although I am writing to it on a 
different component and that seems to be working. 

I am not trying to create a AppPool as I am using the default, I am just trying 
to change the enable32BitAppOnWin64 from false to true.

Thanks

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: 28 August 2013 14:19
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Setting a value XmlConfig

1) I assume you have previously obtained permissions to the IIS [7-8] 
applicationHost.config file.  Not just anybody can write to it.

2) It looks like you're creating an AppPool the hard way.  One of the things 
the IIS Extension does really well is create AppPools.  I would use the IIS 
Extension unless there's a compelling reason not to.

3) here's how I use util:XmlConfig:

lt;util:XmlConfig Id=DeleteErrorSinkSinks Action=delete
ElementPath=/logging/categories/error
File=[#FileEnterpriseLoggingConfig] Node=element On=install
Sequence=10 VerifyPath=/logging/categories/error/sinks /gt; 
lt;util:XmlConfig Id=WriteErrorSink Action=create
ElementPath=/logging/categories/error
File=[#FileEnterpriseLoggingConfig] Node=document On=install
Sequence=11 Value=[ERROR_INNERTEXT] /gt;

--
John Merryweather Cooper
Build  Install Engineer -- ESA
Jack Henry  Associates, Inc.(r)
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com




-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: Wednesday, August 28, 2013 5:16 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Setting a value XmlConfig

Hi I am trying to change a value setting in a config file using the
following:

Component Id=Enable32BitAppPoolComponent Guid=*
Directory=INSTALLLOCATION

CreateFolder/

util:XmlConfig Id=Enable32BitAppPool Node=value

 
ElementPath=//configuration/system.applicationHost/applicationPools/add[\[]
@name='DefaultAppPool'[\]]/@enable32BitAppOnWin64

  File=[inetsrv]\config\applicationHost.config

  Value=true On=install/

/Component

This code does not change the value in the applicationHost.config file. I

Re: [WiX-users] Setting a value XmlConfig

[Steven Ogilvie]

Nice maybe I will switch it to the WIX instead of custom action dll

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com] 
Sent: August-28-13 10:14 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Setting a value XmlConfig

Steven,

Just to show you how I done it within WiX: :)

CustomAction Id=Enable32BitAppPool_Cmd
Property=Enable32BitAppPool
Value=quot;[SystemFolder]inetsrv\appcmdquot; set apppool 
/apppool.name:quot;Map_Poolquot; /enable32BitAppOnWin64:true
Execute=immediate/
CustomAction Id=Enable32BitAppPool BinaryKey=WixCA
DllEntry=CAQuietExec Execute=deferred Return=check Impersonate=no/


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 28 August 2013 14:56
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Setting a value XmlConfig

I am using a custom action for that (I set mine to false) however after our 
product was released I saw this post:

http://stackoverflow.com/questions/11687870/wix-installer-always-changes-app
pool-to-enable-32bit-app

below is my custom action just in case...

[CustomAction]
public static ActionResult Enable32BitApplicationPool(Session
session)
{
try
{
if (session == null)
{
throw new ArgumentNullException(session);
}

var tempString = GetSessionProperty(session, 
CustomActionData, false);
var parts = tempString.Split(new[] { '|' });
var applicationPool = parts[0];
const string Quote = \;
var cmdLineParameters = set apppool /apppool.name: + Quote
+ applicationPool + Quote +  /enable32BitAppOnWin64:false;

var cmdLineExe =
Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.System),
inetsrv\\appcmd.exe);

// Prepare the process to run
var startInfo = new ProcessStartInfo
{
UseShellExecute = true,
Arguments = cmdLineParameters,
FileName = cmdLineExe,
WindowStyle = ProcessWindowStyle.Hidden,
CreateNoWindow = true
};

// Run the external process  wait for it to finish
using (Process proc = Process.Start(startInfo))
{
proc.WaitForExit();
}
}
catch (Exception ex)
{
WriteErrorLogInstall(session, Enable32BitApplicationPool
failed: , ex, true);
}

return ActionResult.Success;
}

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: August-28-13 9:41 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Setting a value XmlConfig

Hi John,

I haven't done anything regarding permissions, although I am writing to it on a 
different component and that seems to be working. 

I am not trying to create a AppPool as I am using the default, I am just trying 
to change the enable32BitAppOnWin64 from false to true.

Thanks

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: 28 August 2013 14:19
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Setting a value XmlConfig

1) I assume you have previously obtained permissions to the IIS [7-8] 
applicationHost.config file.  Not just anybody can write to it.

2) It looks like you're creating an AppPool the hard way.  One of the things 
the IIS Extension does really well is create AppPools.  I would use the IIS 
Extension unless there's a compelling reason not to.

3) here's how I use util:XmlConfig:

lt;util:XmlConfig Id=DeleteErrorSinkSinks Action=delete
ElementPath=/logging/categories/error
File=[#FileEnterpriseLoggingConfig] Node=element On=install
Sequence=10 VerifyPath=/logging/categories/error/sinks /gt; 
lt;util:XmlConfig Id=WriteErrorSink Action=create
ElementPath=/logging/categories/error
File=[#FileEnterpriseLoggingConfig] Node=document On=install
Sequence=11 Value=[ERROR_INNERTEXT] /gt;

--
John Merryweather Cooper
Build  Install Engineer -- ESA
Jack Henry  Associates, Inc.(r)
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com




-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: Wednesday, August 28, 2013 5:16 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Setting a value XmlConfig

Hi I am trying to change a value setting in a config file using the
following:

Component Id=Enable32BitAppPoolComponent Guid=*
Directory=INSTALLLOCATION

CreateFolder/

util:XmlConfig Id=Enable32BitAppPool Node=value

 
ElementPath=//configuration/system.applicationHost/applicationPools/add

Re: [WiX-users] Add text to final window in burn bootstrapper/installer

[Steven Ogilvie]

You want me to make the change for 3.8 or your going to make the change?

I can send you my code for the BA if you want :)

-Original Message-
From: Bruce Cran [mailto:br...@cran.org.uk] 
Sent: August-28-13 12:34 PM
To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Add text to final window in burn bootstrapper/installer

Yes that was for Steven: he's made exactly the same changes I was hoping to get 
around to making, and I'd like to see them get into WiX 3.8 if possible.

--
Bruce

Sent from my iPhone

On 28 Aug 2013, at 16:52, Alain Forget afor...@cmu.edu wrote:

 I hope that's directed at Steven, because I don't know what that means (and I 
 have yet to figure out where and how to modify .wxl files).
 
 Alain
 
 -Original Message-
 From: Bruce Cran [mailto:br...@cran.org.uk]
 Sent: Wednesday, August 28, 2013 11:39 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Add text to final window in burn 
 bootstrapper/installer
 
 Could you sent a pull request to integrate this change upstream please?
 
 --
 Bruce Cran
 
 Sent from my iPhone
 
 On 28 Aug 2013, at 14:28, Steven Ogilvie steven.ogil...@titus.com wrote:
 
 Yes exactly
 
 BA is using the same property for Setup/Uninstall for the 
 success/failure string
 
 I fixed this by changing the code in BA and adding a few extra string 
 properties in the theme wxl file String Id=SuccessHeaderSetup 
 Successful/String String Id=SuccessSetupHeaderSetup 
 Successful/String String Id=SuccessUninstallHeaderUninstall 
 Successful/String String Id=FailureHeaderSetup Failed/String 
 String Id=FailureSetupHeaderSetup Failed/String String 
 Id=FailureUninstallHeaderUninstall Failed/String
 
 BA:
 
 { WIXSTDBA_CONTROL_SUCCESS_HEADER, LSuccessHeader },
   { WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER, LSuccessSetupHeader },
   { WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER, 
 LSuccessUninstallHeader },
 
 { WIXSTDBA_CONTROL_FAILURE_HEADER, LFailureHeader },
   { WIXSTDBA_CONTROL_FAILURE_SETUP_HEADER, LFailureSetupHeader },
   { WIXSTDBA_CONTROL_FAILURE_UNINSTALL_HEADER, 
 LFailureUninstallHeader },
 
 The in OnChangeState is where I set the correct string
 
 
 -Original Message-
 From: Bruce Cran [mailto:br...@cran.org.uk]
 Sent: August-28-13 2:26 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Add text to final window in burn 
 bootstrapper/installer
 
 On 28/08/2013 06:07, Blair Murri wrote:
 As I understand it, page Success will be shown whenever the result of 
 bundle application is successful but not when a failure occurs (when 
 instead the Failure page will be shown). So, successful install, 
 successful removal, successful modification, etc.
 If you can set bundle properties you can use that property's value as your 
 text, maybe...
 
 There was a discussion on wix-devs about this a few months ago: the WixStdBA 
 bootstrapper needs changed to allow better text on the 'success' pages.  In 
 particular, people have complained to me about the fact that when uninstall 
 completes it reports Setup Success.
 
 --
 Bruce Cran
 
 -
 - Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 
 2012, more!
 Discover the easy way to master current and previous Microsoft technologies 
 and advance your career. Get an incredible 1,500+ hours of step-by-step 
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.
 clktrk ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 
 -
 - Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 
 2012, more!
 Discover the easy way to master current and previous Microsoft 
 technologies and advance your career. Get an incredible 1,500+ hours 
 of step-by-step tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.
 clktrk ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 
 --
  Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 
 2012, more!
 Discover the easy way to master current and previous Microsoft 
 technologies and advance your career. Get an incredible 1,500+ hours 
 of step-by-step tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.c
 lktrk ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Add text to final window in burn bootstrapper/installer

[Steven Ogilvie]

Here is the code from BA

Theme wxl file
String Id=SuccessHeaderSetup Successful/String
  String Id=SuccessSetupHeaderSetup Successful/String
  String Id=SuccessUninstallHeaderUninstall Successful/String

String Id=FailureHeaderSetup Failed/String
  String Id=FailureSetupHeaderSetup Failed/String
  String Id=FailureUninstallHeaderUninstall Failed/String

Theme xml file
  Page Name=Success
Text Name=SuccessHeader X=11 Y=80 Width=-11 Height=30 FontId=2 
HideWhenDisabled=yes DisablePrefix=yes#(loc.SuccessHeader)/Text
Text Name=SuccessSetupHeader X=11 Y=80 Width=-11 Height=30 
FontId=2 HideWhenDisabled=yes 
DisablePrefix=yes#(loc.SuccessSetupHeader)/Text
Text Name=SuccessUninstallHeader X=11 Y=80 Width=-11 Height=30 
FontId=2 HideWhenDisabled=yes 
DisablePrefix=yes#(loc.SuccessUninstallHeader)/Text

  Page Name=Failure
Text Name=FailureHeader X=11 Y=80 Width=-11 Height=30 FontId=2 
HideWhenDisabled=yes DisablePrefix=yes#(loc.FailureHeader)/Text
Text Name=FailureSetupHeader X=11 Y=80 Width=-11 Height=30 
FontId=2 HideWhenDisabled=yes 
DisablePrefix=yes#(loc.FailureSetupHeader)/Text
Text Name=FailureUninstallHeader X=11 Y=80 Width=-11 Height=30 
FontId=2 HideWhenDisabled=yes 
DisablePrefix=yes#(loc.FailureUninstallHeader)/Text

WixStandardBootstrapperApplication.cpp

// Success page
WIXSTDBA_CONTROL_SUCCESS_HEADER,
WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER,
WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER,

// Failure page
WIXSTDBA_CONTROL_FAILURE_HEADER,
WIXSTDBA_CONTROL_FAILURE_SETUP_HEADER,
WIXSTDBA_CONTROL_FAILURE_UNINSTALL_HEADER,

{ WIXSTDBA_CONTROL_SUCCESS_HEADER, LSuccessHeader },
{ WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER, LSuccessSetupHeader },
{ WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER, LSuccessUninstallHeader },

{ WIXSTDBA_CONTROL_FAILURE_HEADER, LFailureHeader },
{ WIXSTDBA_CONTROL_FAILURE_SETUP_HEADER, LFailureSetupHeader },
{ WIXSTDBA_CONTROL_FAILURE_UNINSTALL_HEADER, LFailureUninstallHeader },

In method OnChangeState:
..
else if (m_rgdwPageIds[WIXSTDBA_PAGE_SUCCESS] == dwNewPageId) // on the 
Success page, check if the restart or launch button should be enabled.
...
// Set the header of the failure page to either Setup or Uninstall
if (ThemeControlExists(m_pTheme, 
WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER))
{
ThemeControlEnable(m_pTheme, 
WIXSTDBA_CONTROL_SUCCESS_SETUP_HEADER, BOOTSTRAPPER_ACTION_UNINSTALL  
m_plannedAction);
ThemeControlEnable(m_pTheme, 
WIXSTDBA_CONTROL_SUCCESS_HEADER, FALSE);
}
else
{
ThemeControlEnable(m_pTheme, 
WIXSTDBA_CONTROL_SUCCESS_HEADER, TRUE);
}
if (ThemeControlExists(m_pTheme, 
WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER))
{
ThemeControlEnable(m_pTheme, 
WIXSTDBA_CONTROL_SUCCESS_UNINSTALL_HEADER, BOOTSTRAPPER_ACTION_INSTALL  
m_plannedAction);
ThemeControlEnable(m_pTheme, 
WIXSTDBA_CONTROL_SUCCESS_HEADER, FALSE);
}
else
{
ThemeControlEnable(m_pTheme, 
WIXSTDBA_CONTROL_SUCCESS_HEADER, TRUE);
}
...
else if (m_rgdwPageIds[WIXSTDBA_PAGE_FAILURE] == dwNewPageId) // on the 
Failure page, show error message and check if the restart button should be 
enabled.
...
// Set the header of the failure page to either Setup or Uninstall
if (ThemeControlExists(m_pTheme, 
WIXSTDBA_CONTROL_FAILURE_SETUP_HEADER))
{
ThemeControlEnable(m_pTheme, 
WIXSTDBA_CONTROL_FAILURE_SETUP_HEADER, BOOTSTRAPPER_ACTION_UNINSTALL  
m_plannedAction);
ThemeControlEnable(m_pTheme, 
WIXSTDBA_CONTROL_FAILURE_HEADER, FALSE);
}
else
{
ThemeControlEnable(m_pTheme, 
WIXSTDBA_CONTROL_FAILURE_HEADER, TRUE);
}
if (ThemeControlExists(m_pTheme, 
WIXSTDBA_CONTROL_FAILURE_UNINSTALL_HEADER))
{
ThemeControlEnable(m_pTheme, 
WIXSTDBA_CONTROL_FAILURE_UNINSTALL_HEADER, BOOTSTRAPPER_ACTION_INSTALL  
m_plannedAction);
ThemeControlEnable(m_pTheme, 
WIXSTDBA_CONTROL_FAILURE_HEADER, FALSE);
}
else
{
ThemeControlEnable(m_pTheme, 
WIXSTDBA_CONTROL_FAILURE_HEADER, TRUE);
}

That should be it :)

Cheers,

Steve
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com] 
Sent: August-28-13 1:14 PM
To: General discussion for Windows Installer XML toolset.; afor...@cmu.edu
Subject: Re: [WiX-users] Add text to final window in burn bootstrapper/installer

You want me to make the change for 3.8 or your going

Re: [WiX-users] Theme element

[Steven Ogilvie]

You mean like this:
WixVariable Id=WixExtbaThemeXml 
Value=$(var.SolutionDir)Include\HyperlinkTheme.xml /
WixVariable Id=WixExtbaThemeWxl 
Value=$(var.SolutionDir)Include\HyperlinkTheme_ClientSuite.wxl /

-Original Message-
From: yugolancer [mailto:thewebo...@yahoo.com] 
Sent: August-22-13 6:04 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Theme element

Hello Guys,

How do I fix this odd error?

*The document element name 'Theme' is invalid.  A Windows Installer XML source 
file must use 'Wix' as the document element name.*

It's just the same RtfTheme.xml that I copied from the source-code
(src\ext\BalExtension\wixstdba\Resources)

I haven't modified the theme.
I just set the ThemeFile attribute in the 
bal:WixStandardBootstrapperApplication

Also if you know please tell me what should the build action for the theme 
file(s). 

Thank you so much




--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Theme-element-tp7588336.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Introducing Performance Central, a new site from SourceForge and AppDynamics. 
Performance Central is your source for news, insights, analysis and resources 
for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Embedded UI Dependent files

[Steven Ogilvie]

Is this for Burn, wouldn't you use Payload
i.e. Payload SourceFile=pathto some file/

Steve

-Original Message-
From: Phyx [mailto:loneti...@gmail.com] 
Sent: August-21-13 11:06 AM
To: wix-users@lists.sourceforge.net
Cc: loneti...@gmail.com
Subject: [WiX-users] Embedded UI Dependent files

Hi Guys,

I have finally gotten an Embedded WPF example to work, but I've ran into a 
problem: I need to add some extra files that should only be used by the WPF UI.

without these the UI doesn't run. The problem is I don't know how to add them. 
If I use a Component File .. wouldn't that be added as a part of the 
installed application instead of the UI installer?

I have been trying to look at the documentation but it's been down all day 
unfortunately.

I'm sure i'm missing something quite simple.

Regards,
Tamar

--
Introducing Performance Central, a new site from SourceForge and AppDynamics. 
Performance Central is your source for news, insights, analysis and resources 
for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Basic MSI without UI

[Steven Ogilvie]

Did you try running the MSI via the command line MSIEXEC /qn?



Windows (r) Installer. V 5.0.7601.17514



msiexec /Option Required Parameter [Optional Parameter]



Install Options

   /package | /i Product.msi

  Installs or configures a product

   /a Product.msi

  Administrative install - Installs a product on 
the network

   /ju|m Product.msi [/t Transform List] [/g Language ID]

  Advertises a product - m to all users, u to 
current user

   /uninstall | /x Product.msi | ProductCode

  Uninstalls the product

Display Options

   /quiet

  Quiet mode, no user interaction

   /passive

  Unattended mode - progress bar only

   /q[n|b|r|f]

  Sets user interface level

  n - No UI

  b - Basic UI

  r - Reduced UI

  f - Full UI (default)

   /help

  Help information

Restart Options

   /norestart

  Do not restart after the installation is complete

   /promptrestart

  Prompts the user for restart if necessary

   /forcerestart

  Always restart the computer after installation

Logging Options

   /l[i|w|e|a|r|u|c|m|o|p|v|x|+|!|*] LogFile

  i - Status messages

  w - Nonfatal warnings

  e - All error messages

  a - Start up of actions

  r - Action-specific records

  u - User requests

  c - Initial UI parameters

  m - Out-of-memory or fatal exit information

  o - Out-of-disk-space messages

  p - Terminal properties

  v - Verbose output

  x - Extra debugging information

  + - Append to existing log file

  ! - Flush each line to the log

  * - Log all information, except for v and x 
options

   /log LogFile

  Equivalent of /l* LogFile

Update Options

   /update Update1.msp[;Update2.msp]

  Applies update(s)

   /uninstall PatchCodeGuid[;Update2.msp] /package Product.msi | 
ProductCode

  Remove update(s) for a product

Repair Options

   /f[p|e|c|m|s|o|d|a|u|v] Product.msi | ProductCode

  Repairs a product

  p - only if file is missing

  o - if file is missing or an older version is 
installed (default)

  e - if file is missing or an equal or older 
version is installed

  d - if file is missing or a different version is 
installed

  c - if file is missing or checksum does not match 
the calculated value

  a - forces all files to be reinstalled

  u - all required user-specific registry entries 
(default)

  m - all required computer-specific registry 
entries (default)

  s - all existing shortcuts (default)

  v - runs from source and recaches local package

Setting Public Properties

   [PROPERTY=PropertyValue]



-Original Message-
From: Andrei Trif [mailto:trif.and...@mail.com]
Sent: August-20-13 2:25 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Basic MSI without UI



Hello,



I just started with WIX and I have a question, is there any way I can hide the 
little box where Windows Installer says what's happening during the install of 
a simple basic msi without a UI?



I tried to suppress the entire UI sequence but the little box is still 
displayed.

Then I tried to set the UILEVEL property to 2 but little box is still 
displayed. In the log file I can see that the property is actually set to 3 
just before the INSTALL.

Then I tried to set the LIMITUI property to 2 but the little box is still there.



Please give some advice.



Thank you,



Andrei

--

Introducing Performance Central, a new site from SourceForge and AppDynamics. 
Performance Central is your source for news, insights, analysis and resources 
for efficient Application Performance Management.

Re: [WiX-users] Basic MSI without UI

[Steven Ogilvie]

This was asked before, here is an answer:
In reply to this post by Pierson Lee (Volt)
Pierson Lee (Volt) wrote:
Is there a property within the Wix I can set conditionally (dependent upon a 
registry key) whether or not to display a UI?

No. UILevel is set by MSI to indicate how the *user* chose to run your package. 
As long as you have authored UI, a user can always request it.
 -- 
sig://boB
http://joyofsetup.com/

once again my response is: if you want to change the UI level during 
installation type MSIEXEC at a cmd prompt that will give you a list of cmd line 
parameters to use to run a MSI
i.e.:
Display Options
/quiet
Quiet mode, no user interaction
/passive
Unattended mode - progress bar only
/q[n|b|r|f]
Sets user interface level
n - No UI
b - Basic UI
r - Reduced UI
f - Full UI (default)
/help
Help information

-Original Message-
From: Andrei Trif [mailto:trif.and...@mail.com] 
Sent: August-20-13 4:03 PM
To: General discussion for Windows Installer XML toolset. 
Subject: Re: [WiX-users] Basic MSI without UI

Hello,

Hmm... to run the msi with the /qn switch I need to build a boostrapper with 
Burn. The result will be an exe file with a different UI. To remove this UI I 
need to create a custom BA and if I manage to do this succesfully I will have 2 
entries in Add/Remove Programs, one for my msi and one for my bootstrapper, and 
I still have an exe instead of a msi. All this looks a little bit silly 
considering that the proper value for the UILevel might do the trick.

John, can I set the UILevel property using the Property element in the .wxs 
file?

Thank you,
Andrei

Marlos Gottschild marlos.gottsch...@gmail.com wrote:

Hi,
You can create a bootstrapper using Burn and set the execution to /quiet.

BR,
Marlos


2013/8/20 Andrei Trif trif.and...@mail.com

 Hello,

 I just started with WIX and I have a question, is there any way I can 
 hide the little box where Windows Installer says what's happening 
 during the install of a simple basic msi without a UI?

 I tried to suppress the entire UI sequence but the little box is 
 still displayed.
 Then I tried to set the UILEVEL property to 2 but little box is still 
 displayed. In the log file I can see that the property is actually 
 set to 3 just before the INSTALL.
 Then I tried to set the LIMITUI property to 2 but the little box is 
 still there.

 Please give some advice.

 Thank you,

 Andrei

 -
 - Introducing Performance Central, a new site from 
 SourceForge and AppDynamics. Performance Central is your source for 
 news, insights, analysis and resources for efficient Application 
 Performance Management.
 Visit us today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.
 clktrk ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

---
--- Introducing Performance Central, a new site from SourceForge 
and AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.cl
ktrk ___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Introducing Performance Central, a new site from SourceForge and AppDynamics. 
Performance Central is your source for news, insights, analysis and resources 
for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Validate browser

[Steven Ogilvie]

What does the burn runtime log file have ?

-Original Message-
From: Christopher M. Bunn [mailto:cmb...@torchmarkcorp.com] 
Sent: August-09-13 10:18 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Validate browser

Does anyone see anything wrong with the following code?  I'm trying to check 
the version of the browser in BURN ( bootstrapper app) and see if it is greater 
than or equal to 8.  Otherwise stop the install and display message.
It evaluates to false every time even if I change it to an expression that 
should work.

 

util:RegistrySearch

 Root=HKLM

 Key=SOFTWARE\Microsoft\Internet Explorer

 Value=Version

 Variable=IEVersion

/

 

bal:Condition Message=Internet Explorer version 8 or higher must be 
installedIEVersion = 8/bal:Condition

 

Thanks,

Chris Bunn

 

 

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Validate browser

[Steven Ogilvie]

Check your %temp%
i.e. C:\Users\your login user\AppData\Local\Temp
name would be: MY_INSTALLER_20130809114750.log

Steve

-Original Message-
From: Christopher M. Bunn [mailto:cmb...@torchmarkcorp.com] 
Sent: August-09-13 11:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Validate browser

Where is the burn runtime log file?  I'm not seeing a log file anywhere

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Friday, August 09, 2013 9:24 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Validate browser

What does the burn runtime log file have ?

-Original Message-
From: Christopher M. Bunn [mailto:cmb...@torchmarkcorp.com]
Sent: August-09-13 10:18 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Validate browser

Does anyone see anything wrong with the following code?  I'm trying to check 
the version of the browser in BURN ( bootstrapper app) and see if it is greater 
than or equal to 8.  Otherwise stop the install and display message.
It evaluates to false every time even if I change it to an expression that 
should work.

 

util:RegistrySearch

 Root=HKLM

 Key=SOFTWARE\Microsoft\Internet Explorer

 Value=Version

 Variable=IEVersion

/

 

bal:Condition Message=Internet Explorer version 8 or higher must be 
installedIEVersion = 8/bal:Condition

 

Thanks,

Chris Bunn

 

 

-
-
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
-
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Validate browser

[Steven Ogilvie]

I am getting the version of IIS and see what it is in burn this is what I have:

!-- Check for IIS 7.0 and above --
util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\InetStp 
Result=value Value=MajorVersion Variable=IISVersion /
util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\InetStp 
Result=value Value=MajorVersion Variable=IISx64Version Win64=yes /

!-- Check for IIS 7.5 and above --
bal:Condition Message=$(var.ProductName) requires Microsoft Internet 
Information Services (IIS) 7.5 or above installed.
  ![CDATA[(NOT((IISVersion  7) AND (NOT VersionNT64 OR (IISx64Version  
7)))]]
/bal:Condition

Log results:

[1394:1F58][2013-08-09T13:17:00]i000: Setting string variable 'IISVersion' to 
value '7'
[1394:1F58][2013-08-09T13:17:00]i000: Setting string variable 'IISx64Version' 
to value '7'

[1394:1F58][2013-08-09T13:17:00]i052: Condition '(NOT((IISVersion  7) AND (NOT 
VersionNT64 OR (IISx64Version  7))) )' evaluates to true.
You can use the same similar logic


-Original Message-
From: Christopher M. Bunn [mailto:cmb...@torchmarkcorp.com] 
Sent: August-09-13 12:06 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Validate browser

Great - Thanks Steven! - found it - That is helpful!  The expression is false, 
I'm guessing because it's comparing a string with a number.  Is there any way 
to get the version as a integer/number?

[03E0:05EC][2013-08-09T10:53:26]i000: Setting string variable 'IEVersion' to 
value '6.0.2900.5512'

03E0:05EC][2013-08-09T10:53:26]i052: Condition 'IEVersion = 5' evaluates to 
false.


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Friday, August 09, 2013 10:49 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Validate browser

Check your %temp%
i.e. C:\Users\your login user\AppData\Local\Temp name would be:
MY_INSTALLER_20130809114750.log

Steve

-Original Message-
From: Christopher M. Bunn [mailto:cmb...@torchmarkcorp.com]
Sent: August-09-13 11:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Validate browser

Where is the burn runtime log file?  I'm not seeing a log file anywhere

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Friday, August 09, 2013 9:24 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Validate browser

What does the burn runtime log file have ?

-Original Message-
From: Christopher M. Bunn [mailto:cmb...@torchmarkcorp.com]
Sent: August-09-13 10:18 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Validate browser

Does anyone see anything wrong with the following code?  I'm trying to check 
the version of the browser in BURN ( bootstrapper app) and see if it is greater 
than or equal to 8.  Otherwise stop the install and display message.
It evaluates to false every time even if I change it to an expression that 
should work.

 

util:RegistrySearch

 Root=HKLM

 Key=SOFTWARE\Microsoft\Internet Explorer

 Value=Version

 Variable=IEVersion

/

 

bal:Condition Message=Internet Explorer version 8 or higher must be 
installedIEVersion = 8/bal:Condition

 

Thanks,

Chris Bunn

 

 

-
-
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
-
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
-
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Msiexec command prompt when running setup

[Steven Ogilvie]

In a dos box (cmd prompt) you type msiexec.exe /I Myinstaller.msi you can add 
other options like logging, no reboot etc..

-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org] 
Sent: August-08-13 1:46 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Msiexec command prompt when running setup

I don't know what an msiexec command propt is - you may need to be more 
specific about what it is and the exact message text. 

The only scenarios I can think of where you might see that kind of 
informational dialog that just goes away are remote desktop types, or maybe 
Terminal Server or VMWare connections. Something like that anyway.

Phil 

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: Thursday, August 08, 2013 6:28 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Msiexec command prompt when running setup

Hi,

 

Seeing a strange problem with a few of my setups, when they are run a msiexec 
command prompt opens saying opening connection and it stays until the setup has 
been completed.

 

Does anyone know why this would be happening?

 

Thanks

Natalie


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
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 set a variable by selecting a different radiobutton in BURN?

[Steven Ogilvie]

Aw nuts :(

I was hoping that was something in Burn that I could use...

Hey on the bright side the extended BA will be in 3.8 :)

Steve

-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com] 
Sent: August-08-13 1:41 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] is there a way to set a variable by selecting a 
different radiobutton in BURN?

I just started working with the
WixExtendedBootstrapperApplication.HyperlinkLicense yesterday, and there is 
some functionality that I do not understand yet.  But it seems like you could 
use the BAFunction.dll template.

In the bundle you would do something like:

Variable Name='EULA1' Type='string' Value='lt;url to eula1'
bal:Overridable='yes'/
Variable Name='EULA2' Type='string' Value='lt;url to eula2'
bal:Overridable='yes'/


In the BAFunction OnPlan, do something like this:
   LPWSTR sczEula1 = NULL;
   LPWSTR sczEula2 = NULL;
   BalGetStringVariable(LWixBundleName, sczEula1);
   BalExitOnFailure(hr, Failed to get variable.);
   BalGetStringVariable(LWixBundleName, sczEula2);
   BalExitOnFailure(hr, Failed to get variable.);
  
   LONGLONG llValue = 0;
if (SUCCEEDED(BalGetNumericVariable(LRadioButton1, llValue)) 
llValue)
{
m_pEngine-SetVariableNumeric(LRadioButton, 1);
BalExitOnFailure(hr, Failed to set variable.);

   
hr = m_pEngine-SetVariableString(LWixExtbaLicenseUrl,
sczEula1);
BalExitOnFailure(hr, Failed to set variable.);
 
}
else if (SUCCEEDED(BalGetNumericVariable(LRadioButton2, llValue))  
llValue)
{
m_pEngine-SetVariableNumeric(LRadioButton, 2);
BalExitOnFailure(hr, Failed to set variable.);
hr = m_pEngine-SetVariableString(LWixExtbaLicenseUrl,
sczEula1);
BalExitOnFailure(hr, Failed to set variable.);
}
else if (SUCCEEDED(BalGetNumericVariable(LRadioButton3, llValue))  
llValue)
{
m_pEngine-SetVariableNumeric(LRadioButton, 3);
BalExitOnFailure(hr, Failed to set variable.);
hr = m_pEngine-SetVariableString(LWixExtbaLicenseUrl,
sczEula2);
BalExitOnFailure(hr, Failed to set variable.);
}
else
{
m_pEngine-SetVariableNumeric(LRadioButton, 0);
BalExitOnFailure(hr, Failed to set variable.);
hr = m_pEngine-SetVariableString(LWixExtbaLicenseUrl,
sczEula1);
BalExitOnFailure(hr, Failed to set variable.);
}
   ReleaseNullStr(sczEula1); // Release string so it can be re-used
   ReleaseNullStr(sczEula2); // Release string so it can be re-used 

I am guessing that you might need to do something to reload the dialog, which I 
don't know what is involved there.  I have setting the vars and reading them in 
the BAFuntion and changing them working, but I am not trying to do anything 
with the Eula string at this time so I am not sure of the dialog behavior in 
that regard.  (For some reason I can't get the DelayStart to actually show and 
delay the splashcreen, but that will need to be another
thread.)
Phill




--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/is-there-a-way-to-set-a-variable-by-selecting-a-different-radiobutton-in-BURN-tp7587887p7587889.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] BURN - Check browser version and install if not the minimum browser

[Steven Ogilvie]

Get the version number of the browser by using the util:RegistrySearch element 
(HKLM\SOFTWARE\Microsoft\Internet Explorer get the value for the key Version, 
then based on the result from that use an installcondition for installing the 
IE8
InstallCondition=IEVersion  8.1 or whatever is the version you want

Steve

-Original Message-
From: Christopher M. Bunn [mailto:cmb...@torchmarkcorp.com] 
Sent: August-08-13 4:24 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] BURN - Check browser version and install if not the 
minimum browser

Can anyone provide an example to handle the following scenario??  I need get 
the version of Internet Explorer Browser in a boot strapper project in BURN 
used for person who loads MSI.  I need to be able to install IE 8 (which is our 
minimum requirements) if the version is less than 8.  Any help is appreciated!

 

 

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WixStdBA Command line parameters

[Steven Ogilvie]

Yup pretty easy
i.e. MyBundle.exe APROPERTY=DIFFERENTVALUE

Bundle.wxs

Variable Name= APROPERTY  Type=string bal:Overridable=yes 
Value=DEFAULTVALUE/

Then in MSIPackage element:

MsiProperty Name= APROPERTY  Value=[ APROPERTY]/

In your MSI
Property Id= APROPERTY  Secure=yes/

If you don't use the command line parameter the default value that you set i.e. 
Value=DEFAULTVALUE will be used :)

Steve

-Original Message-
From: Ian Williams [mailto:iawil...@microsoft.com] 
Sent: August-07-13 7:04 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WixStdBA Command line parameters

Using WixStdBA with WiX 3.6.

Is there a way allow custom command line parameters to set values of Variables 
in the bundle?

Thanks,
Ian
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Detect Internet Explorer Browser Version [P]

[Steven Ogilvie]

Classification: Public
Use the WIX RegistrySearch element to get the version of IE from the registry 
key at HKLM\SOFTWARE\Microsoft\Internet Explorer

i.e.
Property Id=IE_VERSION Secure=yes
  RegistrySearch Id=GetIEVersion
  Key=SOFTWARE\Microsoft Microsoft\Internet Explorer 
  Name=Version
  Root=HKLM
  Type=raw
  Win64=no/
/Property

Steve

-Original Message-
From: Christopher M. Bunn [mailto:cmb...@torchmarkcorp.com]
Sent: August-06-13 5:46 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Detect Internet Explorer Browser Version

Can anyone provide an example in WIX to check the version of Internet Explorer 
Browser used for person who loads MSI?

 

Thanks,

Chris Bunn

214-250-5602

 

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


This message has been marked as Public by Steven Ogilvie on August-06-13 
5:56:41 PM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.





--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Need help, how to put a condition on a merge module in Product.wxs [P]

[Steven Ogilvie]

Classification: Public
I originally have two solutions for the Services installer, in the x86 
product.wxs I have the 5 x86 merge modules, in the x64 product.wxs I have the 5 
x64 merge modules...
So there are two sets of merge modules x86 compiled and x64 compiled

I am trying to make 1 solution using the configurations to build x86 MSI x64 MSI

Steve

-Original Message-
From: Blair Murri [mailto:os...@live.com]
Sent: July-31-13 1:23 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

You need one set of merge modules for x64 and another for x86, correct?
 
Use conditional compilation. You don't need all the merge modules in the x86, 
correct? Why put them there?
 
Or am I missing something?
 
 From: steven.ogil...@titus.com
 To: wix-users@lists.sourceforge.net; d...@agilityrecordbook.com
 Date: Tue, 30 Jul 2013 16:19:37 +
 Subject: Re: [WiX-users] Need help, how to put a condition on a merge 
 module in Product.wxs [P]
 
 Classification: Public
 Yup I have the configuration set in the Solution file for my Services 
 Solution, and in each MergeModule WIXProj I have set up x86/x64 
 configurations so it is built twice once for x86 and once for x64 and 
 placed in different folders wixlib/wixlibx64 (both merge modules and
 wixlibs)
 
 So I have 1 MergeModule project / 1 wixlib project but multiple 
 configurations to handle the x86/x64
 
 Looks like I am pooched...
 
 Steve
 
 -Original Message-
 From: David Watson [mailto:dwat...@sdl.com]
 Sent: July-30-13 12:11 PM
 To: General discussion for Windows Installer XML toolset.; David 
 Connet
 Subject: Re: [WiX-users] Need help, how to put a condition on a merge 
 module in Product.wxs [P]
 
 Isn't the win64 setting on the component so you need to build a 64bit 
 and a
 32 bit version of each merge module (or wixlib).
 This is easily done with a shared .wxs file and a compilation setting.
 
 I have 32 and 64 bit components all up my build tree just because one package 
 needs a 32 and a 64 bit msi.
 
 (another) Dave
 
 
 -Original Message-
 From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
 Sent: 30 July 2013 16:54
 To: David Connet; General discussion forWindows Installer XML toolset.
 Subject: Re: [WiX-users] Need help, how to put a condition on a merge 
 module in Product.wxs [P]
 
 Classification: Public
 Sigh same merge modules just compiled under x86 and x64
 
 Get the error:
 
 Error 49  The merge module 'EnterpriseServicesMM_x64' contains a file
 identifier,
 'fil2502525491FAEBF0E0D0ED1FE352E76D.9EFC3F5B_3D47_4233_A162_371DEF5D8
 E92', that is duplicated either in another merge module or in a 
 File/@Id attribute.
 File identifiers must be unique.  Please change one of the file identifiers
 to a different value. C:\Dev\ Setup\Services_Setup\Product.wxs282
 1 Services_Setup
 
 Feature Id=MergeModulesX86
  Title=Merge modules for 32 bit OS
  Level=1
  Display=expand
  ConfigurableDirectory=DIRECTORY_PATH_SERVICES
   ...
   MergeRef Id=ServicesMergeModule/
   Condition Level=1
 ![CDATA[NOT(VersionNT64) OR $(var.Platform) = x86]]
   /Condition
 /Feature
 Feature Id=MergeModulesX64
  Title=Merge modules for 64 bit OS
  Level=1
  Display=expand
  ConfigurableDirectory=DIRECTORY_PATH_SERVICES
   ...
   MergeRef Id=ServicesMergeModule_x64/
   Condition Level=1
 ![CDATA[VersionNT64 OR $(var.Platform) = x64]]
   /Condition
 
 ...
 Merge Id=ServicesMergeModule DiskId=1
 SourceFile=$(env.SharedServices)\Installers\wixlib\ServicesMergeModule.msm
 Language=1033/ ...
 Merge Id=ServicesMergeModule_x64 DiskId=1
 SourceFile=$(env.SharedServices)\Installers\wixlibx64\ServicesMergeMo
 dule.ms
 m Language=1033/
 
 -Original Message-
 From: David Connet [mailto:d...@agilityrecordbook.com]
 Sent: July-30-13 11:10 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Need help, how to put a condition on a merge 
 module in Product.wxs [P]
 
 Assign them to a feature and condition the feature.
 
 Dave
 
 
 
 - Original Message -
 From: Steven Ogilvie steven.ogil...@titus.com
 To: General discussion for Windows Installer XML toolset.
 wix-users@lists.sourceforge.net
 Cc: 
 Sent: Tuesday, July 30, 2013 7:16 AM
 Subject: Re: [WiX-users] Need help, how to put a condition on a merge 
 module in Product.wxs [P]
 
 Classification: Public
 The 5 merge modules have ComponentGroupRef Id=cmpgrp_Log4Net/ of 
 about 10 wixlibs The files in the MergeModules and WixLibs are built 
 as AnyCPU however since I need to install the services for 64 bit OS 
 and 32 bit OS I need two MSI's one for 32 and one for 64 bit
 
 So I am not using any binary files that are specific for 32 bit or 64 bit, I 
 just need to include the MergeModules in 1

Re: [WiX-users] Need help, how to put a condition on a merge module in Product.wxs [P]

[Steven Ogilvie]

Classification: Public
Can't use WIXLIBS to replace the MERGEMODULES (Rob confirmed that with me)

I am installing 5 Services, they each go into a separate folder off the 
Services parent folder.

They share 8-10 WIXLIBS each (common files for each service, didn't make sense 
to create new component for each file 5 times)

Hence I can't use WIXLIBS for the Merge Modules nor can I throw everything into 
the Product.wxs since I would be repeating  files 5 times 10-20 files...

Was able to change 3 other installers from 2 solutions down to 1 solution and 
able to create x86 and x64 MSI's

Might just leave this one alone :(

Steve

-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: July-31-13 12:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

I did it by not using merge modules, I used pure wixlibs.

http://wyrdfish.wordpress.com/2011/01/05/32-and-64-bit-msis-from-a-single-sou
rce-file/

So my components are pulled into the msi by ComponentGroupRef not by MergeID.

I only have the relevant bitness wixlib referenced in the wixproj.


Can you work around the issue with some pre-processing?

e.g.

?if $(var.Platform)=x64 ?
MergeRef Id=ServicesMergeModule/
?else ?
MergeRef Id=ServicesMergeModule_x64/ ?endif ?

You seem to be trying to include both sets of merge module into the msi at 
compile time then deciding on what to install at runtime when you actually need 
to decide at compile time.

Dave W.

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 31 July 2013 13:55
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Classification: Public
I originally have two solutions for the Services installer, in the x86 
product.wxs I have the 5 x86 merge modules, in the x64 product.wxs I have the
5 x64 merge modules...
So there are two sets of merge modules x86 compiled and x64 compiled

I am trying to make 1 solution using the configurations to build x86 MSI x64 MSI

Steve

-Original Message-
From: Blair Murri [mailto:os...@live.com]
Sent: July-31-13 1:23 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

You need one set of merge modules for x64 and another for x86, correct?
 
Use conditional compilation. You don't need all the merge modules in the x86, 
correct? Why put them there?
 
Or am I missing something?
 
 From: steven.ogil...@titus.com
 To: wix-users@lists.sourceforge.net; d...@agilityrecordbook.com
 Date: Tue, 30 Jul 2013 16:19:37 +
 Subject: Re: [WiX-users] Need help, how to put a condition on a merge 
 module in Product.wxs [P]
 
 Classification: Public
 Yup I have the configuration set in the Solution file for my Services 
 Solution, and in each MergeModule WIXProj I have set up x86/x64 
 configurations so it is built twice once for x86 and once for x64 and 
 placed in different folders wixlib/wixlibx64 (both merge modules and
 wixlibs)
 
 So I have 1 MergeModule project / 1 wixlib project but multiple 
 configurations to handle the x86/x64
 
 Looks like I am pooched...
 
 Steve
 
 -Original Message-
 From: David Watson [mailto:dwat...@sdl.com]
 Sent: July-30-13 12:11 PM
 To: General discussion for Windows Installer XML toolset.; David 
 Connet
 Subject: Re: [WiX-users] Need help, how to put a condition on a merge 
 module in Product.wxs [P]
 
 Isn't the win64 setting on the component so you need to build a 64bit 
 and a
 32 bit version of each merge module (or wixlib).
 This is easily done with a shared .wxs file and a compilation setting.
 
 I have 32 and 64 bit components all up my build tree just because one
package needs a 32 and a 64 bit msi.
 
 (another) Dave
 
 
 -Original Message-
 From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
 Sent: 30 July 2013 16:54
 To: David Connet; General discussion forWindows Installer XML toolset.
 Subject: Re: [WiX-users] Need help, how to put a condition on a merge 
 module in Product.wxs [P]
 
 Classification: Public
 Sigh same merge modules just compiled under x86 and x64
 
 Get the error:
 
 Error 49  The merge module 'EnterpriseServicesMM_x64' contains a file
 identifier,
 'fil2502525491FAEBF0E0D0ED1FE352E76D.9EFC3F5B_3D47_4233_A162_371DEF5D8
 E92', that is duplicated either in another merge module or in a 
 File/@Id attribute.
 File identifiers must be unique.  Please change one of the file identifiers
 to a different value. C:\Dev\ Setup\Services_Setup\Product.wxs282
 1 Services_Setup
 
 Feature Id=MergeModulesX86
  Title=Merge modules for 32 bit OS
  Level=1
  Display=expand
  ConfigurableDirectory=DIRECTORY_PATH_SERVICES
   ...
   MergeRef Id=ServicesMergeModule

Re: [WiX-users] Need help, how to put a condition on a merge module in Product.wxs [P]

[Steven Ogilvie]

Classification: Public
Sigh, every example I see out there in Google land they use

?if $(var.Platform) = x64 ?
  ?define Win=yes ?
  ?define PlatformProductName = $(var.ProductName) (64 bit) ?
  ?define PlatformProgramFilesFolder = ProgramFiles64Folder ?
  ?define PlatformCAQuietExecDLLEntry = CAQuietExec64?
  ?define PlatformQtExecCmdLine = QtExec64CmdLine?
  ?else ?
  ?define Win=no ?
  ?define PlatformProductName = $(var.ProductName) ?
  ?define PlatformProgramFilesFolder = ProgramFilesFolder ?
  ?define PlatformCAQuietExecDLLEntry = CAQuietExec?
  ?define PlatformQtExecCmdLine = QtExecCmdLine?
  ?endif ?

And also this?

Component Id=cmp_TL_DsoFileHooksDll_x64 
Guid={A7A293D2-D3FD-4616-BA75-C573F24512BD} Win64=$(var.Win)
  File Id=file_TL_DsoFileHooksDll_x64 KeyPath=yes 
Source=$(var.tcpSourcePath)\lib\x64\TL_DsoFileHooks.dll
   /File
  Condition
![CDATA[VersionNT64 OR $(var.Platform) = x64]]
  /Condition
/Component
So your saying replace $(var.Platform) with $(sys.BUILDARCH) since the above 
code should run at runtime...

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: July-31-13 1:38 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Yes, it appears to be inverted.

Also, as the documentation states, $(sys.BUILDARCH) is a better choice than 
$(var.Platform).

--
John Merryweather Cooper
Build  Install Engineer - ESA
Jack Henry  Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com 




-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Wednesday, July 31, 2013 12:22 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

That should work, remembering you need both a 32bit and a 64 bit MSI.  Though 
I do think you have the MergRef's inverted based on the condition...

-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Wednesday, July 31, 2013 11:48 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Sorry I may have confused the issue by stating how I did it, the main question 
was does this (or something similar) not work ?

Along the lines of 

?if $(var.Platform)=x64 ?
MergeRef Id=ServicesMergeModule/
?else ?
MergeRef Id=ServicesMergeModule_x64/  ?endif ?



-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 31 July 2013 17:26
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Classification: Public
Can't use WIXLIBS to replace the MERGEMODULES (Rob confirmed that with me)

I am installing 5 Services, they each go into a separate folder off the 
Services parent folder.

They share 8-10 WIXLIBS each (common files for each service, didn't make sense 
to create new component for each file 5 times)

Hence I can't use WIXLIBS for the Merge Modules nor can I throw everything into 
the Product.wxs since I would be repeating  files 5 times 10-20 files...

Was able to change 3 other installers from 2 solutions down to 1 solution and 
able to create x86 and x64 MSI's

Might just leave this one alone :(

Steve

-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: July-31-13 12:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

I did it by not using merge modules, I used pure wixlibs.

http://wyrdfish.wordpress.com/2011/01/05/32-and-64-bit-msis-from-a-single-sou
rce-file/

So my components are pulled into the msi by ComponentGroupRef not by MergeID.

I only have the relevant bitness wixlib referenced in the wixproj.


Can you work around the issue with some pre-processing?

e.g.

?if $(var.Platform)=x64 ?
MergeRef Id=ServicesMergeModule/
?else ?
MergeRef Id=ServicesMergeModule_x64/ ?endif ?

You seem to be trying to include both sets of merge module into the msi at 
compile time then deciding on what to install at runtime when you actually need 
to decide at compile time.

Dave W.

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 31 July 2013 13:55
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Classification: Public
I originally have two solutions for the Services installer, in the x86 
product.wxs I have the 5 x86 merge modules, in the x64 product.wxs I have the
5 x64 merge modules...
So there are two sets of merge modules x86 compiled and x64 compiled

I am trying to make 1 solution using the configurations

Re: [WiX-users] Need help, how to put a condition on a merge module in Product.wxs [P]

[Steven Ogilvie]

Classification: Public
Nuts more files to change roger that, will change :)

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: July-31-13 2:05 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

I have a very similar include file in the installer that must build two 
platforms.  The only difference is that I replace $(var.Platform) with 
$(sys.BUILDARCH).  It has worked in production for nearly two years that way.

--
John Merryweather Cooper
Build  Install Engineer - ESA
Jack Henry  Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com 




-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Wednesday, July 31, 2013 12:50 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Classification: Public
Sigh, every example I see out there in Google land they use

?if $(var.Platform) = x64 ?
  ?define Win=yes ?
  ?define PlatformProductName = $(var.ProductName) (64 bit) ?
  ?define PlatformProgramFilesFolder = ProgramFiles64Folder ?
  ?define PlatformCAQuietExecDLLEntry = CAQuietExec64?
  ?define PlatformQtExecCmdLine = QtExec64CmdLine?
  ?else ?
  ?define Win=no ?
  ?define PlatformProductName = $(var.ProductName) ?
  ?define PlatformProgramFilesFolder = ProgramFilesFolder ?
  ?define PlatformCAQuietExecDLLEntry = CAQuietExec?
  ?define PlatformQtExecCmdLine = QtExecCmdLine?
  ?endif ?

And also this?

Component Id=cmp_TL_DsoFileHooksDll_x64 
Guid={A7A293D2-D3FD-4616-BA75-C573F24512BD} Win64=$(var.Win)
  File Id=file_TL_DsoFileHooksDll_x64 KeyPath=yes 
Source=$(var.tcpSourcePath)\lib\x64\TL_DsoFileHooks.dll
   /File
  Condition
![CDATA[VersionNT64 OR $(var.Platform) = x64]]
  /Condition
/Component
So your saying replace $(var.Platform) with $(sys.BUILDARCH) since the above 
code should run at runtime...

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: July-31-13 1:38 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Yes, it appears to be inverted.

Also, as the documentation states, $(sys.BUILDARCH) is a better choice than 
$(var.Platform).

--
John Merryweather Cooper
Build  Install Engineer - ESA
Jack Henry  Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com 




-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Wednesday, July 31, 2013 12:22 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

That should work, remembering you need both a 32bit and a 64 bit MSI.  Though 
I do think you have the MergRef's inverted based on the condition...

-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Wednesday, July 31, 2013 11:48 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Sorry I may have confused the issue by stating how I did it, the main question 
was does this (or something similar) not work ?

Along the lines of 

?if $(var.Platform)=x64 ?
MergeRef Id=ServicesMergeModule/
?else ?
MergeRef Id=ServicesMergeModule_x64/  ?endif ?



-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 31 July 2013 17:26
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Classification: Public
Can't use WIXLIBS to replace the MERGEMODULES (Rob confirmed that with me)

I am installing 5 Services, they each go into a separate folder off the 
Services parent folder.

They share 8-10 WIXLIBS each (common files for each service, didn't make sense 
to create new component for each file 5 times)

Hence I can't use WIXLIBS for the Merge Modules nor can I throw everything into 
the Product.wxs since I would be repeating  files 5 times 10-20 files...

Was able to change 3 other installers from 2 solutions down to 1 solution and 
able to create x86 and x64 MSI's

Might just leave this one alone :(

Steve

-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: July-31-13 12:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

I did it by not using merge modules, I used pure wixlibs.

http://wyrdfish.wordpress.com/2011/01/05/32-and-64-bit-msis-from-a-single-sou
rce-file/

So my components are pulled into the msi by ComponentGroupRef not by MergeID.

I

Re: [WiX-users] Need help, how to put a condition on a merge module in Product.wxs [P]

[Steven Ogilvie]

Classification: Public
I build the solution twice, once as ReleaseX86 and then again for ReleaseX64 
(produces 2 MSI's, i.e. install_x86.msi, install_x64.msi) to answer:
Will happen at COMPILE/LINK time, so you will need to build the same project 
twice.  Once as 32 bit and once as 64 bit.

To answer:
A) do you need to support both 32 bit and 64 bit components on the same PC?
   No, we only install 1 on a machine, but the machine could be 32 bit or 64 
bit hence we have 2 MSI's

B) Is this component part of the wixlib, part of your product, or part of a 
megre module?
Sorry this is in the Product.wxs file (this was to ask about the diff about 
var.Platform vs sys.BUILDARCH

C) Are the number and name of destination files identical, just that they are 
sourced from a different lib folder?
Yes the name of the file is the same but the location is different lib\x86 
and lib\x64 

steve


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: July-31-13 2:56 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

I'm confused...

?if $(var.Platform) = x64 ?
  ?define Win=yes ?
  ?define PlatformProductName = $(var.ProductName) (64 bit) ?
  ?define PlatformProgramFilesFolder = ProgramFiles64Folder ?
  ?define PlatformCAQuietExecDLLEntry = CAQuietExec64?
  ?define PlatformQtExecCmdLine = QtExec64CmdLine?
  ?else ?
  ?define Win=no ?
  ?define PlatformProductName = $(var.ProductName) ?
  ?define PlatformProgramFilesFolder = ProgramFilesFolder ?
  ?define PlatformCAQuietExecDLLEntry = CAQuietExec?
  ?define PlatformQtExecCmdLine = QtExecCmdLine?
  ?endif ?

Will happen at COMPILE/LINK time, so you will need to build the same project 
twice.  Once as 32 bit and once as 64 bit.

As for 

Component Id=cmp_TL_DsoFileHooksDll_x64 
Guid={A7A293D2-D3FD-4616-BA75-C573F24512BD} Win64=$(var.Win)
  File Id=file_TL_DsoFileHooksDll_x64 KeyPath=yes 
Source=$(var.tcpSourcePath)\lib\x64\TL_DsoFileHooks.dll
   /File
  Condition
![CDATA[VersionNT64 OR $(var.Platform) = x64]]
  /Condition
/Component

I would ask a few things:
  A) do you need to support both 32 bit and 64 bit components on the same PC?
  B) Is this component part of the wixlib, part of your product, or part of a 
megre module?
  C) Are the number and name of destination files identical, just that they are 
sourced from a different lib folder?


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Wednesday, July 31, 2013 1:17 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Classification: Public
Nuts more files to change roger that, will change :)

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: July-31-13 2:05 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

I have a very similar include file in the installer that must build two 
platforms.  The only difference is that I replace $(var.Platform) with 
$(sys.BUILDARCH).  It has worked in production for nearly two years that way.

--
John Merryweather Cooper
Build  Install Engineer - ESA
Jack Henry  Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com 




-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Wednesday, July 31, 2013 12:50 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Classification: Public
Sigh, every example I see out there in Google land they use

?if $(var.Platform) = x64 ?
  ?define Win=yes ?
  ?define PlatformProductName = $(var.ProductName) (64 bit) ?
  ?define PlatformProgramFilesFolder = ProgramFiles64Folder ?
  ?define PlatformCAQuietExecDLLEntry = CAQuietExec64?
  ?define PlatformQtExecCmdLine = QtExec64CmdLine?
  ?else ?
  ?define Win=no ?
  ?define PlatformProductName = $(var.ProductName) ?
  ?define PlatformProgramFilesFolder = ProgramFilesFolder ?
  ?define PlatformCAQuietExecDLLEntry = CAQuietExec?
  ?define PlatformQtExecCmdLine = QtExecCmdLine?
  ?endif ?

And also this?

Component Id=cmp_TL_DsoFileHooksDll_x64 
Guid={A7A293D2-D3FD-4616-BA75-C573F24512BD} Win64=$(var.Win)
  File Id=file_TL_DsoFileHooksDll_x64 KeyPath=yes 
Source=$(var.tcpSourcePath)\lib\x64\TL_DsoFileHooks.dll
   /File
  Condition
![CDATA[VersionNT64 OR $(var.Platform) = x64]]
  /Condition
/Component
So your saying replace $(var.Platform) with $(sys.BUILDARCH) since the above 
code should run at runtime...

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: July-31-13 1:38 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re

Re: [WiX-users] Need help, how to put a condition on a merge module in Product.wxs [P]

[Steven Ogilvie]

Classification: Public
A.) On a 64 bit machine running 32 bit Office, we install the 32 bit MSI for 
out Plugins installer and our Client install

b) The component and file ID is different for both files one is cmp_filename 
the other is cmp_filename_x64, and file_filename the other file_filename_x64 
and of course the GUID is also different... BUT the actual installed file is 
the same file name...
i.e.
Component Id=cmp_SomefileDll Guid={A GUID} Permanent=no Shared=no
File Id=file_SomefileDll KeyPath=yes 
Source=$(var.tcpSourcePath)\lib\x86\Somefile.dll /
Condition
  ![CDATA[NOT(VersionNT64) OR $(sys.BUILDARCH) = x86]]
/Condition
  /Component
  Component Id=cmp_SomefileDll_x64 Guid={Another GUID} 
Win64=$(var.Win)
File Id=file_SomefileDll_x64 KeyPath=yes 
Source=$(var.tcpSourcePath)\lib\x64\Somefile.dll /
Condition
  ![CDATA[VersionNT64 OR $(sys.BUILDARCH) = x64]]
/Condition
  /Component

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: July-31-13 3:38 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

A) Ok, then you should probably have a conditional Condition element on the 32 
bit install to prevent the 32 bit MSI from installing on a 64 bit PC.

B) Knowing that,
Component Id=cmp_TL_DsoFileHooksDll  
Guid={A7A293D2-D3FD-4616-BA75-C573F24512BD} Win64=$(var.Win)
  File Id=file_TL_DsoFileHooksDll KeyPath=yes 
Source=$(var.tcpSourcePath)\lib\$(sys.BUILDARCH )\TL_DsoFileHooks.dll/ 
/Component

This will cause both the 64 bit and 32 bit components to have the same ID's but 
since you won't support both on the same PC it should not be a problem.


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Wednesday, July 31, 2013 2:09 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Classification: Public
I build the solution twice, once as ReleaseX86 and then again for ReleaseX64 
(produces 2 MSI's, i.e. install_x86.msi, install_x64.msi) to answer:
Will happen at COMPILE/LINK time, so you will need to build the same project 
twice.  Once as 32 bit and once as 64 bit.

To answer:
A) do you need to support both 32 bit and 64 bit components on the same PC?
   No, we only install 1 on a machine, but the machine could be 32 bit or 64 
bit hence we have 2 MSI's

B) Is this component part of the wixlib, part of your product, or part of a 
megre module?
Sorry this is in the Product.wxs file (this was to ask about the diff about 
var.Platform vs sys.BUILDARCH

C) Are the number and name of destination files identical, just that they are 
sourced from a different lib folder?
Yes the name of the file is the same but the location is different lib\x86 
and lib\x64 

steve


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: July-31-13 2:56 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

I'm confused...

?if $(var.Platform) = x64 ?
  ?define Win=yes ?
  ?define PlatformProductName = $(var.ProductName) (64 bit) ?
  ?define PlatformProgramFilesFolder = ProgramFiles64Folder ?
  ?define PlatformCAQuietExecDLLEntry = CAQuietExec64?
  ?define PlatformQtExecCmdLine = QtExec64CmdLine?
  ?else ?
  ?define Win=no ?
  ?define PlatformProductName = $(var.ProductName) ?
  ?define PlatformProgramFilesFolder = ProgramFilesFolder ?
  ?define PlatformCAQuietExecDLLEntry = CAQuietExec?
  ?define PlatformQtExecCmdLine = QtExecCmdLine?
  ?endif ?

Will happen at COMPILE/LINK time, so you will need to build the same project 
twice.  Once as 32 bit and once as 64 bit.

As for 

Component Id=cmp_TL_DsoFileHooksDll_x64 
Guid={A7A293D2-D3FD-4616-BA75-C573F24512BD} Win64=$(var.Win)
  File Id=file_TL_DsoFileHooksDll_x64 KeyPath=yes 
Source=$(var.tcpSourcePath)\lib\x64\TL_DsoFileHooks.dll
   /File
  Condition
![CDATA[VersionNT64 OR $(var.Platform) = x64]]
  /Condition
/Component

I would ask a few things:
  A) do you need to support both 32 bit and 64 bit components on the same PC?
  B) Is this component part of the wixlib, part of your product, or part of a 
megre module?
  C) Are the number and name of destination files identical, just that they are 
sourced from a different lib folder?


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Wednesday, July 31, 2013 1:17 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Classification: Public
Nuts more files to change roger that, will change :)

-Original Message-
From: John Cooper

Re: [WiX-users] Having trouble modifying a Built-in WixUI dialog set [P]

[Steven Ogilvie]

 agreement.
Any ideas would be appreciated.

Thanks,

Tony




This Email is covered by the Electronic Communication Privacy Act, 18 U.S.C 
2510-2521 and may be legally privileged. The information contained in this 
Email is intended only for the use of the individual or entity named above. If 
the reader of this message is not the intended recipient, or the employee or 
agent responsible to deliver it to the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this communication in error please 
immediately notify us by telephone and destroy the original message.
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent caught 
up. So what steps can you take to put your SQL databases under version control? 
Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-31-13 4:27:28 
PM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Need help, how to put a condition on a merge module in Product.wxs [P]

[Steven Ogilvie]

, but databases havent caught 
up. So what steps can you take to put your SQL databases under version control? 
Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are 
intended exclusively for the individual or entity to which it is addressed. The 
message, together with any attachment, may contain confidential and/or 
privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution is strictly prohibited. If you have received this message in 
error, please immediately advise the sender by reply email and delete all 
copies.


--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent caught 
up. So what steps can you take to put your SQL databases under version control? 
Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-30-13 10:16:47 
AM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Need help, how to put a condition on a merge module in Product.wxs [P]

[Steven Ogilvie]

Classification: Public
Damnit, I didn't think of that... I will try that thanks!

-Original Message-
From: David Connet [mailto:d...@agilityrecordbook.com]
Sent: July-30-13 11:10 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Assign them to a feature and condition the feature.

Dave



- Original Message -
From: Steven Ogilvie steven.ogil...@titus.com
To: General discussion for Windows Installer XML toolset. 
wix-users@lists.sourceforge.net
Cc: 
Sent: Tuesday, July 30, 2013 7:16 AM
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Classification: Public
The 5 merge modules have ComponentGroupRef Id=cmpgrp_Log4Net/ of about 10 
wixlibs The files in the MergeModules and WixLibs are built as AnyCPU however 
since I need to install the services for 64 bit OS and 32 bit OS I need two 
MSI's one for 32 and one for 64 bit

So I am not using any binary files that are specific for 32 bit or 64 bit, I 
just need to include the MergeModules in 1 product.wxs file The Merge Modules 
themselves are built x86 and x64 and are located in two different folders...

So the question is, HOW do I conditionally install the merge modules based on 
the OS bitness?

Thanks,

Steve

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent caught 
up. So what steps can you take to put your SQL databases under version control? 
Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-30-13 11:29:17 
AM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Need help, how to put a condition on a merge module in Product.wxs [P]

[Steven Ogilvie]

Classification: Public
Sigh same merge modules just compiled under x86 and x64

Get the error:

Error   49  The merge module 'EnterpriseServicesMM_x64' contains a file 
identifier, 
'fil2502525491FAEBF0E0D0ED1FE352E76D.9EFC3F5B_3D47_4233_A162_371DEF5D8E92', 
that is duplicated either in another merge module or in a File/@Id attribute.  
File identifiers must be unique.  Please change one of the file identifiers to 
a different value.C:\Dev\ Setup\Services_Setup\Product.wxs282 1 
  Services_Setup

Feature Id=MergeModulesX86
 Title=Merge modules for 32 bit OS
 Level=1
 Display=expand
 ConfigurableDirectory=DIRECTORY_PATH_SERVICES
  ...
  MergeRef Id=ServicesMergeModule/
  Condition Level=1
![CDATA[NOT(VersionNT64) OR $(var.Platform) = x86]]
  /Condition
/Feature
Feature Id=MergeModulesX64
 Title=Merge modules for 64 bit OS
 Level=1
 Display=expand
 ConfigurableDirectory=DIRECTORY_PATH_SERVICES
  ...
  MergeRef Id=ServicesMergeModule_x64/
  Condition Level=1
![CDATA[VersionNT64 OR $(var.Platform) = x64]]
  /Condition

...
Merge Id=ServicesMergeModule DiskId=1 
SourceFile=$(env.SharedServices)\Installers\wixlib\ServicesMergeModule.msm 
Language=1033/ ...
Merge Id=ServicesMergeModule_x64 DiskId=1 
SourceFile=$(env.SharedServices)\Installers\wixlibx64\ServicesMergeModule.msm 
Language=1033/

-Original Message-
From: David Connet [mailto:d...@agilityrecordbook.com]
Sent: July-30-13 11:10 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Assign them to a feature and condition the feature.

Dave



- Original Message -
From: Steven Ogilvie steven.ogil...@titus.com
To: General discussion for Windows Installer XML toolset. 
wix-users@lists.sourceforge.net
Cc: 
Sent: Tuesday, July 30, 2013 7:16 AM
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Classification: Public
The 5 merge modules have ComponentGroupRef Id=cmpgrp_Log4Net/ of about 10 
wixlibs The files in the MergeModules and WixLibs are built as AnyCPU however 
since I need to install the services for 64 bit OS and 32 bit OS I need two 
MSI's one for 32 and one for 64 bit

So I am not using any binary files that are specific for 32 bit or 64 bit, I 
just need to include the MergeModules in 1 product.wxs file The Merge Modules 
themselves are built x86 and x64 and are located in two different folders...

So the question is, HOW do I conditionally install the merge modules based on 
the OS bitness?

Thanks,

Steve

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent caught 
up. So what steps can you take to put your SQL databases under version control? 
Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-30-13 11:53:30 
AM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Need help, how to put a condition on a merge module in Product.wxs [P]

[Steven Ogilvie]

Classification: Public
Yup I have the configuration set in the Solution file for my Services Solution, 
and in each MergeModule WIXProj I have set up x86/x64 configurations so it is 
built twice once for x86 and once for x64 and placed in different folders 
wixlib/wixlibx64 (both merge modules and wixlibs)

So I have 1 MergeModule project / 1 wixlib project but multiple configurations 
to handle the x86/x64

Looks like I am pooched...

Steve

-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: July-30-13 12:11 PM
To: General discussion for Windows Installer XML toolset.; David Connet
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Isn't the win64 setting on the component so you need to build a 64bit and a
32 bit version of each merge module (or wixlib).
This is easily done with a shared .wxs file and a compilation setting.

I have 32 and 64 bit components all up my build tree just because one package 
needs a 32 and a 64 bit msi.

(another) Dave 


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 30 July 2013 16:54
To: David Connet; General discussion forWindows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Classification: Public
Sigh same merge modules just compiled under x86 and x64

Get the error:

Error   49  The merge module 'EnterpriseServicesMM_x64' contains a file
identifier,
'fil2502525491FAEBF0E0D0ED1FE352E76D.9EFC3F5B_3D47_4233_A162_371DEF5D8E92',
that is duplicated either in another merge module or in a File/@Id attribute.
File identifiers must be unique.  Please change one of the file identifiers
to a different value.   C:\Dev\ Setup\Services_Setup\Product.wxs282
1   Services_Setup

Feature Id=MergeModulesX86
 Title=Merge modules for 32 bit OS
 Level=1
 Display=expand
 ConfigurableDirectory=DIRECTORY_PATH_SERVICES
  ...
  MergeRef Id=ServicesMergeModule/
  Condition Level=1
![CDATA[NOT(VersionNT64) OR $(var.Platform) = x86]]
  /Condition
/Feature
Feature Id=MergeModulesX64
 Title=Merge modules for 64 bit OS
 Level=1
 Display=expand
 ConfigurableDirectory=DIRECTORY_PATH_SERVICES
  ...
  MergeRef Id=ServicesMergeModule_x64/
  Condition Level=1
![CDATA[VersionNT64 OR $(var.Platform) = x64]]
  /Condition

...
Merge Id=ServicesMergeModule DiskId=1
SourceFile=$(env.SharedServices)\Installers\wixlib\ServicesMergeModule.msm
Language=1033/ ...
Merge Id=ServicesMergeModule_x64 DiskId=1
SourceFile=$(env.SharedServices)\Installers\wixlibx64\ServicesMergeModule.ms
m Language=1033/

-Original Message-
From: David Connet [mailto:d...@agilityrecordbook.com]
Sent: July-30-13 11:10 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Assign them to a feature and condition the feature.

Dave



- Original Message -
From: Steven Ogilvie steven.ogil...@titus.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Cc: 
Sent: Tuesday, July 30, 2013 7:16 AM
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module in 
Product.wxs [P]

Classification: Public
The 5 merge modules have ComponentGroupRef Id=cmpgrp_Log4Net/ of about 10 
wixlibs The files in the MergeModules and WixLibs are built as AnyCPU however 
since I need to install the services for 64 bit OS and 32 bit OS I need two 
MSI's one for 32 and one for 64 bit

So I am not using any binary files that are specific for 32 bit or 64 bit, I 
just need to include the MergeModules in 1 product.wxs file The Merge Modules 
themselves are built x86 and x64 and are located in two different folders...

So the question is, HOW do I conditionally install the merge modules based on 
the OS bitness?

Thanks,

Steve

-
-
Get your SQL database under version control now!
Version control is standard for application code, but databases havent caught 
up. So what steps can you take to put your SQL databases under version control? 
Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-30-13
11:53:30 AM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



-
-
Get your SQL database under version control now!
Version control

Re: [WiX-users] WiX 3.6: SelectDbDlg [P]

[Steven Ogilvie]

Classification: Public
I have 5 custom dialogs that I created that I use in my WIX project, I didn't 
need to reference that...

Steve
-Original Message-
From: Wang, Miaohsi [mailto:miaohsi.w...@invensys.com]
Sent: July-26-13 1:01 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX 3.6: SelectDbDlg [P]

Hi Steve,

After googling more I found that I needed to add reference 
WixCommonUiExtension.dll to my WiX 3.6 project in Visual Studio 2010. However, 
as I did so, I got error that WixCommonUiExtension.dll is not a valid WiX 
reference. How can resolve this issue?

Thanks a lot!
Miaohsi

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Thursday, July 25, 2013 4:59 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX 3.6: SelectDbDlg [P]

Classification: Public
Did you add a dialogref to it as well? 
i.e.
in my product.wxs file I have:
DialogRef Id=GenericErrorDlg/

Then in my SQLConnectionDlog.wxs I have:
Publish Event=SpawnDialog Value=GenericErrorDlg 
Order=4![CDATA[DATABASE_CONNECTION_ERROR = 0]]/Publish

Steve

-Original Message-
From: Wang, Miaohsi [mailto:miaohsi.w...@invensys.com]
Sent: July-25-13 7:09 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] WiX 3.6: SelectDbDlg

Hello all,

I am trying to use SelectDbDlg in my WiX 3.6 project as shown below:

Publish Event=NewDialog Value=SelectDbDlg/Publish

When I built the install  program I got the error below:

error LGHT0094: Unresolved reference to symbol 'Dialog:SelectDbDlg' in section 
'Fragment:'

Note that I've included SqlExtension in the WiX element:

Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
 xmlns:sql=http://schemas.microsoft.com/wix/SqlExtension;
 xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; 

I've also added WixSqlExtension in the project References in my Visual Studio 
2010. What am I missing here?

Thanks a lot you for your help!
Miaohsi





*** Confidentiality Notice: This e-mail, including any associated or attached 
files, is intended solely for the individual or entity to which it is 
addressed. This e-mail is confidential and may well also be legally privileged. 
If you have received it in error, you are on notice of its status. Please 
notify the sender immediately by reply e-mail and then delete this message from 
your system. Please do not copy it or use it for any purposes, or disclose its 
contents to any other person. This email comes from a division of the Invensys 
Group, owned by Invensys plc, which is a company registered in England and 
Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 
7AW (Registered number 166023). For a list of European legal entities within 
the Invensys Group, please select the Legal Entities link at invensys.com.


You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail 
recept...@invensys.com. This e-mail and any attachments thereto may be subject 
to the terms of any agreements between Invensys (and/or its subsidiaries and 
affiliates) and the recipient (and/or its subsidiaries and affiliates).

--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-25-13 7:59:05 
PM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


*** Confidentiality Notice: This e-mail, including any associated or attached 
files, is intended solely for the individual or entity to which it is 
addressed. This e-mail is confidential and may well also be legally privileged. 
If you have received it in error, you are on notice of its status. Please 
notify the sender immediately by reply e-mail and then delete this message from 
your system. Please do not copy it or use it for any purposes, or disclose its

Re: [WiX-users] Custom action [P]

[Steven Ogilvie]

Classification: Public
You should NOT call any custom actions After InstallFinalize.

-Original Message-
From: Chaitanya Sanapala [PC-BLR-DEV] [mailto:chaita...@pointcross.com]
Sent: July-25-13 4:56 AM
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Custom action

Hi,

I'am using wix 3.5,I am using customa action for installing the IIS files.
some of the custom actions is in Before Install Finalize  some are from after 
install finalize I'm using some of files to install after Installfinalize 
through custom action.
At that time custom action is calling the command prompt and throwing the 
Finish window out of the screen..
I want to know how to avoid that..???
Is is there any timer to set the custom action to call???

Regards,
chaitanya


--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-25-13 9:08:18 
AM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Custom action [P]

[Steven Ogilvie]

Classification: Public
Darn my bad, I should have stated the Before :)

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: July-25-13 12:01 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Custom action [P]

Slight amendment: You should NOT call any custom actions **that modify machine 
state Before InstallInitialize or** After InstallFinalize 


On Thu, Jul 25, 2013 at 6:08 AM, Steven Ogilvie steven.ogil...@titus.comwrote:

 Classification: Public
 You should NOT call any custom actions After InstallFinalize.

 -Original Message-
 From: Chaitanya Sanapala [PC-BLR-DEV] 
 [mailto:chaita...@pointcross.com]
 Sent: July-25-13 4:56 AM
 To: WiX-users@lists.sourceforge.net
 Subject: [WiX-users] Custom action

 Hi,

 I'am using wix 3.5,I am using customa action for installing the IIS files.
 some of the custom actions is in Before Install Finalize  some are 
 from after install finalize I'm using some of files to install after 
 Installfinalize through custom action.
 At that time custom action is calling the command prompt and throwing 
 the Finish window out of the screen..
 I want to know how to avoid that..???
 Is is there any timer to set the custom action to call???

 Regards,
 chaitanya



 --
  See everything from the browser to the database with 
 AppDynamics Get end-to-end visibility with application monitoring from 
 AppDynamics Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.c
 lktrk ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


 This message has been marked as Public by Steven Ogilvie on July-25-13
 9:08:18 AM.

 The above classification labels were added to the message by TITUS 
 Message Classification. For more information visit www.titus.com.






 --
  See everything from the browser to the database with 
 AppDynamics Get end-to-end visibility with application monitoring from 
 AppDynamics Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.c
 lktrk ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-25-13 1:51:37 
PM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX 3.6: SelectDbDlg [P]

[Steven Ogilvie]

Classification: Public
Did you add a dialogref to it as well? 
i.e.
in my product.wxs file I have:
DialogRef Id=GenericErrorDlg/

Then in my SQLConnectionDlog.wxs I have:
Publish Event=SpawnDialog Value=GenericErrorDlg 
Order=4![CDATA[DATABASE_CONNECTION_ERROR = 0]]/Publish

Steve

-Original Message-
From: Wang, Miaohsi [mailto:miaohsi.w...@invensys.com]
Sent: July-25-13 7:09 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] WiX 3.6: SelectDbDlg

Hello all,

I am trying to use SelectDbDlg in my WiX 3.6 project as shown below:

Publish Event=NewDialog Value=SelectDbDlg/Publish

When I built the install  program I got the error below:

error LGHT0094: Unresolved reference to symbol 'Dialog:SelectDbDlg' in section 
'Fragment:'

Note that I've included SqlExtension in the WiX element:

Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
 xmlns:sql=http://schemas.microsoft.com/wix/SqlExtension;
 xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; 

I've also added WixSqlExtension in the project References in my Visual Studio 
2010. What am I missing here?

Thanks a lot you for your help!
Miaohsi





*** Confidentiality Notice: This e-mail, including any associated or attached 
files, is intended solely for the individual or entity to which it is 
addressed. This e-mail is confidential and may well also be legally privileged. 
If you have received it in error, you are on notice of its status. Please 
notify the sender immediately by reply e-mail and then delete this message from 
your system. Please do not copy it or use it for any purposes, or disclose its 
contents to any other person. This email comes from a division of the Invensys 
Group, owned by Invensys plc, which is a company registered in England and 
Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 
7AW (Registered number 166023). For a list of European legal entities within 
the Invensys Group, please select the Legal Entities link at invensys.com.


You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail 
recept...@invensys.com. This e-mail and any attachments thereto may be subject 
to the terms of any agreements between Invensys (and/or its subsidiaries and 
affiliates) and the recipient (and/or its subsidiaries and affiliates).

--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-25-13 7:59:05 
PM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installing MSMQ as dependency [P]

[Steven Ogilvie]

 ActionResult.Failure;
}

return ActionResult.Success;
}


private class Os
{
/// summary
/// The OS ANYSERVER.
/// /summary
[SuppressMessage(StyleCop.CSharp.NamingRules, 
SA1310:FieldNamesMustNotContainUnderscore, Justification = Reviewed. 
Suppression is OK here.)] // ReSharper disable InconsistentNaming
private const int OS_ANYSERVER = 29; // ReSharper restore 
InconsistentNaming

/// summary
/// Prevents a default instance of the see cref=Os/ class from 
being created. 
/// /summary
private Os()
{
}

/// summary
/// The is windows server.
/// /summary
/// returns
/// The see cref=bool/.
/// /returns
public static bool IsWindowsServer()
{
return Os.IsOS(OS_ANYSERVER);
}

[DllImport(shlwapi.dll, SetLastError = true, EntryPoint = #437)]
private static extern bool IsOS(int os);
}

Steve


-Original Message-
From: José Marques [mailto:jose.marq...@waveform.pt]
Sent: July-24-13 6:18 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Installing MSMQ as dependency

Hello all,

On the installer I'm currently developing, I need to install Microsoft Message 
Queue (MSMQ) as a dependency. Depending on Windows version, I need to run 
ocsetup.exe or sysocmgr.exe. No issues with ocsetup, my problem relies with 
sysocmgr.
So far I've thought of two ways to do it: add an ExePackage to my existing 
bundle, or setting a custom action.
Either way, the issues I'm currently having is:

- If i do it in the bundle, i need to provide the .exe file, which I think it 
is not recommended, I have to call it. (correct me if I'm wrong)
- I need to pass a file with MSMQ options as a parameter, is this possible?
(I didn't anything remotely close with this)

If there's another simple and/or correct way of installing MSMQ let me know as 
well :)

Thank you for your help,

José Marques
--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-24-13 9:09:47 
AM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installing MSMQ as dependency [P]

[Steven Ogilvie]

Classification: Public
I have written a custom action C# DLL

The custom action is called within the product.wxs:

CustomAction Id=CA_SetCHECKFORMSMQ Property=CA_CHECKFORMSMQ 
Value=$(var.ProductName)/
CustomAction Id=CA_CHECKFORMSMQ BinaryKey=BIN_CustomAction 
DllEntry=CheckToSeeIfMSMQIsInstalled Impersonate=no Execute=deferred 
Return=check/
UI
  ProgressText Action=CA_CHECKFORMSMQCA: Checking for Microsoft Message 
Queuing Service (MSMQ).../ProgressText
/UI

Custom Action=CA_SetCHECKFORMSMQ After=CostFinalizeNOT Installed/Custom 
Custom Action=CA_CHECKFORMSMQ After=InstallInitializeNOT 
Installed/Custom

-Original Message-
From: José Marques [mailto:jose.marq...@waveform.pt]
Sent: July-24-13 9:22 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing MSMQ as dependency [P]

Thank you for your reply.
I am a bit new to Wix, as this is the first time I'm making an installer, where 
exactly do you write that code? I presume it's not straight into the xml, but 
so far I only have written XML...

Best regards,
José

On Wed, Jul 24, 2013 at 2:09 PM, Steven Ogilvie steven.ogil...@titus.comwrote:

 Classification: Public
 I have the same requirements and ended up writing a custom action to 
 do the work for me:
 From Windows 7/8/2008R2/2012 I use Dism.exe for OS's below I use
 ocsetup.exe (we use MSMQ for our Server product and our Client 
 product), however Microsoft being so consistent (being sarcastic) the 
 features for MSMQ change from OS to OS :( so I ended up doing something like 
 this:
 [CustomAction]
 public static ActionResult CheckToSeeIfMSMQIsInstalled(Session
 session)
 {
 var productName = string.Empty;
 try
 {
 if (session == null)
 {
 throw new ArgumentNullException(session);
 }

 var tempString = GetSessionProperty(session, 
 CustomActionData, false);
 var parts = tempString.Split(new[] { '|' });
 productName = parts[0];

 var serviceExists =
 ServiceController.GetServices().Any(s
 = s.ServiceName == MSMQ);
 if (!serviceExists)
 {
 var platformVersion = 
 Environment.OSVersion.VersionString;

 var cmdLineParameters = string.Empty;
 if (platformVersion.Contains(6.0.600) 
 !Os.IsWindowsServer())
 {
 // Windows Vista
 cmdLineParameters = 
 MSMQ-Container;MSMQ-Server /quiet /norestart;
 }
 else if ((platformVersion.Contains(6.1.760) 
 !Os.IsWindowsServer())
  || (platformVersion.Contains(6.2.920)
 
 !Os.IsWindowsServer()))
 {
 // Windows 7 and Windows 8
 cmdLineParameters = /Online /NoRestart 
 /Enable-Feature /featurename:MSMQ-Container /featurename:MSMQ-Server;
 }
 else if (platformVersion.Contains(6.1.760) 
 Os.IsWindowsServer())
 {
 // Windows Server 2008 R2
 cmdLineParameters = /Online /NoRestart 
 /Enable-Feature /featurename:MSMQ-Server;
 }
 else if (platformVersion.Contains(6.2.920) 
 Os.IsWindowsServer())
 {
 // Windows Server 2012
 cmdLineParameters = /Online /NoRestart 
 /Enable-Feature /featurename:MSMQ /featurename:MSMQ-Services 
 /featurename:MSMQ-Server;
 }

 string cmdLineExe;
 if (platformVersion.Contains(6.0.600) 
 !Os.IsWindowsServer())
 {
 // Windows Vista
 cmdLineExe =
 Environment.GetFolderPath(Environment.SpecialFolder.System) + 
 \\ocsetup.exe;
 }
 else
 {
 // Windows 7 / 8 / 2008R2 / 2012
 var system32Directory = 
 Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Windo
 ws),
 system32);
 if (Environment.Is64BitOperatingSystem 
 !Environment.Is64BitProcess)
 {
 // For 32-bit processes on 64-bit systems,
 %windir%\system32 folder
 // can only be accessed by specifying 
 %windir%\sysnative folder.
 system32Directory = 
 Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Windo
 ws),
 sysnative);
 }

 // Windows 7 / 8 / 2008R2 / 2012
 cmdLineExe = system32Directory + \\dism.exe;
 }

 // Install MSMQ if missing

Re: [WiX-users] prompt for administrator account during major upgrade [P]

[Steven Ogilvie]

Classification: Public
Is this a custom action you are using?

Anyway you could use something like:
Custom Action=MyCustomAction After=some sequence NOT 
WIX_UPGRADE_DETECTED/Custom

-Original Message-
From: Mike Myers [mailto:mike.my...@naucountry.com]
Sent: July-24-13 11:02 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] prompt for administrator account during major upgrade

I have a wix install with burn bootstrapper.  My situation deals with a 
non-administrator installing this on a machine.  The user is prompted for an 
administrator account.  When a major upgrade happens, the user is prompted for 
an administrator account again.  Is there any way to prevent a user from being 
prompted during the upgrade?

Thanks
-Mike



This electronic message from NAU Country Insurance Company and any attachment 
to it is intended exclusively for the individual or entity to which it is 
addressed. It may contain information that is privileged, confidential and 
exempt from disclosure under applicable law. Any unauthorized disclosure, 
copying, distribution or use of this electronic message or any attachment is 
prohibited. If you have received this message in error, please return it to the 
sender and delete this original from your system.

3483950 - 24 Jul 2013 15:02:32 -
--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-24-13 11:29:05 
AM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RemotePayload causes error LGHT0103: The system cannot find the file '' with type ''. [P]

[Steven Ogilvie]

:


ExePackage Name='data\dotnetfx35.exe'
  SourceFile='lt;path to
package\Microsoft\dotnetframework\DotNet3.5SP1\Full\dotnetfx35.exe'
  PerMachine='yes' Permanent='yes' Cache='yes'
CacheId='dotNetFx3.51' /


I also checked the Bugs for this RemotePayload issue, raised previously, but 
did not find it reported.  Should it be?

Any advise on how to install .Net 3.5 as I expect that running the Microsoft 
package will not work on Windows 7 or later without also writing some kind of a 
CA to call DISM.

Phill



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RemotePayload-causes-error-LGHT0103-The-system-cannot-find-the-file-with-type-tp7587545.html
Sent from the wix-users mailing list archive at Nabble.com.

--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-24-13 11:32:19 
AM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] prompt for administrator account during major upgrade [P]

[Steven Ogilvie]

Classification: Public
How are you asking the user to give the administrator account then?

-Original Message-
From: Mike Myers [mailto:mike.my...@naucountry.com]
Sent: July-24-13 11:43 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] prompt for administrator account during major upgrade 
[P]

I do not have any custom actions in my install beyond what is included in wix.

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Wednesday, July 24, 2013 10:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] prompt for administrator account during major upgrade 
[P]

Classification: Public
Is this a custom action you are using?

Anyway you could use something like:
Custom Action=MyCustomAction After=some sequence NOT 
WIX_UPGRADE_DETECTED/Custom

-Original Message-
From: Mike Myers [mailto:mike.my...@naucountry.com]
Sent: July-24-13 11:02 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] prompt for administrator account during major upgrade

I have a wix install with burn bootstrapper.  My situation deals with a 
non-administrator installing this on a machine.  The user is prompted for an 
administrator account.  When a major upgrade happens, the user is prompted for 
an administrator account again.  Is there any way to prevent a user from being 
prompted during the upgrade?

Thanks
-Mike



This electronic message from NAU Country Insurance Company and any attachment 
to it is intended exclusively for the individual or entity to which it is 
addressed. It may contain information that is privileged, confidential and 
exempt from disclosure under applicable law. Any unauthorized disclosure, 
copying, distribution or use of this electronic message or any attachment is 
prohibited. If you have received this message in error, please return it to the 
sender and delete this original from your system.

3483950 - 24 Jul 2013 15:02:32 -
--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-24-13 11:29:05 
AM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



This electronic message from NAU Country Insurance Company and any attachment 
to it is intended exclusively for the individual or entity to which it is 
addressed. It may contain information that is privileged, confidential and 
exempt from disclosure under applicable law. Any unauthorized disclosure, 
copying, distribution or use of this electronic message or any attachment is 
prohibited. If you have received this message in error, please return it to the 
sender and delete this original from your system.

3484761 - 24 Jul 2013 15:43:06 -


--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-24-13 11:50:44 
AM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro

Re: [WiX-users] Updating msi database (install time) [P]

[Steven Ogilvie]

Classification: Public
Enrique,

Why are you using a custom action to change the banner of the MSI? There is a 
WIX element to do that:
WixVariable Overridable=yes Id='WixUIBannerBmp' 
Value=$(var.resourcePath)\TFSTopBanner.bmp/
 WixVariable Overridable=yes Id='WixUIDialogBmp' 
Value=$(var.resourcePath)\TFSSide.bmp/

Regards,

Steve

-Original Message-
From: Enrique Domínguez [mailto:edoming...@goalsystems.com]
Sent: July-23-13 7:04 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Updating msi database (install time)

Hi, I'm working with wix-3.6 over VS2005 and I'm trying to make an update in a 
custom action at install time, for changing installer's banners. It's C# code 
and looks like:
  
Microsoft.Deployment.WindowsInstaller.Database db = session.Database;
string stSQL = @UPDATE `Control` SET `Text`=? WHERE 
`Type`='Bitmap' AND `Control`='BannerBitmap';
Microsoft.Deployment.WindowsInstaller.Record rc = 
db.CreateRecord(1);
Microsoft.Deployment.WindowsInstaller.View 
vw=db.OpenView(stSQL);
rc.SetString(1, MyBannerBmp);
vw.Execute(rc);
rc.SetString(1, MyDialogBmp);
vw.Execute(rc);
But UPDATE always fails with: 'Database Table(s) Update Failed' at vw.Execute 
line. I have tested a couple of different ways, always failing. Please, could 
somebody pointing me in right direction?
I suppose as I was able to update PROPERTIES, I could update Control table 
fields.
Thanks a lot. Best regards,
Enrique Dominguez

--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-23-13 9:05:51 
AM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] passing command args to MSI from bundle [P]

[Steven Ogilvie]

 --
util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\InetStp 
Result=value Value=MajorVersion Variable=IISVersion /
util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\InetStp 
Result=value Value=MajorVersion Variable=IISx64Version Win64=yes /

!-- Check that IIS exists --
util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\InetStp 
Result=exists Value=MajorVersion Variable=IISExists /
util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\InetStp 
Result=exists Value=MajorVersion Variable=IISx64Exists Win64=yes /

!-- Check for .NET 4.0 --
WixVariable Id=WixMbaPrereqPackageId Value=Netfx4Full /
util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\Net Framework 
Setup\NDP\v4\Full Value=Version Variable=Netfx4FullVersion /
util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\Net Framework 
Setup\NDP\v4\Full Value=Version Variable=Netfx4x64FullVersion Win64=yes 
/

PackageGroup Id=Netfx4Full
  ExePackage Id=Netfx4Full
  DisplayName=Microsoft .NET Framework 4.0
  Cache=no
  Compressed=no
  PerMachine=yes
  Permanent=yes
  Protocol=netfx4
  Vital=yes
  SourceFile=..\PreReqs\dotNetFx40_Full_x86_x64.exe
  Name=RedistServerAC\dotNetFx40_Full_x86_x64.exe
  InstallCommand=/passive /norestart
  DetectCondition=Netfx4FullVersion AND (NOT VersionNT64 OR 
Netfx4x64FullVersion) /
/PackageGroup

!-- Check for SQL Server Express --
!-- Read SQL Server keys to find current instance and version --
util:RegistrySearch Id=SQLExpress_Check Root=HKLM 
Key=SOFTWARE\Microsoft\Microsoft SQL Server\SQLEXPRESS\Setup Value=SQLPath 
Format=raw Result=value Variable=SQLExpress_Path /
util:RegistrySearch Id=SQLExpress_Checkx64 Root=HKLM 
Key=SOFTWARE\Microsoft\Microsoft SQL Server\SQLEXPRESS\Setup Value=SQLPath 
Format=raw Result=value Variable=SQLExpress_Pathx64 Win64=yes /
util:FileSearch Result=exists Path=[SQLExpress_Path]\Binn\sqlservr.exe 
Variable=SQLExpress_Exist After=SQLExpress_Check/
util:FileSearch Result=exists 
Path=[SQLExpress_Pathx64]\Binn\sqlservr.exe Variable=SQLExpress_Existx64 
After=SQLExpress_Checkx64/

  /Fragment
/Wix

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu] 
Sent: July-23-13 7:36 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

I did'nt realize it was overwriting the wix generated bootstrapper. The intent 
is to not have to reproduce the logic of all the pre-reqs I need to include, 
like .NET 3.5, .NET 4, SQL Server, but seems to undo all the wix-specifics I'm 
setting up. I guess the real answer here is to not rely on the 
GenerateBootstrapper task, but I'm not ready to reproduce all the bootstrapper 
logic that's already provided to me.

I was looking at this Stack Overflow question, and others, for a bootstrapper 
guide:
http://stackoverflow.com/questions/1128734/how-do-i-make-a-wix-installer-with-a-completely-self-contained-net-3-5-sp1-inst


Mark Freedman


-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: Monday, July 22, 2013 2:13 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

It's redundant and probably a significant source of the problem.  It should be 
removed or at least commented out so he knows which bootstrapper he's actually 
debugging.

--
John Merryweather Cooper
Build  Install Engineer - ESA
Jack Henry  Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com




-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 12:13 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
Then what is the purpose of using MSBuild + WIX bundle + WIX MSI that seems 
like an overkill?

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: July-22-13 12:50 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Old MsBuild/Visual Studio task that takes a manifest, a set of dependencies 
usually embedded in the project file, and builds a primitive bootstrapper.  We 
used to use it before they hired me.

--
John Merryweather Cooper
Build  Install Engineer - ESA
Jack Henry  Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com




-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 11:34 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from

Re: [WiX-users] Product Version functions [P]

[Steven Ogilvie]

Classification: Public
Who uses C++ for custom actions? Use C# :)

-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: July-23-13 3:53 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Product Version functions

If you're referring to file versions, I wouldn't be surprised if it's not made 
available because it's not that complicated to just call
MsiGetFileVersion() and parse the results.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa370122(v=vs.85).as
px

Phil  

-Original Message-
From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk]
Sent: Monday, July 22, 2013 10:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Product Version functions

Hi,
What I need to do is get the product version (major/minor/build/release from a 
file during a custom action.
I could write this, but wondered whether this is already included.
Cheers
Sean.

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 23 July 2013 04:40
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Product Version functions

Always better to start with what you are trying to accomplish rather than ask a 
very narrow question with no context.


On Mon, Jul 22, 2013 at 3:18 PM, Sean Farrow
sean.far...@seanfarrow.co.ukwrote:

 Hi,
 I'm just in the process of writing a custom action, I know file 
 version functions are in fileutil.cpp/h. Are Product version functions 
 surfaced by WiX dutil?
 Regards
 Sean.

 --
  See everything from the browser to the database with 
 AppDynamics Get end-to-end visibility with application monitoring from 
 AppDynamics Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.c
 lktrk ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-23-13 3:59:25 
PM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Product Version functions [P]

[Steven Ogilvie]

Classification: Public
I was being a smartss :)

-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: July-23-13 4:06 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Product Version functions [P]

The original reference was to a .cpp file, so I assumed C++ was needed ;) 

You can use your FileVersionInfo.FileVersion if you insist ;)   

Phil  

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Tuesday, July 23, 2013 12:59 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Product Version functions [P]

Classification: Public
Who uses C++ for custom actions? Use C# :)

-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: July-23-13 3:53 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Product Version functions

If you're referring to file versions, I wouldn't be surprised if it's not made 
available because it's not that complicated to just call
MsiGetFileVersion() and parse the results.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa370122(v=vs.85).as
px

Phil  

-Original Message-
From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk]
Sent: Monday, July 22, 2013 10:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Product Version functions

Hi,
What I need to do is get the product version (major/minor/build/release from a 
file during a custom action.
I could write this, but wondered whether this is already included.
Cheers
Sean.

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 23 July 2013 04:40
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Product Version functions

Always better to start with what you are trying to accomplish rather than ask a 
very narrow question with no context.


On Mon, Jul 22, 2013 at 3:18 PM, Sean Farrow
sean.far...@seanfarrow.co.ukwrote:

 Hi,
 I'm just in the process of writing a custom action, I know file 
 version functions are in fileutil.cpp/h. Are Product version functions 
 surfaced by WiX dutil?
 Regards
 Sean.

 --
  See everything from the browser to the database with 
 AppDynamics Get end-to-end visibility with application monitoring from 
 AppDynamics Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.c
 lktrk ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-23-13
3:59:25 PM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 




--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics

Re: [WiX-users] passing command args to MSI from bundle [P]

[Steven Ogilvie]

Classification: Public
Take out the Value out of your Product.wxs i.e.: Property Id=SETLOCALDB 
Secure=yes  /

Set the default value of the property in the bundle.wxs so it is passed on to 
the MSI, that way you have the default value but you can change it via the 
command line to change it...

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 8:06 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

I've tried Steven's method of defining a variable and assigning it to the 
MsiProperty, as well not using a burn variable and just using the MSI Property 
with a constant. When I have the Property defined in my product.wxs, it is 
always set to the defaulted value set in the product.wxs. The value that I set 
in the bundle.wxs doesn't seem to carry over the MSI.

The custom action where I'm setting the custom data property is after 
InstallFiles.


In Bundle.wxs:
Variable Name=SETLOCALDB Persisted=yes Type=string Value=true 
bal:Overridable=yes /

  MsiPackage Id=MyInstaller SourceFile=$(var.MyInstaller.TargetPath) 
Compressed=no  
MsiProperty Name=SETLOCALDB Value=[SETLOCALDB] /
  /MsiPackage


Product.wxs
Property Id=SETLOCALDB Secure=yes Value=false  /

  Custom Action=SetUsingLocalDbRegistryAction.SetProperty 
After=InstallFilesNOT REMOVE/Custom
  Custom Action=SetUsingLocalDbRegistryAction 
After=SetUsingLocalDbRegistryAction.SetPropertyNOT REMOVE/Custom

CustomAction.wxs:
CustomAction Id='SetUsingLocalDbRegistryAction.SetProperty' Return='check'
  Value='SETLOCALDB=[SETLOCALDB]' 
Property='SetUsingLocalDbRegistryAction'/

CustomAction Id='SetUsingLocalDbRegistryAction' 
BinaryKey='CustomActionBinary' DllEntry='SetUsingLocalDbRegistry'
  Execute='deferred' Impersonate='no' Return='check'/

Mark Freedman


-Original Message-
From: Blair Murri [mailto:os...@live.com]
Sent: Sunday, July 21, 2013 3:07 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Mark, you simply need to use an MsiProperty element as a child to your 
MsiPackage one. A burn variable is only involved if you are not hardcoding the 
value you are passing to MSI.

 From: steven.ogil...@titus.com
 To: wix-users@lists.sourceforge.net
 Date: Fri, 19 Jul 2013 18:53:53 +
 Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

 Classification: Public
 Mark,

 In my bundle.wxs I have the following:

 /BootstrapperApplicationRef
 Variable Name=SERVICESLOGLEVEL Type=string
 bal:Overridable=yes Value=WARN/

 Chain
 MsiPackage Id=MainInstall
 DisplayName=$(var.ProductName)
 SourceFile=path to my MSI file\MyMSIFile.msi
 Name=Redist\ MyMSIFile.msi 
 DisplayInternalUI=yes
 Visible=no
 Cache=no
 Compressed=no
 Permanent=no
   MsiProperty Name=SERVICESLOGLEVEL Value=[SERVICESLOGLEVEL]/
 /MsiPackage

 This way if I don't have a command line argument the MSI property 
 SERVICESLOGLEVEL is set to WARN by default, hence I can change it by:
 MYBOOSTRAPPEREXE.exe SERVICESLOGLEVEL=DEBUG

 Then in my product.wxs file I have the property initialized:
 Property Id=SERVICESLOGLEVEL Secure=yes/

 And then I use that property in a custom action to change the app.config file 
 of my various services logging level i.e.

 CustomAction Id=CA_Set_ConfigLevelStr Property=CA_SETCONFIGLEVELSTR 
 Value=[CONFIG_SERVICE_PATH]|Config.exe.config|[SERVICESLOGLEVEL]/
 CustomAction Id=CA_SETCONFIGLEVELSTR
 BinaryKey=BIN_CustomAction DllEntry=ChangeConfigLevel
 Impersonate=no Execute=deferred Return=check /

 So if I don't have a command line parameter to the logging level is set to 
 the default WARN (which is set in my variable element in the bundle.wxs, or I 
 can change the logging level by having a command line parameter as shown 
 above...

 Steve

 -Original Message-
 From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
 Sent: July-19-13 2:31 PM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

 Right, My bootstrapper projct creates the exe, and I can run it and install 
 with it. I'm not sure what's happening to the MsiProperty that Ive set up. 
 I'm not sure how to read it from the MSI installer package, and it isn't 
 passed as a command line argument as shown in the logs.

 I thin what I want to do is to read the MSI property and store it in a 
 CustomActionData property to be read by a custom action, but does not seem to 
 work.

 Mark Freedman
 JHU/APL
 17-N568
 443.778.2647
 mark.freed...@jhuapl.edu


 -Original Message-
 From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
 Sent: Friday, July 19

Re: [WiX-users] passing command args to MSI from bundle [P]

[Steven Ogilvie]

Classification: Public
Nope the property I have is a made up property that I use... in the bundle.wxs 
I set the default value to WARN which is passed onto the MSI and my custom 
action uses it.
I can change the value via the command line i.e.: MYBootstrapper.exe 
SERVICESLOGLEVEL=DEBUG which would overwrite the default value WARN to DEBUG...

Bundle.wxs:
Variable Name=SERVICESLOGLEVEL Type=string bal:Overridable=yes 
Value=WARN/

Chain
...
MsiPackage Id=MainInstall
  DisplayName=$(var.ProductName)
  DisplayInternalUI=no
  SourceFile=$(env.TLSharedServices)\Installers\_Setup.msi
  Name=RedistServerAC\Setup.msi
  Visible=no
  Cache=no
  Compressed=no
  Permanent=no
MsiProperty Name=WEBAPPPOOL_USERNAME Value=NetworkService/
MsiProperty Name=ALLOW_REMOTE_ACCESS Value=0/
MsiProperty Name=SERVICESLOGLEVEL Value=[SERVICESLOGLEVEL]/
MsiProperty Name=SERVERLESSINSTALL Value=1/
  /MsiPackage

Product.wxs:
Property Id=SERVICESLOGLEVEL Secure=yes/

CustomAction Id=CA_Set_WebLogLevel Property=CA_WEBLOGLEVEL 
Value=[DIRECTORY_PATH_SERVER]|Web.config|[SERVICESLOGLEVEL]/
CustomAction Id=CA_WEBLOGLEVEL BinaryKey=BIN_CustomAction 
DllEntry=ChangeConfigLoggingLevel Impersonate=no Execute=deferred 
Return=check /
UI
  ProgressText Action=CA_WEBLOGLEVELCA: Configuring the logging level 
for Web.Config.../ProgressText
/UI

Custom Action=CA_Set_WebLogLevel After= InstallValidateNOT 
Installed/Custom Custom Action=CA_WEBLOGLEVEL After= InstallFiles NOT 
Installed/Custom

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 9:25 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Thanks Steven,

I tried that as well, not defaulting the value in the Product.wxs and it seems 
that when the MSI takes over, the value of the property is empty string or 
null. If I do call my setup.exe via commandline, I am able to set it and it 
picks it up in the MSI.  Is your MSI Property in the example below a built in 
property, and there's an issue with mine being one I created?

Variable Name=SETLOCALDB Type=string Value=true 
bal:Overridable=yes /
  MsiPackage Id=OperatorStationInstaller 
SourceFile=$(var.OperatorStationInstaller.TargetPath) Compressed=no
MsiProperty Name=SETLOCALDB Value=[SETLOCALDB] /
  /MsiPackage


Property Id=SETLOCALDB Secure=yes/



Mark Freedman


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 9:17 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
Take out the Value out of your Product.wxs i.e.: Property Id=SETLOCALDB 
Secure=yes  /

Set the default value of the property in the bundle.wxs so it is passed on to 
the MSI, that way you have the default value but you can change it via the 
command line to change it...

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 8:06 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

I've tried Steven's method of defining a variable and assigning it to the 
MsiProperty, as well not using a burn variable and just using the MSI Property 
with a constant. When I have the Property defined in my product.wxs, it is 
always set to the defaulted value set in the product.wxs. The value that I set 
in the bundle.wxs doesn't seem to carry over the MSI.

The custom action where I'm setting the custom data property is after 
InstallFiles.


In Bundle.wxs:
Variable Name=SETLOCALDB Persisted=yes Type=string Value=true 
bal:Overridable=yes /

  MsiPackage Id=MyInstaller SourceFile=$(var.MyInstaller.TargetPath) 
Compressed=no  
MsiProperty Name=SETLOCALDB Value=[SETLOCALDB] /
  /MsiPackage


Product.wxs
Property Id=SETLOCALDB Secure=yes Value=false  /

  Custom Action=SetUsingLocalDbRegistryAction.SetProperty 
After=InstallFilesNOT REMOVE/Custom
  Custom Action=SetUsingLocalDbRegistryAction 
After=SetUsingLocalDbRegistryAction.SetPropertyNOT REMOVE/Custom

CustomAction.wxs:
CustomAction Id='SetUsingLocalDbRegistryAction.SetProperty' Return='check'
  Value='SETLOCALDB=[SETLOCALDB]' 
Property='SetUsingLocalDbRegistryAction'/

CustomAction Id='SetUsingLocalDbRegistryAction' 
BinaryKey='CustomActionBinary' DllEntry='SetUsingLocalDbRegistry'
  Execute='deferred' Impersonate='no' Return='check'/

Mark Freedman


-Original Message-
From: Blair Murri [mailto:os...@live.com]
Sent: Sunday, July 21, 2013 3:07 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI

Re: [WiX-users] passing command args to MSI from bundle [P]

[Steven Ogilvie]

Classification: Public
Sorry Mark,

I am not familiar with Generatebootstrapper what is that?

Steve

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 12:15 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Steve,

Correct, I do not see the logs.

I experimented with removing my GenerateBootstrapper task as I mentioned 
before, reproduced below. I then see the log file show up, and I see similar 
log files as you have described, and the variable SETLOCALDB set to 'true' as 
you would expect. The problem is, I am relying on the GenerateBootstrapper 
post-build task to gather up my bootstrappers. It seems that running 
GenerateBootstrapper clobbers specifics that I put in my Bundle.wxs

  Target Name=AfterBuild
GenerateBootstrapper ApplicationFile=My Installer.msi 
ApplicationName=My App BootstrapperItems=@(BootstrapperFile) 
ComponentsLocation=Relative CopyComponents=True OutputPath=$(OutputPath) 
Path=..\..\Bootstrapper /
  /Target

Mark Freedman
JHU/APL
17-N568
443.778.2647
mark.freed...@jhuapl.edu


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 12:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
If you run your bootstrapper exe (burn.wxs) then through it run the MSI, you 
don't see any log files in your %temp% folder?

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 11:49 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Steven,

I see what you're doing and it all makes sense.
I can't find any logs files where you describe, or any log files that include 
my bundle name. I do see an install.log, but doesn't mention the defaulted 
MsiProperty I'm trying to set, nor does it have the date/time stamps like the 
excerpt you're showing below.

I'm on Wix 3.7.1224.0, building on a win 7 machine

Mark Freedman
JHU/APL
17-N568
443.778.2647
mark.freed...@jhuapl.edu


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 11:30 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
The log files from the bundle are placed in %temp% are i.e.: Name of 
bundle_datetime.log

Weird, try taking out the Persisted=yes out of the variable element in your 
bundle.wxs

Btw what version of WIX are you using?

My bundle log shows this:
[2364:27B0][2013-07-22T11:21:45]i001: Burn v3.7.1224.0, Windows v6.1 (Build 
7601: Service Pack 1), path: C:\Dev\Core 
Technologies\Releases\4.0.RTM\Setup\bin\Setup.exe, cmdline: ''
 [2364:27B0][2013-07-22T11:21:45]i000: Initializing string variable 
'SERVICESLOGLEVEL' to value 'WARN'

So you can see I did not call the command line and it is defaulting to WARN (as 
expected)

If I do the command line I get this:

[19A8:0CB4][2013-07-22T11:28:25]i001: Burn v3.7.1224.0, Windows v6.1 (Build 
7601: Service Pack 1), path: C:\Dev\Core 
Technologies\Main\Setup\bin\TITUSAdminConsoleSetup.exe, cmdline: 
'SERVICESLOGLEVEL=DEBUG -burn.unelevated 
BurnPipe.{4746E36A-0273-4F2E-A8AE-E284D5000B00} 
{38FC0504-C9E9-4C41-A013-DF3CBBEB3A28} 9820'
 [19A8:0CB4][2013-07-22T11:28:25]i000: Initializing string variable 
'SERVICESLOGLEVEL' to value 'WARN'
...
[19A8:0CE0][2013-07-22T11:28:25]i000: Setting string variable 
'SERVICESLOGLEVEL' to value 'DEBUG'

I didn't launch my MSI so you can't see the log file :(

But look at your log files see what they are telling you

Steve

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 11:08 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

I've removed the default value in product.wxs, but to no avail. That's why my 
custom action reports the property as being null.

I'm assuming that the bundle log is the install.log I see by default in my temp 
directory in a VSD.tmp directory. It has no mention of the variable when 
simply running the setup.exe. If I run setup.exe with the parameter in the 
arguments list, then it shows that it's calling msiexec with the parameters I 
gave to setup.exe

Mark Freedman


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Monday, July 22, 2013 10:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

The bundle and installer logs would tell the story...  Start with the bundle 
log and ensure it is passing the default value to the MSI, then inspect the MSI 
log file to find where the property is changing

Re: [WiX-users] passing command args to MSI from bundle [P]

[Steven Ogilvie]

Classification: Public
Do you want your SETLOCALDB default value to be true or false?
In your bundle.wxs you have it set to true, in your product.wxs you have it set 
to false Have the default value set in the bundle.wxs and get rid of the value= 
in your product.wxs...

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 10:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

I'm really at a loss as to why I'm seeing this behavior. Only if I manually run 
setup.exe on the command line with my parameter, as in your example, do I see 
it be able to be picked up by the MSI.

In your email below, I see that you just have some hardcoded values, which is 
really what I want. Even those hardcoded values do not work for me. Perhaps it 
has to do with when the Custom Action for setting the property is firing. I see 
you are doing it after InstallValidate, but I am doing it after InstallFiles.

Mark Freedman
JHU/APL
17-N568
443.778.2647
mark.freed...@jhuapl.edu


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 9:49 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
Nope the property I have is a made up property that I use... in the bundle.wxs 
I set the default value to WARN which is passed onto the MSI and my custom 
action uses it.
I can change the value via the command line i.e.: MYBootstrapper.exe 
SERVICESLOGLEVEL=DEBUG which would overwrite the default value WARN to DEBUG...

Bundle.wxs:
Variable Name=SERVICESLOGLEVEL Type=string bal:Overridable=yes 
Value=WARN/

Chain
...
MsiPackage Id=MainInstall
  DisplayName=$(var.ProductName)
  DisplayInternalUI=no
  SourceFile=$(env.TLSharedServices)\Installers\_Setup.msi
  Name=RedistServerAC\Setup.msi
  Visible=no
  Cache=no
  Compressed=no
  Permanent=no
MsiProperty Name=WEBAPPPOOL_USERNAME Value=NetworkService/
MsiProperty Name=ALLOW_REMOTE_ACCESS Value=0/
MsiProperty Name=SERVICESLOGLEVEL Value=[SERVICESLOGLEVEL]/
MsiProperty Name=SERVERLESSINSTALL Value=1/
  /MsiPackage

Product.wxs:
Property Id=SERVICESLOGLEVEL Secure=yes/

CustomAction Id=CA_Set_WebLogLevel Property=CA_WEBLOGLEVEL 
Value=[DIRECTORY_PATH_SERVER]|Web.config|[SERVICESLOGLEVEL]/
CustomAction Id=CA_WEBLOGLEVEL BinaryKey=BIN_CustomAction 
DllEntry=ChangeConfigLoggingLevel Impersonate=no Execute=deferred 
Return=check /
UI
  ProgressText Action=CA_WEBLOGLEVELCA: Configuring the logging level 
for Web.Config.../ProgressText
/UI

Custom Action=CA_Set_WebLogLevel After= InstallValidateNOT 
Installed/Custom Custom Action=CA_WEBLOGLEVEL After= InstallFiles NOT 
Installed/Custom

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 9:25 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Thanks Steven,

I tried that as well, not defaulting the value in the Product.wxs and it seems 
that when the MSI takes over, the value of the property is empty string or 
null. If I do call my setup.exe via commandline, I am able to set it and it 
picks it up in the MSI.  Is your MSI Property in the example below a built in 
property, and there's an issue with mine being one I created?

Variable Name=SETLOCALDB Type=string Value=true 
bal:Overridable=yes /
  MsiPackage Id=OperatorStationInstaller 
SourceFile=$(var.OperatorStationInstaller.TargetPath) Compressed=no
MsiProperty Name=SETLOCALDB Value=[SETLOCALDB] /
  /MsiPackage


Property Id=SETLOCALDB Secure=yes/



Mark Freedman


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 9:17 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
Take out the Value out of your Product.wxs i.e.: Property Id=SETLOCALDB 
Secure=yes  /

Set the default value of the property in the bundle.wxs so it is passed on to 
the MSI, that way you have the default value but you can change it via the 
command line to change it...

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 8:06 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

I've tried Steven's method of defining a variable and assigning it to the 
MsiProperty, as well not using a burn variable and just using the MSI Property 
with a constant. When I have the Property defined in my product.wxs, it is 
always set to the defaulted

Re: [WiX-users] passing command args to MSI from bundle [P]

[Steven Ogilvie]

Classification: Public
I am totally confused now, are you using MSBuild to create a setup.exe that 
kicks off your installer?

The point of the WIX Bootstrapper (bundle.wxs) is to create an executable that 
allows you to install any pre requisites you have (exe/msi/msu) and of course 
kick off your main installer.

I am not really familiar with MSBuild

Steve

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 12:15 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Steve,

Correct, I do not see the logs.

I experimented with removing my GenerateBootstrapper task as I mentioned 
before, reproduced below. I then see the log file show up, and I see similar 
log files as you have described, and the variable SETLOCALDB set to 'true' as 
you would expect. The problem is, I am relying on the GenerateBootstrapper 
post-build task to gather up my bootstrappers. It seems that running 
GenerateBootstrapper clobbers specifics that I put in my Bundle.wxs

  Target Name=AfterBuild
GenerateBootstrapper ApplicationFile=My Installer.msi 
ApplicationName=My App BootstrapperItems=@(BootstrapperFile) 
ComponentsLocation=Relative CopyComponents=True OutputPath=$(OutputPath) 
Path=..\..\Bootstrapper /
  /Target

Mark Freedman
JHU/APL
17-N568
443.778.2647
mark.freed...@jhuapl.edu


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 12:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
If you run your bootstrapper exe (burn.wxs) then through it run the MSI, you 
don't see any log files in your %temp% folder?

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 11:49 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Steven,

I see what you're doing and it all makes sense.
I can't find any logs files where you describe, or any log files that include 
my bundle name. I do see an install.log, but doesn't mention the defaulted 
MsiProperty I'm trying to set, nor does it have the date/time stamps like the 
excerpt you're showing below.

I'm on Wix 3.7.1224.0, building on a win 7 machine

Mark Freedman
JHU/APL
17-N568
443.778.2647
mark.freed...@jhuapl.edu


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 11:30 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
The log files from the bundle are placed in %temp% are i.e.: Name of 
bundle_datetime.log

Weird, try taking out the Persisted=yes out of the variable element in your 
bundle.wxs

Btw what version of WIX are you using?

My bundle log shows this:
[2364:27B0][2013-07-22T11:21:45]i001: Burn v3.7.1224.0, Windows v6.1 (Build 
7601: Service Pack 1), path: C:\Dev\Core 
Technologies\Releases\4.0.RTM\Setup\bin\Setup.exe, cmdline: ''
 [2364:27B0][2013-07-22T11:21:45]i000: Initializing string variable 
'SERVICESLOGLEVEL' to value 'WARN'

So you can see I did not call the command line and it is defaulting to WARN (as 
expected)

If I do the command line I get this:

[19A8:0CB4][2013-07-22T11:28:25]i001: Burn v3.7.1224.0, Windows v6.1 (Build 
7601: Service Pack 1), path: C:\Dev\Core 
Technologies\Main\Setup\bin\TITUSAdminConsoleSetup.exe, cmdline: 
'SERVICESLOGLEVEL=DEBUG -burn.unelevated 
BurnPipe.{4746E36A-0273-4F2E-A8AE-E284D5000B00} 
{38FC0504-C9E9-4C41-A013-DF3CBBEB3A28} 9820'
 [19A8:0CB4][2013-07-22T11:28:25]i000: Initializing string variable 
'SERVICESLOGLEVEL' to value 'WARN'
...
[19A8:0CE0][2013-07-22T11:28:25]i000: Setting string variable 
'SERVICESLOGLEVEL' to value 'DEBUG'

I didn't launch my MSI so you can't see the log file :(

But look at your log files see what they are telling you

Steve

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 11:08 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

I've removed the default value in product.wxs, but to no avail. That's why my 
custom action reports the property as being null.

I'm assuming that the bundle log is the install.log I see by default in my temp 
directory in a VSD.tmp directory. It has no mention of the variable when 
simply running the setup.exe. If I run setup.exe with the parameter in the 
arguments list, then it shows that it's calling msiexec with the parameters I 
gave to setup.exe

Mark Freedman


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Monday, July 22, 2013 10:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users

Re: [WiX-users] passing command args to MSI from bundle [P]

[Steven Ogilvie]

Classification: Public
If you run your bootstrapper exe (burn.wxs) then through it run the MSI, you 
don't see any log files in your %temp% folder?

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 11:49 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Steven,

I see what you're doing and it all makes sense.
I can't find any logs files where you describe, or any log files that include 
my bundle name. I do see an install.log, but doesn't mention the defaulted 
MsiProperty I'm trying to set, nor does it have the date/time stamps like the 
excerpt you're showing below.

I'm on Wix 3.7.1224.0, building on a win 7 machine

Mark Freedman
JHU/APL
17-N568
443.778.2647
mark.freed...@jhuapl.edu


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 11:30 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
The log files from the bundle are placed in %temp% are i.e.: Name of 
bundle_datetime.log

Weird, try taking out the Persisted=yes out of the variable element in your 
bundle.wxs

Btw what version of WIX are you using?

My bundle log shows this:
[2364:27B0][2013-07-22T11:21:45]i001: Burn v3.7.1224.0, Windows v6.1 (Build 
7601: Service Pack 1), path: C:\Dev\Core 
Technologies\Releases\4.0.RTM\Setup\bin\Setup.exe, cmdline: ''
 [2364:27B0][2013-07-22T11:21:45]i000: Initializing string variable 
'SERVICESLOGLEVEL' to value 'WARN'

So you can see I did not call the command line and it is defaulting to WARN (as 
expected)

If I do the command line I get this:

[19A8:0CB4][2013-07-22T11:28:25]i001: Burn v3.7.1224.0, Windows v6.1 (Build 
7601: Service Pack 1), path: C:\Dev\Core 
Technologies\Main\Setup\bin\TITUSAdminConsoleSetup.exe, cmdline: 
'SERVICESLOGLEVEL=DEBUG -burn.unelevated 
BurnPipe.{4746E36A-0273-4F2E-A8AE-E284D5000B00} 
{38FC0504-C9E9-4C41-A013-DF3CBBEB3A28} 9820'
 [19A8:0CB4][2013-07-22T11:28:25]i000: Initializing string variable 
'SERVICESLOGLEVEL' to value 'WARN'
...
[19A8:0CE0][2013-07-22T11:28:25]i000: Setting string variable 
'SERVICESLOGLEVEL' to value 'DEBUG'

I didn't launch my MSI so you can't see the log file :(

But look at your log files see what they are telling you

Steve

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 11:08 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

I've removed the default value in product.wxs, but to no avail. That's why my 
custom action reports the property as being null.

I'm assuming that the bundle log is the install.log I see by default in my temp 
directory in a VSD.tmp directory. It has no mention of the variable when 
simply running the setup.exe. If I run setup.exe with the parameter in the 
arguments list, then it shows that it's calling msiexec with the parameters I 
gave to setup.exe

Mark Freedman


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Monday, July 22, 2013 10:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

The bundle and installer logs would tell the story...  Start with the bundle 
log and ensure it is passing the default value to the MSI, then inspect the MSI 
log file to find where the property is changing.

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: Monday, July 22, 2013 9:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

I'm really at a loss as to why I'm seeing this behavior. Only if I manually run 
setup.exe on the command line with my parameter, as in your example, do I see 
it be able to be picked up by the MSI.

In your email below, I see that you just have some hardcoded values, which is 
really what I want. Even those hardcoded values do not work for me. Perhaps it 
has to do with when the Custom Action for setting the property is firing. I see 
you are doing it after InstallValidate, but I am doing it after InstallFiles.

Mark Freedman
JHU/APL
17-N568
443.778.2647
mark.freed...@jhuapl.edu


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 9:49 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
Nope the property I have is a made up property that I use... in the bundle.wxs 
I set the default value to WARN which is passed onto the MSI and my custom 
action uses it.
I can change the value via the command line i.e.: MYBootstrapper.exe 
SERVICESLOGLEVEL=DEBUG which would overwrite the default

Re: [WiX-users] passing command args to MSI from bundle [P]

[Steven Ogilvie]

Classification: Public
The log files from the bundle are placed in %temp% are i.e.: Name of 
bundle_datetime.log

Weird, try taking out the Persisted=yes out of the variable element in your 
bundle.wxs 

Btw what version of WIX are you using?

My bundle log shows this:
[2364:27B0][2013-07-22T11:21:45]i001: Burn v3.7.1224.0, Windows v6.1 (Build 
7601: Service Pack 1), path: C:\Dev\Core 
Technologies\Releases\4.0.RTM\Setup\bin\Setup.exe, cmdline: ''
 [2364:27B0][2013-07-22T11:21:45]i000: Initializing string variable 
'SERVICESLOGLEVEL' to value 'WARN'

So you can see I did not call the command line and it is defaulting to WARN (as 
expected)

If I do the command line I get this:

[19A8:0CB4][2013-07-22T11:28:25]i001: Burn v3.7.1224.0, Windows v6.1 (Build 
7601: Service Pack 1), path: C:\Dev\Core 
Technologies\Main\Setup\bin\TITUSAdminConsoleSetup.exe, cmdline: 
'SERVICESLOGLEVEL=DEBUG -burn.unelevated 
BurnPipe.{4746E36A-0273-4F2E-A8AE-E284D5000B00} 
{38FC0504-C9E9-4C41-A013-DF3CBBEB3A28} 9820'
 [19A8:0CB4][2013-07-22T11:28:25]i000: Initializing string variable 
'SERVICESLOGLEVEL' to value 'WARN'
...
[19A8:0CE0][2013-07-22T11:28:25]i000: Setting string variable 
'SERVICESLOGLEVEL' to value 'DEBUG'

I didn't launch my MSI so you can't see the log file :(

But look at your log files see what they are telling you

Steve

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 11:08 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

I've removed the default value in product.wxs, but to no avail. That's why my 
custom action reports the property as being null.

I'm assuming that the bundle log is the install.log I see by default in my temp 
directory in a VSD.tmp directory. It has no mention of the variable when 
simply running the setup.exe. If I run setup.exe with the parameter in the 
arguments list, then it shows that it's calling msiexec with the parameters I 
gave to setup.exe

Mark Freedman


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Monday, July 22, 2013 10:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

The bundle and installer logs would tell the story...  Start with the bundle 
log and ensure it is passing the default value to the MSI, then inspect the MSI 
log file to find where the property is changing.

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: Monday, July 22, 2013 9:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

I'm really at a loss as to why I'm seeing this behavior. Only if I manually run 
setup.exe on the command line with my parameter, as in your example, do I see 
it be able to be picked up by the MSI.

In your email below, I see that you just have some hardcoded values, which is 
really what I want. Even those hardcoded values do not work for me. Perhaps it 
has to do with when the Custom Action for setting the property is firing. I see 
you are doing it after InstallValidate, but I am doing it after InstallFiles.

Mark Freedman
JHU/APL
17-N568
443.778.2647
mark.freed...@jhuapl.edu


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 9:49 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
Nope the property I have is a made up property that I use... in the bundle.wxs 
I set the default value to WARN which is passed onto the MSI and my custom 
action uses it.
I can change the value via the command line i.e.: MYBootstrapper.exe 
SERVICESLOGLEVEL=DEBUG which would overwrite the default value WARN to DEBUG...

Bundle.wxs:
Variable Name=SERVICESLOGLEVEL Type=string bal:Overridable=yes 
Value=WARN/

Chain
...
MsiPackage Id=MainInstall
  DisplayName=$(var.ProductName)
  DisplayInternalUI=no
  SourceFile=$(env.TLSharedServices)\Installers\_Setup.msi
  Name=RedistServerAC\Setup.msi
  Visible=no
  Cache=no
  Compressed=no
  Permanent=no
MsiProperty Name=WEBAPPPOOL_USERNAME Value=NetworkService/
MsiProperty Name=ALLOW_REMOTE_ACCESS Value=0/
MsiProperty Name=SERVICESLOGLEVEL Value=[SERVICESLOGLEVEL]/
MsiProperty Name=SERVERLESSINSTALL Value=1/
  /MsiPackage

Product.wxs:
Property Id=SERVICESLOGLEVEL Secure=yes/

CustomAction Id=CA_Set_WebLogLevel Property=CA_WEBLOGLEVEL 
Value=[DIRECTORY_PATH_SERVER]|Web.config|[SERVICESLOGLEVEL]/
CustomAction Id=CA_WEBLOGLEVEL BinaryKey=BIN_CustomAction 
DllEntry=ChangeConfigLoggingLevel Impersonate=no Execute=deferred 
Return=check /
UI

Re: [WiX-users] passing command args to MSI from bundle [P]

[Steven Ogilvie]

Classification: Public
Then what is the purpose of using MSBuild + WIX bundle + WIX MSI that seems 
like an overkill?

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: July-22-13 12:50 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Old MsBuild/Visual Studio task that takes a manifest, a set of dependencies 
usually embedded in the project file, and builds a primitive bootstrapper.  We 
used to use it before they hired me.

--
John Merryweather Cooper
Build  Install Engineer - ESA
Jack Henry  Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com 




-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 11:34 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
Sorry Mark,

I am not familiar with Generatebootstrapper what is that?

Steve

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 12:15 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Steve,

Correct, I do not see the logs.

I experimented with removing my GenerateBootstrapper task as I mentioned 
before, reproduced below. I then see the log file show up, and I see similar 
log files as you have described, and the variable SETLOCALDB set to 'true' as 
you would expect. The problem is, I am relying on the GenerateBootstrapper 
post-build task to gather up my bootstrappers. It seems that running 
GenerateBootstrapper clobbers specifics that I put in my Bundle.wxs

  Target Name=AfterBuild
GenerateBootstrapper ApplicationFile=My Installer.msi 
ApplicationName=My App BootstrapperItems=@(BootstrapperFile) 
ComponentsLocation=Relative CopyComponents=True OutputPath=$(OutputPath) 
Path=..\..\Bootstrapper /
  /Target

Mark Freedman
JHU/APL
17-N568
443.778.2647
mark.freed...@jhuapl.edu


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 12:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
If you run your bootstrapper exe (burn.wxs) then through it run the MSI, you 
don't see any log files in your %temp% folder?

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 11:49 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Steven,

I see what you're doing and it all makes sense.
I can't find any logs files where you describe, or any log files that include 
my bundle name. I do see an install.log, but doesn't mention the defaulted 
MsiProperty I'm trying to set, nor does it have the date/time stamps like the 
excerpt you're showing below.

I'm on Wix 3.7.1224.0, building on a win 7 machine

Mark Freedman
JHU/APL
17-N568
443.778.2647
mark.freed...@jhuapl.edu


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 11:30 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
The log files from the bundle are placed in %temp% are i.e.: Name of 
bundle_datetime.log

Weird, try taking out the Persisted=yes out of the variable element in your 
bundle.wxs

Btw what version of WIX are you using?

My bundle log shows this:
[2364:27B0][2013-07-22T11:21:45]i001: Burn v3.7.1224.0, Windows v6.1 (Build 
7601: Service Pack 1), path: C:\Dev\Core 
Technologies\Releases\4.0.RTM\Setup\bin\Setup.exe, cmdline: ''
 [2364:27B0][2013-07-22T11:21:45]i000: Initializing string variable 
'SERVICESLOGLEVEL' to value 'WARN'

So you can see I did not call the command line and it is defaulting to WARN (as 
expected)

If I do the command line I get this:

[19A8:0CB4][2013-07-22T11:28:25]i001: Burn v3.7.1224.0, Windows v6.1 (Build 
7601: Service Pack 1), path: C:\Dev\Core 
Technologies\Main\Setup\bin\TITUSAdminConsoleSetup.exe, cmdline: 
'SERVICESLOGLEVEL=DEBUG -burn.unelevated 
BurnPipe.{4746E36A-0273-4F2E-A8AE-E284D5000B00} 
{38FC0504-C9E9-4C41-A013-DF3CBBEB3A28} 9820'
 [19A8:0CB4][2013-07-22T11:28:25]i000: Initializing string variable 
'SERVICESLOGLEVEL' to value 'WARN'
...
[19A8:0CE0][2013-07-22T11:28:25]i000: Setting string variable 
'SERVICESLOGLEVEL' to value 'DEBUG'

I didn't launch my MSI so you can't see the log file :(

But look at your log files see what they are telling you

Steve

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 11:08 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users

Re: [WiX-users] passing command args to MSI from bundle [P]

[Steven Ogilvie]

Classification: Public
I totally agree :)

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: July-22-13 2:13 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

It's redundant and probably a significant source of the problem.  It should be 
removed or at least commented out so he knows which bootstrapper he's actually 
debugging.

--
John Merryweather Cooper
Build  Install Engineer - ESA
Jack Henry  Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com 




-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 12:13 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
Then what is the purpose of using MSBuild + WIX bundle + WIX MSI that seems 
like an overkill?

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: July-22-13 12:50 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Old MsBuild/Visual Studio task that takes a manifest, a set of dependencies 
usually embedded in the project file, and builds a primitive bootstrapper.  We 
used to use it before they hired me.

--
John Merryweather Cooper
Build  Install Engineer - ESA
Jack Henry  Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com 




-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 11:34 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
Sorry Mark,

I am not familiar with Generatebootstrapper what is that?

Steve

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 12:15 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Steve,

Correct, I do not see the logs.

I experimented with removing my GenerateBootstrapper task as I mentioned 
before, reproduced below. I then see the log file show up, and I see similar 
log files as you have described, and the variable SETLOCALDB set to 'true' as 
you would expect. The problem is, I am relying on the GenerateBootstrapper 
post-build task to gather up my bootstrappers. It seems that running 
GenerateBootstrapper clobbers specifics that I put in my Bundle.wxs

  Target Name=AfterBuild
GenerateBootstrapper ApplicationFile=My Installer.msi 
ApplicationName=My App BootstrapperItems=@(BootstrapperFile) 
ComponentsLocation=Relative CopyComponents=True OutputPath=$(OutputPath) 
Path=..\..\Bootstrapper /
  /Target

Mark Freedman
JHU/APL
17-N568
443.778.2647
mark.freed...@jhuapl.edu


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 12:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
If you run your bootstrapper exe (burn.wxs) then through it run the MSI, you 
don't see any log files in your %temp% folder?

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 11:49 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Steven,

I see what you're doing and it all makes sense.
I can't find any logs files where you describe, or any log files that include 
my bundle name. I do see an install.log, but doesn't mention the defaulted 
MsiProperty I'm trying to set, nor does it have the date/time stamps like the 
excerpt you're showing below.

I'm on Wix 3.7.1224.0, building on a win 7 machine

Mark Freedman
JHU/APL
17-N568
443.778.2647
mark.freed...@jhuapl.edu


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, July 22, 2013 11:30 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
The log files from the bundle are placed in %temp% are i.e.: Name of 
bundle_datetime.log

Weird, try taking out the Persisted=yes out of the variable element in your 
bundle.wxs

Btw what version of WIX are you using?

My bundle log shows this:
[2364:27B0][2013-07-22T11:21:45]i001: Burn v3.7.1224.0, Windows v6.1 (Build 
7601: Service Pack 1), path: C:\Dev\Core 
Technologies\Releases\4.0.RTM\Setup\bin\Setup.exe, cmdline: ''
 [2364:27B0][2013-07-22T11:21:45]i000: Initializing string variable 
'SERVICESLOGLEVEL' to value 'WARN'

So you can see I did not call the command line and it is defaulting to WARN (as 
expected

Re: [WiX-users] passing command args to MSI from bundle [P]

[Steven Ogilvie]

Classification: Public
I do the same thing:

Variable Name=SERVICESLOGLEVEL Type=string bal:Overridable=yes 
Value=WARN/

MsiProperty Name=SERVICESLOGLEVEL Value=[SERVICESLOGLEVEL]/

So from the command line I would run MyBootstrapperEXE.exe 
SERVICESLOGLEVEL=DEBUG

Now if you are just wanting to change a property via the bootstrapper you don't 
have to add the variable element

Just add the MsiProperty element to your MSI:
MsiProperty Name=ALLOW_REMOTE_ACCESS Value=0/

Steve

-Original Message-
From: Rahul V [mailto:rahul8...@gmail.com]
Sent: July-19-13 9:55 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle

Create a variable inside the Bundle, pass that variable to MsiProperty, and 
change the variable in the bootstrapper code like 
Bootstrapper.Engine.StringVariables[MyVariable] = 

now you can see it in the log, for the reference,

http://stackoverflow.com/questions/15305932/how-to-pass-a-property-from-an-editbox-control-in-burn-native-bootstrapper-to-a

http://bryanpjohnston.com/2012/09/28/custom-wix-managed-bootstrapper-application/

Regards,
Rahul

On Thu, Jul 18, 2013 at 6:05 PM, Freedman, Mark P. mark.freed...@jhuapl.edu
 wrote:

 I'm on Wix 3.7. I have an MSI that I would like to set a registry key 
 (perhaps via a Custom Action, as he will have to check if the key 
 already exists).

 I'm understand that a Bundle in a bootstrapper project can't change 
 the machine state (such as setting the registry). Therefore, I'm 
 attempting to pass a command line argument via MsiProperty, but 
 doesn't appear to show up as a command line argument in my log file for the 
 bootstrapper.


 1.   Is it possible to set a registry key up in a Bundle?

 2.   If not, how can I add a command line argument (or some other
 piece of custom data) to be passed to the MSI.

 3.   How can the MSI read whatever it is I pass to it (whether I tends
 up being a command line arg or something else).

 ?xml version=1.0 encoding=UTF-8? Wix 
 xmlns=http://schemas.microsoft.com/wix/2006/wi;
   Bundle Name=MyInstallerBootstrapperLocalDb Version=1.0.0.0
 Manufacturer=$(var.Configuration) Industires UpgradeCode=*
 BootstrapperApplicationRef
 Id=WixStandardBootstrapperApplication.RtfLicense /
 Chain
   MsiPackage Id=MyInstallerInstaller
 SourceFile=$(var.MyInstallerInstaller.TargetPath) Compressed=no
 !-- TODO - if this is being set correctly, the MSI needs to 
 interpret it and set up the key--
 MsiProperty Name=SetLocalDb Value=yes/
   /MsiPackage
 /Chain
   /Bundle
 /Wix


 Thanks,

 Mark Freedman


 --
  See everything from the browser to the database with 
 AppDynamics Get end-to-end visibility with application monitoring from 
 AppDynamics Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.c
 lktrk ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-19-13 10:07:29 
AM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] passing command args to MSI from bundle [P]

[Steven Ogilvie]

Classification: Public
Mark,

In my bundle.wxs I have the following:

/BootstrapperApplicationRef
Variable Name=SERVICESLOGLEVEL Type=string bal:Overridable=yes 
Value=WARN/

Chain
MsiPackage Id=MainInstall
DisplayName=$(var.ProductName)
SourceFile=path to my MSI file\MyMSIFile.msi
Name=Redist\ MyMSIFile.msi 
DisplayInternalUI=yes
Visible=no
Cache=no
Compressed=no
Permanent=no
  MsiProperty Name=SERVICESLOGLEVEL Value=[SERVICESLOGLEVEL]/
/MsiPackage

This way if I don't have a command line argument the MSI property 
SERVICESLOGLEVEL is set to WARN by default, hence I can change it by:
MYBOOSTRAPPEREXE.exe SERVICESLOGLEVEL=DEBUG

Then in my product.wxs file I have the property initialized:
Property Id=SERVICESLOGLEVEL Secure=yes/

And then I use that property in a custom action to change the app.config file 
of my various services logging level i.e.

CustomAction Id=CA_Set_ConfigLevelStr Property=CA_SETCONFIGLEVELSTR 
Value=[CONFIG_SERVICE_PATH]|Config.exe.config|[SERVICESLOGLEVEL]/
CustomAction Id=CA_SETCONFIGLEVELSTR BinaryKey=BIN_CustomAction 
DllEntry=ChangeConfigLevel Impersonate=no Execute=deferred Return=check 
/

So if I don't have a command line parameter to the logging level is set to the 
default WARN (which is set in my variable element in the bundle.wxs, or I can 
change the logging level by having a command line parameter as shown above...

Steve

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-19-13 2:31 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Right, My bootstrapper projct creates the exe, and I can run it and install 
with it. I'm not sure what's happening to the MsiProperty that Ive set up. I'm 
not sure how to read it from the MSI installer package, and it isn't passed as 
a command line argument as shown in the logs. 

I thin what I want to do is to read the MSI property and store it in a 
CustomActionData property to be read by a custom action, but does not seem to 
work.

Mark Freedman
JHU/APL
17-N568
443.778.2647
mark.freed...@jhuapl.edu


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Friday, July 19, 2013 1:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
The bundle.wxs is the bootsrapper code file, when you compile it, it creates an 
exe

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-19-13 12:44 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Currently, I do not have a custom bootstrapper application, just what I have in 
the Bundle.wxs file. 

I thought that by setting up the MSI Property that way, it wouldn't require 
running the bootstrapper EXE with a command line argument. I just want to pass 
a hard coded value of some sort to the MSI from this particular bootstrapper to 
the MSI and read it in a custom action.

I'm trying to then put the MSI property in to a custom action, if it is 
present, but it doesn't seem to work.

CustomAction Id='SetUsingLocalDbRegistryAction.SetProperty' Return='check'
  Value='SETLOCALDB=[SETLOCALDB]' 
Property='SetUsingLocalDbRegistryAction'/

CustomAction Id='SetUsingLocalDbRegistryAction' 
BinaryKey='CustomActionBinary' DllEntry='SetUsingLocalDbRegistry'
  Execute='deferred' Impersonate='no' Return='check'/


Mark Freedman

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Friday, July 19, 2013 10:08 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
I do the same thing:

Variable Name=SERVICESLOGLEVEL Type=string bal:Overridable=yes 
Value=WARN/

MsiProperty Name=SERVICESLOGLEVEL Value=[SERVICESLOGLEVEL]/

So from the command line I would run MyBootstrapperEXE.exe 
SERVICESLOGLEVEL=DEBUG

Now if you are just wanting to change a property via the bootstrapper you don't 
have to add the variable element

Just add the MsiProperty element to your MSI:
MsiProperty Name=ALLOW_REMOTE_ACCESS Value=0/

Steve

-Original Message-
From: Rahul V [mailto:rahul8...@gmail.com]
Sent: July-19-13 9:55 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle

Create a variable inside the Bundle, pass that variable to MsiProperty, and 
change the variable in the bootstrapper code like 
Bootstrapper.Engine.StringVariables[MyVariable] = 

now you can see it in the log, for the reference,

http://stackoverflow.com/questions

Re: [WiX-users] passing command args to MSI from bundle [P]

[Steven Ogilvie]

Classification: Public
The bundle.wxs is the bootsrapper code file, when you compile it, it creates an 
exe

-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-19-13 12:44 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Currently, I do not have a custom bootstrapper application, just what I have in 
the Bundle.wxs file. 

I thought that by setting up the MSI Property that way, it wouldn't require 
running the bootstrapper EXE with a command line argument. I just want to pass 
a hard coded value of some sort to the MSI from this particular bootstrapper to 
the MSI and read it in a custom action.

I'm trying to then put the MSI property in to a custom action, if it is 
present, but it doesn't seem to work.

CustomAction Id='SetUsingLocalDbRegistryAction.SetProperty' Return='check'
  Value='SETLOCALDB=[SETLOCALDB]' 
Property='SetUsingLocalDbRegistryAction'/

CustomAction Id='SetUsingLocalDbRegistryAction' 
BinaryKey='CustomActionBinary' DllEntry='SetUsingLocalDbRegistry'
  Execute='deferred' Impersonate='no' Return='check'/


Mark Freedman

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Friday, July 19, 2013 10:08 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]

Classification: Public
I do the same thing:

Variable Name=SERVICESLOGLEVEL Type=string bal:Overridable=yes 
Value=WARN/

MsiProperty Name=SERVICESLOGLEVEL Value=[SERVICESLOGLEVEL]/

So from the command line I would run MyBootstrapperEXE.exe 
SERVICESLOGLEVEL=DEBUG

Now if you are just wanting to change a property via the bootstrapper you don't 
have to add the variable element

Just add the MsiProperty element to your MSI:
MsiProperty Name=ALLOW_REMOTE_ACCESS Value=0/

Steve

-Original Message-
From: Rahul V [mailto:rahul8...@gmail.com]
Sent: July-19-13 9:55 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle

Create a variable inside the Bundle, pass that variable to MsiProperty, and 
change the variable in the bootstrapper code like 
Bootstrapper.Engine.StringVariables[MyVariable] = 

now you can see it in the log, for the reference,

http://stackoverflow.com/questions/15305932/how-to-pass-a-property-from-an-editbox-control-in-burn-native-bootstrapper-to-a

http://bryanpjohnston.com/2012/09/28/custom-wix-managed-bootstrapper-application/

Regards,
Rahul

On Thu, Jul 18, 2013 at 6:05 PM, Freedman, Mark P. mark.freed...@jhuapl.edu
 wrote:

 I'm on Wix 3.7. I have an MSI that I would like to set a registry key 
 (perhaps via a Custom Action, as he will have to check if the key 
 already exists).

 I'm understand that a Bundle in a bootstrapper project can't change 
 the machine state (such as setting the registry). Therefore, I'm 
 attempting to pass a command line argument via MsiProperty, but 
 doesn't appear to show up as a command line argument in my log file for the 
 bootstrapper.


 1.   Is it possible to set a registry key up in a Bundle?

 2.   If not, how can I add a command line argument (or some other
 piece of custom data) to be passed to the MSI.

 3.   How can the MSI read whatever it is I pass to it (whether I tends
 up being a command line arg or something else).

 ?xml version=1.0 encoding=UTF-8? Wix 
 xmlns=http://schemas.microsoft.com/wix/2006/wi;
   Bundle Name=MyInstallerBootstrapperLocalDb Version=1.0.0.0
 Manufacturer=$(var.Configuration) Industires UpgradeCode=*
 BootstrapperApplicationRef
 Id=WixStandardBootstrapperApplication.RtfLicense /
 Chain
   MsiPackage Id=MyInstallerInstaller
 SourceFile=$(var.MyInstallerInstaller.TargetPath) Compressed=no
 !-- TODO - if this is being set correctly, the MSI needs to 
 interpret it and set up the key--
 MsiProperty Name=SetLocalDb Value=yes/
   /MsiPackage
 /Chain
   /Bundle
 /Wix


 Thanks,

 Mark Freedman


 --
  See everything from the browser to the database with 
 AppDynamics Get end-to-end visibility with application monitoring from 
 AppDynamics Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.c
 lktrk ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today

Re: [WiX-users] Convert from MSI to EXE [P]

[Steven Ogilvie]

Classification: Public
Hi Balu,

You can use burn (bootstrapper) (which is an EXE) to launch your MSI's

Steve

-Original Message-
From: Mamidi, Balasubrahmanyam [mailto:balu.mam...@flightsafety.com]
Sent: July-18-13 1:52 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Convert from MSI to EXE

Hi, currently we are creating our product to MSI file (using wix ), now client 
is asking convert all products to EXE's.

How much effort to do this and give me some idea please? Is something change 
output file extension to from *.msi to *.exe

Thanks,
Balu



--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-18-13 1:59:37 
PM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Convert from MSI to EXE [P]

[Steven Ogilvie]

Classification: Public
No I don't believe so...

-Original Message-
From: Mamidi, Balasubrahmanyam [mailto:balu.mam...@flightsafety.com]
Sent: July-18-13 2:20 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Convert from MSI to EXE

Thanks for reply steve. not clear what you're saying..

Let me reframe what I want..
When I compile my project I want .exe to be generated. I do not want .msi file 
to be generated. Is it possible using WIX?


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Thursday, July 18, 2013 1:00 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Convert from MSI to EXE [P]

Classification: Public
Hi Balu,

You can use burn (bootstrapper) (which is an EXE) to launch your MSI's

Steve

-Original Message-
From: Mamidi, Balasubrahmanyam [mailto:balu.mam...@flightsafety.com]
Sent: July-18-13 1:52 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Convert from MSI to EXE

Hi, currently we are creating our product to MSI file (using wix ), now client 
is asking convert all products to EXE's.

How much effort to do this and give me some idea please? Is something change 
output file extension to from *.msi to *.exe

Thanks,
Balu



--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-18-13 1:59:37 
PM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-18-13 2:30:23 
PM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] C# custom action to grant builtin user the installation folder full control [P]

[Steven Ogilvie]

Classification: Public
Did you try: Impersonate=yes

-Original Message-
From: Chen, Jianxin [mailto:jianxin.c...@bakerhughes.com]
Sent: July-16-13 1:59 PM
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] C# custom action to grant builtin user the installation 
folder full control

Hi, Experts,

I created a C# custom action to grant the builtin\users full control of the 
installation target folder, but I have to run the setup.exe as administrator 
to make it work.

If I just double-click the setup.exe, my custom action does not have the 
permission to change the folder.

I have tried to use

1 CustomAction Id=GrantFullAccessToFolder Execute=deferred 
Impersonate=no Return=check  BinaryKey=GrantFullAccessToFolder.CA.dll 
DllEntry= GrantFullAccessToFolder /

...
Custom Action=GrantFullAccessToFolder  After=InstallFinalizeNOT 
Installed/Custom



2   Package InstallerVersion=301 Compressed=yes ... 
InstallPrivileges=elevated  InstallScope=perMachine /


They does not work!

Any questions?

Thanks!

JC
___
Jianxin Chen | Senior Software Engineer
Baker Hughes | Software / Intelligent Production Systems 
jianxin.c...@bakerhughes.commailto:jianxin.c...@bakerhughes.com
Office: +1 713.934.4136
14990 Yorktown Plaza Drive, Houston, 77040 
http://www.bakerhughes.comhttp://www.bakerhughes.com/ | Advancing Reservoir 
Performance

--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-16-13 2:06:43 
PM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Newer version of the product is already installed error [P]

[Steven Ogilvie]

Classification: Public
Are the ProductCode and UpgradeCode different?

-Original Message-
From: Greg Edwards [mailto:gedwa...@polariswireless.com]
Sent: July-16-13 4:49 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Newer version of the product is already installed error

I am newbie to WIX.

After running a newly created installer I am receiving the following message:

Unable to install because a newer version of the product is already installed.

I have an application already installed with an installer that I created with a 
similar signature. The Product IDs are different, the names are different and 
the Icons are different. What exactly should I be looking for that might be 
conflicting between these two installers?

Thank you.
-Greg

--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-16-13 4:58:14 
PM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Resolve Light 1056 Warning

[Steven Ogilvie]

Sigh,

I am confused... When I was using InstallShield (for many years) I was told to 
always use Merge Modules, easier for upgrading, and easier for grouping 
features.

I have a Server MSI and a Services MSI which is bundled in burn so the 
bootstrapper can take care of the pre reqs etc...

In my Services MSI I have 6 Merge Modules, where each Service is a Merge 
Module, I also have several WixLibs of common files and share those WixLibs 
within the Merge Modules. The Merge Modules where used mainly for Upgrading...

Are the majority of you saying it makes more sense to get rid of the Merge 
Modules and just use the WixLibs?

Steve

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com] 
Sent: July-11-13 8:34 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Resolve Light 1056 Warning

Yes, I really hate merge modules.  Wixlibs are much better.  Always have issues 
with merge modules I haven't authored.

--
John Merryweather Cooper
Build  Install Engineer - ESA
Jack Henry  Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com 




-Original Message-
From: Kathy Morey
Sent: Wednesday, July 10, 2013 4:22 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Resolve Light 1056 Warning

FYI 

It turns out that, although John's suggestion did work, different Microsoft 
merge modules have different values for some of the standard folders, and so I 
will be following Rob's suggestion and just ignoring those warnings.

Thanks.

-Original Message-
From: Kathy Morey
Sent: Wednesday, July 10, 2013 5:08 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: RE: Resolve Light 1056 Warning

Thanks, John.

That did it for me.


-Original Message-
From: John Cooper
Sent: Wednesday, July 10, 2013 12:50 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Resolve Light 1056 Warning

I was able to get the .:System32 by using

Directory Id=ExperiementFolder Name=. SourceName=System32
Component Id=ProductComponent Guid=*
File KeyPath=yes 
Source=$(var.SolutionDir).nuget\NuGet.exe /
/Component
/Directory

--
John Merryweather Cooper
Build  Install Engineer - ESA
Jack Henry  Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com 




-Original Message-
From: Kathy Morey
Sent: Wednesday, July 10, 2013 11:22 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Resolve Light 1056 Warning

I am creating a WiX installer for an application that requires some Microsoft 
merge modules.

I'm getting several warnings like:

warning LGHT1056: The Directory table contains a row with primary key(s) 
'SystemFolder' which cannot be merged from the merge module 
'C:\_blah\blah\COMCAT.MSM'.  This is likely due to collision of rows with the 
same primary key(s) (but other different values in other columns) between the 
database and the merge module.

I looked at the merge module and my MSI with Orca and found this difference in 
the DefaultDir column of the Directory table:

MM DefaultDir - .:System32
My DefaultDir - System32

How do I author my project so that I get the .: designation in the DefaultDir 
column?

Kathy Morey
Synergy Software Engineer
Profitstars, a Jack Henry Company
700 Tower Drive, Suite 600
Troy MI 48098
Office: 248.879.0316 ext. 454809
Email: kmo...@profitstars.com
NOTICE: This electronic mail message and any files transmitted with it are 
intended exclusively for the individual or entity to which it is addressed. The 
message, together with any attachment, may contain confidential and/or 
privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution is strictly prohibited. If you have received this message in 
error, please immediately advise the sender by reply email and delete all 
copies.
--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are 
intended exclusively for the individual or entity to which it is addressed. The 
message, together with any attachment, may contain confidential and/or 
privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution is strictly prohibited. If you have 

Re: [WiX-users] Resolve Light 1056 Warning

[Steven Ogilvie]

Each merge Module contains 3 file elements (one or two dll's and a .config 
file) and a bunch of Custom Actions
I have about 10 wixlibs that are shared between the Merge Modules (dll's that 
are shared between the merge modules but are installed to different directories)
Each merge module is a different service... I have 5 merge modules.

So are you saying to convert each merge module to a wixlib? Can I still share 
the wixlibs within a wixlib?

Here is a typical Merge Module (I have excluded the custom actions, about 10 of 
them)
Binary Id=BIN_CustomActionMM SuppressModularization=yes 
SourceFile=$(var.some companyInstallerCAMM)/

Directory Id=TARGETDIR Name=SourceDir
  Directory Id=WixLibRedirectFolder Name=EnterpriseSettingsService

Component Id=cmp_EnterpriseSettingsDll Guid=some GUID
  File Id=file_EnterpriseSettingsDll KeyPath=yes Name=some 
company.Enterprise.Settings.dll Source=$(var.tssSourcePath)\some 
company.Enterprise.Settings.Host\some company.Enterprise.Settings.dll /
  ServiceControl Id=StartSettingsService Name=some 
company.Enterprise.Settings Stop=both Wait=yes /
  RemoveFolder Id=RemoveSSFolder Directory=WixLibRedirectFolder 
On=uninstall /
  /Component
Component Id=cmp_SEventLog Guid=some GUID KeyPath=yes
  util:EventSource Name=Settings Service

EventMessageFile=[NETFRAMEWORK40FULLINSTALLROOTDIR]EventLogMessages.dll
Log=some company Labs/
  Condition![CDATA[NOT Installed AND NOT VersionNT64]]/Condition
/Component
Component Id=cmp_SEventLogx64 Guid=some GUID KeyPath=yes
  util:EventSource Name=Settings Service

EventMessageFile=[NETFRAMEWORK40FULLINSTALLROOTDIR64]EventLogMessages.dll
Log=some company Labs/
  Condition![CDATA[NOT Installed AND VersionNT64]]/Condition
/Component
Component Id=cmp_EnterpriseSettingsHostDll Guid=some GUID
  File Id=file_EnterpriseSettingsHostDll KeyPath=yes 
Source=$(var.tssSourcePath)\some company.Enterprise.Settings.Host\some 
company.Enterprise.Settings.Host.dll /
  /Component
Component Id=cmp_EnterpriseSettingsDllConfig Guid=some GUID
  File Id=file_EnterpriseSettingsDllConfig KeyPath=yes Name=some 
company.Enterprise.Settings.Host.dll.config 
Source=$(var.tssSourcePath)\some company.Enterprise.Settings.Host\some 
company.Enterprise.Settings.Host.dll.config /
  /Component

/Directory
  /Directory

!-- Shared services files --
ComponentGroupRef Id=cmpgrp_NServiceBus /
ComponentGroupRef Id=cmpgrp_SharedServiceFiles /
ComponentGroupRef Id=cmpgrp_WcfServiceBehaviors/
ComponentGroupRef Id=cmpgrp_some companySharedDataDlls/
ComponentGroupRef Id=cmpgrp_some companyInternalSettings/
ComponentGroupRef Id=cmpgrp_Log4Net/
ComponentGroupRef Id=cmpgrp_DomainTypes/
ComponentGroupRef Id=cmpgrp_SharedServicesUnityFiles/
ComponentGroupRef Id=cmpgrp_some companyCommon/

PropertyRef Id=NETFRAMEWORK40FULLINSTALLROOTDIR/
PropertyRef Id=NETFRAMEWORK40FULLINSTALLROOTDIR64/
Property Id=SERVER_INSTALL Secure=yes SuppressModularization=yes/
Property Id=DIRECTORY_PATH_SERVICES Secure=yes 
SuppressModularization=yes/
Property Id=SETTINGS_SERVICE_PATH Secure=yes 
SuppressModularization=yes/
Property Id=SERVICESLOGLEVEL Secure=yes SuppressModularization=yes/

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: July-11-13 9:27 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Resolve Light 1056 Warning

Steve, basically, yes:
http://robmensching.com/blog/posts/2008/10/10/what-are-.wixlibs-and-why-would-you-use-them


On Thu, Jul 11, 2013 at 5:48 AM, Steven Ogilvie steven.ogil...@titus.comwrote:

 Sigh,

 I am confused... When I was using InstallShield (for many years) I was 
 told to always use Merge Modules, easier for upgrading, and easier for 
 grouping features.

 I have a Server MSI and a Services MSI which is bundled in burn so the 
 bootstrapper can take care of the pre reqs etc...

 In my Services MSI I have 6 Merge Modules, where each Service is a 
 Merge Module, I also have several WixLibs of common files and share 
 those WixLibs within the Merge Modules. The Merge Modules where used 
 mainly for Upgrading...

 Are the majority of you saying it makes more sense to get rid of the 
 Merge Modules and just use the WixLibs?

 Steve

 -Original Message-
 From: John Cooper [mailto:jocoo...@jackhenry.com]
 Sent: July-11-13 8:34 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Resolve Light 1056 Warning

 Yes, I really hate merge modules.  Wixlibs are much better.  Always 
 have issues with merge modules I haven't authored.

 --
 John Merryweather Cooper
 Build  Install Engineer - ESA
 Jack Henry  Associates, Inc.®
 Shawnee

Re: [WiX-users] Windows updates [P]

[Steven Ogilvie]

___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
See everything from the browser to the database with AppDynamics Get end-to-end 
visibility with application monitoring from AppDynamics Isolate bottlenecks and 
diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 
This message has been marked as Public by Steven Ogilvie on July-11-13 1:01:06 
PM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

 


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Target directory issue with windows xp/ windows 7 [P]

[Steven Ogilvie]

Classification: Public
If you create a x86 (32 bit) MSI it will install to c:\program files (x86)\ 
folder on a 64 bit OS If you application is 32 bit, it should not install to 
c:\program files\ on a 64 bit OS, it should go to c:\program files (x86)\

-Original Message-
From: Blair Murri [mailto:os...@live.com]
Sent: June-22-13 3:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Target directory issue with windows xp/ windows 7

Use 32-bit Win7 instead of 64-bit Win7.
 
 From: balu.mam...@flightsafety.com
 To: wix-users@lists.sourceforge.net
 Date: Fri, 21 Jun 2013 11:37:39 -0400
 Subject: [WiX-users] Target directory issue with windows xp/ windows 7
 
 Hi, I am able to create MSI file for our product using wix installer.
 When I install this product on client PC(windows xp),  it kept all the files 
 C:\Program Files\Safety (the target directory  it's hot coded in 
 code)..which is OK.
 
 But when I install this product on client PC(windows 7),  it kept all the 
 files C:\Program Files (x86)\Safety -client doesn't want it to happen.
 
 My client wants no matter what the operating system is, it should always 
 place the file to C:\Program Files\Safety.
 
 Help me, how to achieve this to fix the problem?
 
 Thanks,
 Balu
 
 
 --
  This SF.net email is sponsored by Windows:
 
 Build for Windows Store.
 
 http://p.sf.net/sfu/windows-dev2dev
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



This message has been marked as Public by Steven Ogilvie on June-23-13 2:35:09 
PM.

The above classification labels were added to the message by TITUS Message 
Classification. 
For more information visit www.titus.com.

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Suppress options in bundle [P]

[Steven Ogilvie]

Classification: Public
Good to hear :)
Have a great weekend

-Original Message-
From: Dave Moss [mailto:davidm...@omprompt.com]
Sent: June-14-13 3:53 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Suppress options in bundle [P]

Thanks for your help Steve this is working like a dream now.


Dave Moss
Tactical Team Lead
OmPrompt
+44 (0)1235 436014 Direct
davidm...@omprompt.com
www.omprompt.com

OmPrompt Limited is registered in England  Wales, registration No. 4452522, 
with registered offices at 67 Innovation Drive, Milton Park, Abingdon, 
Oxfordshire. OX14 4RQ. UK. VAT No. 821339546.

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 13 June 2013 14:51
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Suppress options in bundle [P]

Classification: Public
Dave

Go back to your original code and just modify it to look similar to this:
BootstrapperApplicationRef 
Id=WixStandardBootstrapperApplication.HyperlinkLicense
  bal:WixStandardBootstrapperApplication
SuppressRepair=yes
SuppressOptionsUI=yes
LicenseUrl=
  /bal:WixStandardBootstrapperApplication
/BootstrapperApplicationRef

Keep your application ref, etc..

Steve
-Original Message-
From: Dave Moss [mailto:davidm...@omprompt.com]
Sent: June-13-13 9:42 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Suppress options in bundle [P]

Hi Steve,

Changed to the updated version and I am now getting The 
BootstrapperApplicationRef element contains an unhandled extension element 
'bal:WixStandardBootstrapperApplication'.  Please ensure that the extension for 
elements in the 'http://schemas.microsoft.com/wix/BalExtension' namespace has 
been provided. 

I have a reference in my VS2010 project to WixBalExtension.

Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; 
xmlns:bal=http://schemas.microsoft.com/wix/BalExtension
  Bundle Name=Document Converters Version=$(var.Version) 
Manufacturer=OmPrompt UpgradeCode=GUID here Condition=((VersionNT = v5.1) 
AND (ServicePackLevel = 3)) OR ((VersionNT = v5.2) AND (ServicePackLevel = 
2)) OR (VersionNT = v6.0)
BootstrapperApplicationRef 
Id=WixStandardBootstrapperApplication.HyperlinkLicense
  bal:WixStandardBootstrapperApplication
SuppressRepair=yes
SuppressOptionsUI=yes
LicenseUrl=
  /bal:WixStandardBootstrapperApplication
/BootstrapperApplicationRef

Dave Moss
Tactical Team Lead
OmPrompt
+44 (0)1235 436014 Direct
davidm...@omprompt.com
www.omprompt.com

OmPrompt Limited is registered in England  Wales, registration No. 4452522, 
with registered offices at 67 Innovation Drive, Milton Park, Abingdon, 
Oxfordshire. OX14 4RQ. UK. VAT No. 821339546.


-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 13 June 2013 14:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Suppress options in bundle [P]

Classification: Public
Oops using an extended bootstrapper extension my bad, see change:

BootstrapperApplicationRef 
Id=WixStandardBootstrapperApplication.HyperlinkLicense
  bal:WixStandardBootstrapperApplication
SuppressRepair=yes
SuppressOptionsUI=yes
LicenseUrl=
  /bal:WixStandardBootstrapperApplication
/BootstrapperApplicationRef

-Original Message-
From: Dave Moss [mailto:davidm...@omprompt.com]
Sent: June-13-13 8:59 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Suppress options in bundle [P]

Thanks Steve,

When I try and build that though I get 

The BootstrapperApplicationRef element contains an unexpected child element 
'bal:WixExtendedBootstrapperApplication'.

Dave Moss
Tactical Team Lead
OmPrompt
+44 (0)1235 436014 Direct
davidm...@omprompt.com
www.omprompt.com

OmPrompt Limited is registered in England  Wales, registration No. 4452522, 
with registered offices at 67 Innovation Drive, Milton Park, Abingdon, 
Oxfordshire. OX14 4RQ. UK. VAT No. 821339546.

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 13 June 2013 13:30
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Suppress options in bundle [P]

Classification: Public
Try this:

BootstrapperApplicationRef 
Id=WixExtendedBootstrapperApplication.HyperlinkLicense
  bal:WixExtendedBootstrapperApplication
SuppressRepair=yes
SuppressOptionsUI=yes
LicenseUrl=
  /bal:WixExtendedBootstrapperApplication
/BootstrapperApplicationRef
Steve
-Original Message-
From: Dave Moss [mailto:davidm...@omprompt.com]
Sent: June-13-13 8:16 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Suppress options in bundle

Hi all,

I am trying to hide the options button on my bundle install as the install 
folder is fixed and cannot be changed. I am having trouble getting

Re: [WiX-users] App-pool creation [P]

[Steven Ogilvie]

Classification: Public
Chatra,

I ended up creating a custom action since WIX doesn't have that element...

CustomAction Id=CA_Set_ENABLE32BITAPPPOOL 
Property=CA_ENABLE32BITAPPPOOL Value=[WEB_SITE_NAME]|/
CustomAction Id=CA_ENABLE32BITAPPPOOL BinaryKey=BIN_CustomAction 
DllEntry=Enable32BitApplicationPool Impersonate=no Execute=deferred 
Return=ignore/
UI
  ProgressText Action=CA_ENABLE32BITAPPPOOLCA: Setting 
enable32BitAppOnWin64 for application Pool.../ProgressText
/UI

Custom Action=CA_Set_ENABLE32BITAPPPOOL After=CostFinalizeNOT 
Installed/Custom Custom Action=CA_ENABLE32BITAPPPOOL 
Before=RegisterUserNOT Installed/Custom


/// summary
/// Enable32BitApplicationPool sets the App Pool property 
enable32BitAppOnWin64
/// true or false depending on the bit of the OS
/// /summary
/// param name=sessionSession session/param
/// returnsreturn ActionResult.Success/returns
[CustomAction]
public static ActionResult Enable32BitApplicationPool(Session session)
{
try
{
if (session == null)
{
throw new ArgumentNullException(session);
}

string tempString = GetSessionProperty(session, 
CustomActionData, false);
string[] parts = tempString.Split(new[] { '|' });
string applicationPool = parts[0];
const string Quote = \;
string cmdLineParameters = set apppool /apppool.name: + Quote 
+ applicationPool + Quote +  /enable32BitAppOnWin64:false;

var cmdLineExe = 
Environment.GetFolderPath(Environment.SpecialFolder.System) + 
\\inetsrv\\appcmd.exe;

// Prepare the process to run
var startInfo = new ProcessStartInfo
{
UseShellExecute = true,
Arguments = cmdLineParameters,
FileName = cmdLineExe,
WindowStyle = ProcessWindowStyle.Hidden,
CreateNoWindow = true
};

// Run the external process  wait for it to finish
using (Process proc = Process.Start(startInfo))
{
proc.WaitForExit();
}
}
catch (Exception ex)
{
WriteErrorLogInstall(session, Enable32BitApplicationPool 
failed: , ex, true);
}

return ActionResult.Success;
}

-Original Message-
From: chennam [mailto:chatrapathi.chen...@gmail.com]
Sent: June-14-13 4:39 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] App-pool creation

Hi,

When App-pool is created with the   iis:WebAppPool/; by default Enable
32-bit Application is set  to True .Just want to know how can I change this 
setting to False while Creating the App-pool.


Thanks in Advance
Chatra



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/App-pool-creation-tp7586553.html
Sent from the wix-users mailing list archive at Nabble.com.

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



This message has been marked as Public by Steven Ogilvie on June-14-13 4:52:40 
PM.

The above classification labels were added to the message by TITUS Message 
Classification. 
For more information visit www.titus.com.

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Suppress options in bundle [P]

[Steven Ogilvie]

Classification: Public
Try this:

BootstrapperApplicationRef 
Id=WixExtendedBootstrapperApplication.HyperlinkLicense
  bal:WixExtendedBootstrapperApplication
SuppressRepair=yes
SuppressOptionsUI=yes
LicenseUrl=
  /bal:WixExtendedBootstrapperApplication
/BootstrapperApplicationRef
Steve
-Original Message-
From: Dave Moss [mailto:davidm...@omprompt.com]
Sent: June-13-13 8:16 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Suppress options in bundle

Hi all,

I am trying to hide the options button on my bundle install as the install 
folder is fixed and cannot be changed. I am having trouble getting the 
SuppressOptionUI=yes to work.

I am using WiX 3.7 and here is my bundle.wxs from my VS2010 solution. Any help 
would be greatly appreciated.

?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
  Bundle Name=Document Converters Version=$(var.Version) 
Manufacturer=OmPrompt UpgradeCode=e2e24e5c-5fef-4c16-9b5d-469b67b269a7 
Condition=((VersionNT = v5.1) AND (ServicePackLevel = 3)) OR ((VersionNT = 
v5.2) AND (ServicePackLevel = 2)) OR (VersionNT = v6.0)
BootstrapperApplicationRef 
Id=WixStandardBootstrapperApplication.HyperlinkLicense 
  WixStandardBootstrapperApplication SuppressOptionsUI=yes /
/BootstrapperApplicationRef
WixVariable Id=WixStdbaLogo Value=Resource\logo.png /
WixVariable Id=WixStdbaLicenseUrl Value= /
Variable Name=InstallFolder Type=string 
Value=[ProgramFilesFolder]Omprompt\Document Converters /
Variable Name=LaunchTarget 
Value=[InstallFolder]\ConverterController.exe/

Chain
  PackageGroupRef Id=NetFx40Redist /

  RollbackBoundary /

  MsiPackage
Id=WIXConverterInstaller
Compressed=yes
SourceFile=$(var.WIXConverterInstaller.TargetPath)
Vital=yes
  /MsiPackage
/Chain
  /Bundle
/Wix


Thanks in advance,

Dave Moss
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



This message has been marked as Public by  on June-13-13 8:29:51 AM.

The above classification labels were added to the message by TITUS Message 
Classification. 
For more information visit www.titus.com.

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Suppress options in bundle [P]

[Steven Ogilvie]

Classification: Public
Oops using an extended bootstrapper extension my bad, see change:

BootstrapperApplicationRef 
Id=WixStandardBootstrapperApplication.HyperlinkLicense
  bal:WixStandardBootstrapperApplication
SuppressRepair=yes
SuppressOptionsUI=yes
LicenseUrl=
  /bal:WixStandardBootstrapperApplication
/BootstrapperApplicationRef

-Original Message-
From: Dave Moss [mailto:davidm...@omprompt.com]
Sent: June-13-13 8:59 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Suppress options in bundle [P]

Thanks Steve,

When I try and build that though I get 

The BootstrapperApplicationRef element contains an unexpected child element 
'bal:WixExtendedBootstrapperApplication'.

Dave Moss
Tactical Team Lead
OmPrompt
+44 (0)1235 436014 Direct
davidm...@omprompt.com
www.omprompt.com

OmPrompt Limited is registered in England  Wales, registration No. 4452522, 
with registered offices at 67 Innovation Drive, Milton Park, Abingdon, 
Oxfordshire. OX14 4RQ. UK. VAT No. 821339546.

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 13 June 2013 13:30
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Suppress options in bundle [P]

Classification: Public
Try this:

BootstrapperApplicationRef 
Id=WixExtendedBootstrapperApplication.HyperlinkLicense
  bal:WixExtendedBootstrapperApplication
SuppressRepair=yes
SuppressOptionsUI=yes
LicenseUrl=
  /bal:WixExtendedBootstrapperApplication
/BootstrapperApplicationRef
Steve
-Original Message-
From: Dave Moss [mailto:davidm...@omprompt.com]
Sent: June-13-13 8:16 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Suppress options in bundle

Hi all,

I am trying to hide the options button on my bundle install as the install 
folder is fixed and cannot be changed. I am having trouble getting the 
SuppressOptionUI=yes to work.

I am using WiX 3.7 and here is my bundle.wxs from my VS2010 solution. Any help 
would be greatly appreciated.

?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
  Bundle Name=Document Converters Version=$(var.Version) 
Manufacturer=OmPrompt UpgradeCode=e2e24e5c-5fef-4c16-9b5d-469b67b269a7 
Condition=((VersionNT = v5.1) AND (ServicePackLevel = 3)) OR ((VersionNT = 
v5.2) AND (ServicePackLevel = 2)) OR (VersionNT = v6.0)
BootstrapperApplicationRef 
Id=WixStandardBootstrapperApplication.HyperlinkLicense 
  WixStandardBootstrapperApplication SuppressOptionsUI=yes /
/BootstrapperApplicationRef
WixVariable Id=WixStdbaLogo Value=Resource\logo.png /
WixVariable Id=WixStdbaLicenseUrl Value= /
Variable Name=InstallFolder Type=string 
Value=[ProgramFilesFolder]Omprompt\Document Converters /
Variable Name=LaunchTarget 
Value=[InstallFolder]\ConverterController.exe/

Chain
  PackageGroupRef Id=NetFx40Redist /

  RollbackBoundary /

  MsiPackage
Id=WIXConverterInstaller
Compressed=yes
SourceFile=$(var.WIXConverterInstaller.TargetPath)
Vital=yes
  /MsiPackage
/Chain
  /Bundle
/Wix


Thanks in advance,

Dave Moss
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



This message has been marked as Public by  on June-13-13 8:29:51 AM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com.

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



This message has been marked as Public by  on June-13-13 9:21:29 AM.

The above classification labels were added to the message by TITUS Message 
Classification. 
For more information visit www.titus.com.

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo