Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea?

[Castro, Edwin G. (Hillsboro)]

I have successfully executed PowerShell scripts as CustomActions in MSI 
packages.

If you MUST use PowerShell, then all of the warnings concerning difficulty in 
debugging apply. You MUST fully understand the context under which the script 
is executing (user context, filesystem and registry redirection, etc). If you 
have alternatives for your CustomAction, then you should use those alternatives.

If you are deploying a native application, then write a native CustomAction.

If you are deploying a .NET application, then write a .NET CustomAction.

If you MUST use PowerShell to perform a task because the API available to you 
is a cmdlet provided by thirdparty *AND* you have no other way to perform the 
same task, then and only then is it appropriate to use a PowerShell script as a 
CustomAction to perform that task.

Don't bother writing .NET code to host the PowerShell engine to avoid using a 
PowerShell script as that is very, very hard to do correctly.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com

> -Original Message-
> From: Raghu [mailto:raghu_ti...@yahoo.com]
> Sent: Monday, March 11, 2013 6:05 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Is using Powershell script as a Wix Custom Action a good
> idea?
> 
> Hello Wix users,
> 
> I have a very simple custom action something on the lines of validating a key
> as part of setup, the min requirement that the setup to run is on Win2k8 R2+.
> Now I can achieve the same thing in a dll but I feel its an overkill and is 
> easily
> achieved in a script, for a while I was pondering over using vbscript until I
> read the warning in
> http://blogs.msdn.com/b/robmen/archive/2004/05/20/136530.aspx and
> decided against vbscript. Could folks point out if doing the same in
> powershell is ok?
> Thanks.,
> Raghu
> --
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to tackle
> endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Running PowerShell script...

[Castro, Edwin G. (Hillsboro)]

You need to get more information about what the powershell script is actually 
doing while it is doing it. For example, if you know that the Install-License 
cmdlet is supposed to change the registry, then update your script to write out 
the appropriate registry information immediately after the Install-License 
cmdlet finishes. Then you'll get a visual confirmation that at that point in 
time the information is there. I would assume it would probably write the 
information somewhere in HKLM:\SOFTWARE. If the tool you are using to check the 
registry is 32-bit then HKLM:\SOFTWARE will point to a different location in 
the registry and you won't see the changes.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com


> -Original Message-
> From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
> Sent: Wednesday, March 06, 2013 1:10 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Running PowerShell script...
>
> The 64 bit MSI is checking the 64 bit registry for the POWERSHELL exe via
> Win64=yes The Custom action now has DllEntry="CAQuietExec64"
>
> If I take the custom action value and run it in a CMD prompt it works, which
> means the Powershell PS1 script is good, and the custom action value is good
> as well it is returning 1 which means it "succeeded" but not really since it
> didn't run properly, the I checked the registry and it is not getting 
> populated
> at all...
>
> Sigh...
>
> Steve
>
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: March-06-13 3:59 PM
> To: General discussion for Windows Installer XML toolset.; chr...@iswix.com
> Subject: Re: [WiX-users] Running PowerShell script...
>
> Hosting the PowerShell engine is not an easy thing to do. If you must use the
> provided cmdlet then the easiest way to execute it will be with a script. 
> You'll
> just need to find out what it is doing and get your bitness all sorted out.
>
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
>
>
> > -Original Message-
> > From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
> > Sent: Wednesday, March 06, 2013 12:53 PM
> > To: chr...@iswix.com; General discussion for Windows Installer XML
> toolset.
> > Subject: Re: [WiX-users] Running PowerShell script...
> >
> > What is DTF, I googled it but I don't think you mean what urban slang
> > came up with ;)
> >
> > We are using NServiceBus as a service bus... its core dll has
> > PowerShell cmdlets within, we need to use one of its cmdlets to
> > register its license into the registry
> >
> > I tried running a C# custom action and was getting no real results, so
> > I thought I would create a simple PowerShell script to import-module
> > (the core dll) then run the cmdlet (install-license)
> >
> > I can successfully run this powershell script via the CMD prompt, but
> > within WIX it is not working :(
> >
> > Steve
> >
> > -Original Message-
> > From: Christopher Painter [mailto:chr...@iswix.com]
> > Sent: March-06-13 3:33 PM
> > To: General discussion for Windows Installer XML toolset.; General
> > discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Running PowerShell script...
> >
> > I guess I have to wonder
> >
> > Why run PowerShell period?
> >
> > I mean, DTF is very powerful and robust.  It's also possible to use
> > DTF to write a managed custom action and call PowerShell code from there.
> >
> > The only argument I ever here for PowerShell is it's for guys who know
> > how to script.  These "scripters" are exactly the guys I *DON'T* want
> > contributing to my installers.
> >
> > ??
> >
> > Chris
> >
> > 
> >  From: "Steven Ogilvie" 
> > Sent: Wednesday, March 06, 2013 2:20 PM
> > To: "General discussion for Windows Installer XML toolset."
> > 
> > Subject: Re: [WiX-users] Running PowerShell script...
> >
> > This is driving me crazy, how hard is it to run a PowerShell script...
> > If I run it in a CMD prompt PowerShell.exe .\RegisterLicense.xml it works!!!
> > My dev machine is Window 7 64 bit
> >
> > This DLL is not our DLL it is a 3rd party dll NServiceBus.Core.dll we
> > can not change it... they have the PowerShell cmdlets within the DLL
> > hence you ne

Re: [WiX-users] Running PowerShell script...

[Castro, Edwin G. (Hillsboro)]

:
> CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7
> Action 15:06:44:
> CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7. CA:
> Installing NServiceBus license...
> Action start 15:06:44:
> CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7.
> 1: CA: Installing NServiceBus license...
> Action ended 15:06:44:
> CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7.
> Return value 1.
>
> MSI (s) (5C:BC) [15:07:02:273]: Executing op:
> ActionStart(Name=CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_4F2C_9E74_
> FD373F99E9D7,
> Description=CA: Installing NServiceBus license...,) Action 15:07:02:
> CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7. CA:
> Installing NServiceBus license...
> MSI (s) (5C:BC) [15:07:02:274]: Executing op:
> CustomActionSchedule(Action=CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_
> 4F2C_9E74_FD
> 373F99E9D7,ActionType=3073,Source=BinaryData,Target=CAQuietExec64,Cu
> stomActi
> onData="C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
> -Version
> 3.0 -NoProfile -NonInteractive -InputFormat None -ExecutionPolicy Bypass -
> Command "& 'C:\Program Files\TITUS\TITUS
> Services\Common\RegisterLicense.ps1' ; exit $($Error.Count)") MSI (s)
> (5C:BC) [15:07:02:294]: Creating MSIHANDLE (829) of type 790536 for thread
> 8636 MSI (s) (5C:FC) [15:07:02:294]: Invoking remote custom action. DLL:
> C:\Windows\Installer\MSIF7EE.tmp, Entrypoint: CAQuietExec64 MSI (s)
> (5C!80) [15:07:02:381]: Creating MSIHANDLE (830) of type 790531 for thread
> 8832
> CAQuietExec64:  Entering CAQuietExec64 in
> C:\Windows\Installer\MSIF7EE.tmp, version 3.7.1224.0 MSI (s) (5C!80)
> [15:07:02:382]: Closing MSIHANDLE (830) of type 790531 for thread 8832 MSI
> (s) (5C!80) [15:07:02:382]: Creating MSIHANDLE (831) of type 790531 for
> thread 8832
> CAQuietExec64:
> "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
> -Version 3.0 -NoProfile -NonInteractive -InputFormat None -ExecutionPolicy
> Bypass -Command "& 'C:\Program Files\TITUS\TITUS
> Services\Common\RegisterLicense.ps1' ; exit $($Error.Count)"
>
> Property(S):
> CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7 =
> "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -
> Version 3.0 -NoProfile -NonInteractive -InputFormat None -ExecutionPolicy
> Bypass -Command "& 'C:\Program Files\TITUS\TITUS
> Services\Common\RegisterLicense.ps1' ; exit $($Error.Count)"
>
> Did not register the license, open a CMD prompt enter the above text and
> the license has been placed into the registery
>
> Steve
>
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: March-06-13 2:10 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Running PowerShell script...
>
> Looking back at your original email I see the following:
>
>  DllEntry="CAQuietExec" Execute="deferred" Return="check"
> Impersonate="no"
> />
>
> The DllEntry="CAQuietExec" attribute is putting you in 32-bit land.
>
> You need to use DllEntry="CAQuietExec" for 32-bit and
> DllEntry="CAQuietExec64" for 64-bit.
>
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
>
> > -Original Message-
> > From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
> > Sent: Wednesday, March 06, 2013 10:40 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Running PowerShell script...
> >
> > In this case it is a 64 bit MSI (our services installer has a 32 bit
> > and a 64 bit MSI based on the bitness of the OS, in this case testing
> > with 64 bit MSI) since the path is:
> > MSI (s) (30:B0) [12:56:34:248]: Executing op:
> >
> CustomActionSchedule(Action=CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_
> >
> 4F2C_9E74_FD373F99E9D7,ActionType=3073,Source=BinaryData,Target=Inst
> >
> allNServiceBusLicense,CustomActionData="C:\Windows\System32\Windows
> > PowerShell\v1.0\powershell.exe"|-NoProfile -NonInteractive
> > -InputFormat None -ExecutionPolicy Bypass -Command "& 'C:\Program
> > Files\MYCORP\MYCORP Services\Common\RegisterLicense.ps1' ; exit
> > $($Error.Count)"|C:\Program Files\TITUS\TITUS Services\Common)
> >
> > I even tried using a custom action in my CA DLL:
> >
> > [CustomAction]
> > public static ActionResult InstallNServiceBusLicense(Session
> session)
> >   

Re: [WiX-users] Running PowerShell script...

[Castro, Edwin G. (Hillsboro)]

ad
> 8636 MSI (s) (5C:FC) [15:07:02:294]: Invoking remote custom action. DLL:
> C:\Windows\Installer\MSIF7EE.tmp, Entrypoint: CAQuietExec64 MSI (s)
> (5C!80) [15:07:02:381]: Creating MSIHANDLE (830) of type 790531 for thread
> 8832
> CAQuietExec64:  Entering CAQuietExec64 in
> C:\Windows\Installer\MSIF7EE.tmp, version 3.7.1224.0 MSI (s) (5C!80)
> [15:07:02:382]: Closing MSIHANDLE (830) of type 790531 for thread 8832 MSI
> (s) (5C!80) [15:07:02:382]: Creating MSIHANDLE (831) of type 790531 for
> thread 8832
> CAQuietExec64:
> "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -
> Version 3.0 -NoProfile -NonInteractive -InputFormat None -ExecutionPolicy
> Bypass -Command "& 'C:\Program Files\TITUS\TITUS
> Services\Common\RegisterLicense.ps1' ; exit $($Error.Count)"
>
> Property(S):
> CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7 =
> "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -
> Version 3.0 -NoProfile -NonInteractive -InputFormat None -ExecutionPolicy
> Bypass -Command "& 'C:\Program Files\TITUS\TITUS
> Services\Common\RegisterLicense.ps1' ; exit $($Error.Count)"
>
> Did not register the license, open a CMD prompt enter the above text and
> the license has been placed into the registery
>
> Steve
>
>
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: March-06-13 2:10 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Running PowerShell script...
>
> Looking back at your original email I see the following:
>
>  DllEntry="CAQuietExec" Execute="deferred" Return="check"
> Impersonate="no" />
>
> The DllEntry="CAQuietExec" attribute is putting you in 32-bit land.
>
> You need to use DllEntry="CAQuietExec" for 32-bit and
> DllEntry="CAQuietExec64" for 64-bit.
>
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
>
>
> > -Original Message-
> > From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
> > Sent: Wednesday, March 06, 2013 10:40 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Running PowerShell script...
> >
> > In this case it is a 64 bit MSI (our services installer has a 32 bit
> > and a 64 bit MSI based on the bitness of the OS, in this case testing
> > with 64 bit MSI) since the path is:
> > MSI (s) (30:B0) [12:56:34:248]: Executing op:
> >
> CustomActionSchedule(Action=CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_
> >
> 4F2C_9E74_FD373F99E9D7,ActionType=3073,Source=BinaryData,Target=Inst
> >
> allNServiceBusLicense,CustomActionData="C:\Windows\System32\Windows
> > PowerShell\v1.0\powershell.exe"|-NoProfile -NonInteractive
> > -InputFormat None -ExecutionPolicy Bypass -Command "& 'C:\Program
> > Files\MYCORP\MYCORP Services\Common\RegisterLicense.ps1' ; exit
> > $($Error.Count)"|C:\Program Files\TITUS\TITUS Services\Common)
> >
> > I even tried using a custom action in my CA DLL:
> >
> > [CustomAction]
> > public static ActionResult InstallNServiceBusLicense(Session 
> > session)
> > {
> > try
> > {
> > if (session == null)
> > {
> > throw new ArgumentNullException("session");
> > }
> >
> > var tempString = GetSessionProperty(session,
> > "CustomActionData", false);
> > var parts = tempString.Split(new[] { '|' });
> > var cmdLineExe = parts[0];
> > var cmdLineParameters = parts[1];
> > var commonFolder = parts[2];
> >
> > var path = @commonFolder + "\\RegisterLicense.ps1";
> >
> > var currentFolder = Directory.GetCurrentDirectory();
> > Directory.SetCurrentDirectory(commonFolder);
> >
> > if (Directory.Exists(commonFolder))
> > {
> > // Create a file to write to.
> > using (StreamWriter sw = File.CreateText(path))
> > {
> > sw.WriteLine("CD " + commonFolder);
> > sw.WriteLine("Import-Module 
> > .\\NServiceBus.Core.dll");
> >     sw.WriteLine(&

Re: [WiX-users] Running PowerShell script...

[Castro, Edwin G. (Hillsboro)]

Looking back at your original email I see the following:



The DllEntry="CAQuietExec" attribute is putting you in 32-bit land.

You need to use DllEntry="CAQuietExec" for 32-bit and DllEntry="CAQuietExec64" 
for 64-bit.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com


> -Original Message-
> From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
> Sent: Wednesday, March 06, 2013 10:40 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Running PowerShell script...
>
> In this case it is a 64 bit MSI (our services installer has a 32 bit and a 64 
> bit MSI
> based on the bitness of the OS, in this case testing with 64 bit MSI) since 
> the
> path is:
> MSI (s) (30:B0) [12:56:34:248]: Executing op:
> CustomActionSchedule(Action=CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_
> 4F2C_9E74_FD373F99E9D7,ActionType=3073,Source=BinaryData,Target=Inst
> allNServiceBusLicense,CustomActionData="C:\Windows\System32\Windows
> PowerShell\v1.0\powershell.exe"|-NoProfile -NonInteractive -InputFormat
> None -ExecutionPolicy Bypass -Command "& 'C:\Program
> Files\MYCORP\MYCORP Services\Common\RegisterLicense.ps1' ; exit
> $($Error.Count)"|C:\Program Files\TITUS\TITUS Services\Common)
>
> I even tried using a custom action in my CA DLL:
>
> [CustomAction]
> public static ActionResult InstallNServiceBusLicense(Session session)
> {
> try
> {
> if (session == null)
> {
> throw new ArgumentNullException("session");
> }
>
> var tempString = GetSessionProperty(session, 
> "CustomActionData",
> false);
> var parts = tempString.Split(new[] { '|' });
> var cmdLineExe = parts[0];
> var cmdLineParameters = parts[1];
> var commonFolder = parts[2];
>
> var path = @commonFolder + "\\RegisterLicense.ps1";
>
> var currentFolder = Directory.GetCurrentDirectory();
> Directory.SetCurrentDirectory(commonFolder);
>
> if (Directory.Exists(commonFolder))
> {
> // Create a file to write to.
> using (StreamWriter sw = File.CreateText(path))
> {
> sw.WriteLine("CD " + commonFolder);
> sw.WriteLine("Import-Module .\\NServiceBus.Core.dll");
> sw.WriteLine("Install-License -Path .\\License.xml");
> }
> }
>
> // run PowerShell on the script
> if (File.Exists(path))
> {
> var runPowerShellInfo = new ProcessStartInfo
> {
> UseShellExecute = true,
> Arguments = cmdLineParameters,
> FileName = cmdLineExe,
> WindowStyle = ProcessWindowStyle.Hidden,
> CreateNoWindow = true
> };
>
> // Run the external process & wait for it to finish
> using (Process runPowerShellProc =
> Process.Start(runPowerShellInfo))
> {
> runPowerShellProc.WaitForExit();
> }
>     }
>
> Directory.SetCurrentDirectory(currentFolder);
> }
> catch (Exception ex)
> {
> WriteErrorLogInstall(session, "InstallNServiceBusLicense 
> failed: ", ex,
> true);
> }
>
> return ActionResult.Success;
> }
>
>
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: March-06-13 1:22 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Running PowerShell script...
>
> The useLegacyV2RuntimeActivationPolicy="true" is what allows .NET 4 to
> load .NET 2 assemblies so you need that. You don't want to remove it.
>
> I assume you checked the system where the MSI is installing so my next
> guess is that 64-bit powershell has the configuration file while 32-bit
> powershell does not and the MSI is executing 32-bit powershell.
>
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
>
> >

Re: [WiX-users] Running PowerShell script...

[Castro, Edwin G. (Hillsboro)]

The useLegacyV2RuntimeActivationPolicy="true" is what allows .NET 4 to load 
.NET 2 assemblies so you need that. You don't want to remove it.

I assume you checked the system where the MSI is installing so my next guess is 
that 64-bit powershell has the configuration file while 32-bit powershell does 
not and the MSI is executing 32-bit powershell.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com

> -Original Message-
> From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
> Sent: Wednesday, March 06, 2013 9:53 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Running PowerShell script...
> 
> Hmm
> 
> Your right I have PS version 3 but the powershell config is loading .NET 4
> 
>  
> 
> 
> 
> 
> 
> So why is it still failing? Is it because of the legacyV2 is set to true?
> 
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: March-06-13 12:25 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Running PowerShell script...
> 
> My guess would be that you have PowerShell v3 installed on your system.
> Check the value of the $PSVersionTable variable in PowerShell as that will
> give you detailed version information for PowerShell.
> 
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> 
> > -Original Message-
> > From: StevenOgilvie [mailto:sogil...@msn.com]
> > Sent: Tuesday, March 05, 2013 9:43 PM
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] Running PowerShell script...
> >
> > Why is it that I can run the script in a dos box I.e.  powershell.exe
> > .\registerlicense.ps1 and it works __ Steven
> > Ogilvie
> >
> > Sent from my BlackBerry...
> >
> > 3 - 45 Bertrand Street
> > Ottawa, ON
> > Canada
> > K1M 1Y5
> >
> > Mobile: +1 613 299-2121
> > E-mail:  sogil...@msn.com
> >
> > -Original Message-
> > From: "Edwin G. Castro [via Windows Installer XML (WiX) toolset]"  > node+s687559n7584125...@n2.nabble.com>
> > Date: Tue, 5 Mar 2013 23:00:13
> > To: 
> > Subject: Re: Running PowerShell script...
> >
> > Here's the bit that's important:
> >
> > CAQuietExec:  Import-Module : Could not load file or assembly
> > 'file:///C:\Program Files\MYCORP
> > CAQuietExec:  \MYCORP Services\Common\NServiceBus.Core.dll' or one of
> > its dependencies. This a
> > CAQuietExec:  ssembly is built by a runtime newer than the currently
> > loaded runtime and cannot be loaded.
> >
> > This is telling you that the assembly you are trying to load is
> > probably compiled against .NET 4 while PowerShell is loading the .NET 2
> runtime.
> > PowerShell v3 loads the .NET 4 runtime but PowerShell v2 still only
> > loads the .NET 2 runtime. The easiest solution if you can manage it is
> > to get NServiceBus.Core.dll compiled against the .NET 2 runtime (.NET
> > 3.5 would work too). Otherwise you'll need to decide whether you'll
> > only support PowerShell v3 OR create/customize a PowerShell.exe.config
> > that allows PowerShell to load the .NET 4 runtime.
> >
> > Edwin G. Castro
> > Software Developer - Staff
> > Digital Channels
> > Fiserv
> > Office: 503-746-0643
> > Fax: 503-617-0291
> > www.fiserv.com
> >
> >
> > > -Original Message-
> > > From: StevenOgilvie [mailto:[hidden email]
> > >  ]
> > > Sent: Tuesday, March 05, 2013 2:14 PM
> > > To: [hidden email]
> 
> > > Subject: [WiX-users] Running PowerShell script...
> > >
> > > Hi guys
> > >
> > > I have googled and done everything I think I should have done but I
> > > am getting a funky error in the MSI log file, has anyone else had
> > > this issue, if so how did you fix it?
> > >
> > > Install the Powershell file
> > >  > > Guid="{276C369D-BF32-472F-A7FC-24155DEB18DE}">
> > >            > > Source="..\$(var.resourcePath)\RegisterLicense.ps1" />
> > >         
> > >
> > >
> > > Set the custom action
> > >  > > Property="CA_NSERVICEBUSLICENSE"
> > > Value =""[POWERSHELLEXE]" -Version 2.0 -NoProfile -
> > > NonInteractive -InputFormat None -Execut

Re: [WiX-users] Running PowerShell script...

[Castro, Edwin G. (Hillsboro)]

My guess would be that you have PowerShell v3 installed on your system. Check 
the value of the $PSVersionTable variable in PowerShell as that will give you 
detailed version information for PowerShell.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com

> -Original Message-
> From: StevenOgilvie [mailto:sogil...@msn.com]
> Sent: Tuesday, March 05, 2013 9:43 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Running PowerShell script...
> 
> Why is it that I can run the script in a dos box I.e.  powershell.exe
> .\registerlicense.ps1 and it works __ Steven Ogilvie
> 
> Sent from my BlackBerry...
> 
> 3 - 45 Bertrand Street
> Ottawa, ON
> Canada
> K1M 1Y5
> 
> Mobile: +1 613 299-2121
> E-mail:  sogil...@msn.com
> 
> -Original Message-
> From: "Edwin G. Castro [via Windows Installer XML (WiX) toolset]"  node+s687559n7584125...@n2.nabble.com>
> Date: Tue, 5 Mar 2013 23:00:13
> To: 
> Subject: Re: Running PowerShell script...
> 
>   Here's the bit that's important:
> 
> CAQuietExec:  Import-Module : Could not load file or assembly
> 'file:///C:\Program Files\MYCORP
> CAQuietExec:  \MYCORP Services\Common\NServiceBus.Core.dll' or one of
> its dependencies. This a
> CAQuietExec:  ssembly is built by a runtime newer than the currently loaded
> runtime and cannot be loaded.
> 
> This is telling you that the assembly you are trying to load is probably
> compiled against .NET 4 while PowerShell is loading the .NET 2 runtime.
> PowerShell v3 loads the .NET 4 runtime but PowerShell v2 still only loads the
> .NET 2 runtime. The easiest solution if you can manage it is to get
> NServiceBus.Core.dll compiled against the .NET 2 runtime (.NET 3.5 would
> work too). Otherwise you'll need to decide whether you'll only support
> PowerShell v3 OR create/customize a PowerShell.exe.config that allows
> PowerShell to load the .NET 4 runtime.
> 
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> 
> 
> > -Original Message-
> > From: StevenOgilvie [mailto:[hidden email]
> >  ]
> > Sent: Tuesday, March 05, 2013 2:14 PM
> > To: [hidden email] 
> > Subject: [WiX-users] Running PowerShell script...
> >
> > Hi guys
> >
> > I have googled and done everything I think I should have done but I am
> > getting a funky error in the MSI log file, has anyone else had this
> > issue, if so how did you fix it?
> >
> > Install the Powershell file
> >  > Guid="{276C369D-BF32-472F-A7FC-24155DEB18DE}">
> >            > Source="..\$(var.resourcePath)\RegisterLicense.ps1" />
> >         
> >
> >
> > Set the custom action
> >  > Property="CA_NSERVICEBUSLICENSE"
> > Value =""[POWERSHELLEXE]" -Version 2.0 -NoProfile -
> > NonInteractive -InputFormat None -ExecutionPolicy Bypass -Command
> > "& '[#file_RegisterNServiceBusLicense]' ; exit
> > $$($Error.Count)"" />
> >      > DllEntry="CAQuietExec" Execute="deferred" Return="check"
> > Impersonate="no" />
> >     
> >       CA: Installing
> > NServiceBus license...
> >     
> >
> > Sequence the custom action
> > 
> >  > After="InstallValidate">  > Action="CA_NSERVICEBUSLICENSE" Before="InstallServices">NOT
> > Installed
> >
> > Get the powershell path:
> >
> >     
> >        >                       Type="raw"
> >                       Root="HKLM"
> >
> > Key="SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell"
> >                       Name="Path" />
> >     
> >     
> >
> >     
> >
> > The powershell script itself is pretty basic:
> > C:
> > CD "C:\Program Files\MYCORP\MYCORP Services\Common"
> > Import-Module .\NServiceBus.Core.dll
> > Install-License -Path .\License.xml
> >
> >
> > The error in the msi logfile:
> >
> > Action 17:00:34:
> > CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7.
> > CA: Installing NServiceBus license...
> > MSI (s) (5C:48) [17:00:34:296]: Executing op:
> >
> CustomActionSchedule(Action=CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_
> >
> 4F2C_9E74_FD373F99E9D7,ActionType=3073,Source=BinaryData,Target=CAQ
> >
> uietExec,CustomActionData="C:\Windows\System32\WindowsPowerShell\v
> > 1.0\powershell.exe"
> > -Version 2.0 -NoProfile -NonInteractive -InputFormat None
> > -ExecutionPolicy Bypass -Command "& 'C:\Program
> > Files\MYCORP\MYCORPServices\Common\RegisterLicense.ps1' ; exit
> > $($Error.Count)")
> > MSI (s) (5C:64) [17:00:34:317]: Invoking remote custom action. DLL:
> > C:\Windows\Installer\MSI8EA2.tmp, Entrypoint: CAQuietExec
> > CAQuietExec:  Entering CAQuietExec in
> > C:\Windows\Installer\MSI8EA2.tmp, version 3.7.1224.0
> > CAQuietExec:
> > "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
> > -Version 2.0 -NoProfile -NonInteractive -InputFormat None
> > -ExecutionPolicy Bypass -Command "& 'C:\Program
> Files\MYCORP\MYCORP
> > Services\Common\RegisterLicense.ps1' ; exit $($Error.Count)"
> > CAQuietExec:  Import-Module : Could not lo

Re: [WiX-users] Running PowerShell script...

[Castro, Edwin G. (Hillsboro)]

Here's the bit that's important:

CAQuietExec:  Import-Module : Could not load file or assembly 
'file:///C:\Program Files\MYCORP
CAQuietExec:  \MYCORP Services\Common\NServiceBus.Core.dll' or one of its 
dependencies. This a
CAQuietExec:  ssembly is built by a runtime newer than the currently loaded 
runtime and cannot be loaded.

This is telling you that the assembly you are trying to load is probably 
compiled against .NET 4 while PowerShell is loading the .NET 2 runtime. 
PowerShell v3 loads the .NET 4 runtime but PowerShell v2 still only loads the 
.NET 2 runtime. The easiest solution if you can manage it is to get 
NServiceBus.Core.dll compiled against the .NET 2 runtime (.NET 3.5 would work 
too). Otherwise you'll need to decide whether you'll only support PowerShell v3 
OR create/customize a PowerShell.exe.config that allows PowerShell to load the 
.NET 4 runtime.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com

> -Original Message-
> From: StevenOgilvie [mailto:sogil...@msn.com]
> Sent: Tuesday, March 05, 2013 2:14 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Running PowerShell script...
> 
> Hi guys
> 
> I have googled and done everything I think I should have done but I am
> getting a funky error in the MSI log file, has anyone else had this issue, if 
> so
> how did you fix it?
> 
> Install the Powershell file
>  Guid="{276C369D-BF32-472F-A7FC-24155DEB18DE}">
>Source="..\$(var.resourcePath)\RegisterLicense.ps1" />
> 
> 
> 
> Set the custom action
>  Property="CA_NSERVICEBUSLICENSE"
> Value =""[POWERSHELLEXE]" -Version 2.0 -NoProfile -
> NonInteractive -InputFormat None -ExecutionPolicy Bypass -Command
> "& '[#file_RegisterNServiceBusLicense]' ; exit
> $$($Error.Count)"" />
>  DllEntry="CAQuietExec" Execute="deferred" Return="check"
> Impersonate="no" />
> 
>   CA: Installing
> NServiceBus license...
> 
> 
> Sequence the custom action
> 
>  After="InstallValidate">  Action="CA_NSERVICEBUSLICENSE" Before="InstallServices">NOT
> Installed
> 
> Get the powershell path:
> 
> 
>  Type="raw"
>   Root="HKLM"
> 
> Key="SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell"
>   Name="Path" />
> 
> 
> 
> 
> 
> The powershell script itself is pretty basic:
> C:
> CD "C:\Program Files\MYCORP\MYCORP Services\Common"
> Import-Module .\NServiceBus.Core.dll
> Install-License -Path .\License.xml
> 
> 
> The error in the msi logfile:
> 
> Action 17:00:34:
> CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7.
> CA: Installing NServiceBus license...
> MSI (s) (5C:48) [17:00:34:296]: Executing op:
> CustomActionSchedule(Action=CA_NSERVICEBUSLICENSE.CA23A0DC_B2DE_
> 4F2C_9E74_FD373F99E9D7,ActionType=3073,Source=BinaryData,Target=CAQ
> uietExec,CustomActionData="C:\Windows\System32\WindowsPowerShell\v
> 1.0\powershell.exe"
> -Version 2.0 -NoProfile -NonInteractive -InputFormat None -ExecutionPolicy
> Bypass -Command "& 'C:\Program
> Files\MYCORP\MYCORPServices\Common\RegisterLicense.ps1' ; exit
> $($Error.Count)")
> MSI (s) (5C:64) [17:00:34:317]: Invoking remote custom action. DLL:
> C:\Windows\Installer\MSI8EA2.tmp, Entrypoint: CAQuietExec
> CAQuietExec:  Entering CAQuietExec in C:\Windows\Installer\MSI8EA2.tmp,
> version 3.7.1224.0
> CAQuietExec:
> "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
> -Version 2.0 -NoProfile -NonInteractive -InputFormat None -ExecutionPolicy
> Bypass -Command "& 'C:\Program Files\MYCORP\MYCORP
> Services\Common\RegisterLicense.ps1' ; exit $($Error.Count)"
> CAQuietExec:  Import-Module : Could not load file or assembly
> 'file:///C:\Program Files\MYCORP
> CAQuietExec:  \MYCORP Services\Common\NServiceBus.Core.dll' or one of
> its dependencies. This a
> CAQuietExec:  ssembly is built by a runtime newer than the currently loaded
> runtime and cannot be loaded.
> CAQuietExec:  At C:\Program Files\MYCORP\MYCORP
> Services\Common\RegisterLicense.ps1:5 char:14
> CAQuietExec:  + Import-Module   .\NServiceBus.Core.dll  + CategoryInfo
> : NotSpecified: (:) , BadImageFormatException
> CAQuietExec:  + FullyQualifiedErrorId :
> System.BadImageFormatException,Microsoft.PowerShell.Commands.Import
> ModuleCommand
> CAQuietExec:
> CAQuietExec:  Install-License : The term 'Install-License' is not recognized 
> as
> the name of a
> CAQuietExec:   cmdlet, function, script file, or operable program. Check the
> spelling of the
> CAQuietExec:  name, or if a path was included, verify that the path is correct
> and try again.
> CAQuietExec:  At C:\Program Files\MYCORP\MYCORP
> Services\Common\RegisterLicense.ps1:6 char:16
> CAQuietExec:  + Install-License   -Path .\License.xml
> CAQuietExec:  + CategoryInfo  : ObjectNotFound:
> (Install-License:String) , Com
> CAQuietExec: mandNotFoundException
> CAQuietExec:  + FullyQualifiedErrorId

Re: [WiX-users] Service not starting

[Castro, Edwin G. (Hillsboro)]

Services in Windows are not background processes. They are processes that 
support a very specific API for service management 
(Start/Stop/Suspend/Resume/etc). My gut says that the java VM doesn't natively 
support that API which is going to cause problems when the system tells the 
"service" to start. Searching for java windows service on Google yielded a 
number of results that say you'll need to use a wrapper to execute your java 
app as a windows service.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com

> -Original Message-
> From: Alain Forget [mailto:afor...@cmu.edu]
> Sent: Sunday, February 17, 2013 1:05 PM
> To: 'Phil Wilson'; 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Service not starting
> 
> The batch file starts several java programs, like this:
> 
> start java -cp Dependencies1.jar ClassToRun1.class start java -cp
> Dependencies2.jar ClassToRun2.class start java -cp Dependencies3.jar
> ClassToRun3.class
> 
> Although this is kind of getting out of the realm of WiX, how would you
> recommend I start the Java programs as services (since I want to make sure
> they run when the computer starts up and are very much in the
> background)?
> 
> Thanks,
> Alain
> 
> -Original Message-
> From: Phil Wilson [mailto:phil.wil...@mvps.org]
> Sent: February 17, 2013 13:58
> To: afor...@cmu.edu; 'General discussion for Windows Installer XML
> toolset.'
> Subject: RE: [WiX-users] Service not starting
> 
> You have a .bat file for the name - that doesn't seem correct to me. The
> ServiceInstall table in an MSI file requires a service executable.
> 
> Phil
> 
> -Original Message-
> From: Alain Forget [mailto:afor...@cmu.edu]
> Sent: Sunday, February 17, 2013 7:36 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Service not starting
> 
> Hi all,
> 
> Our installer creates and tries to start a service, but it fails to start 
> with the
> following error message:
> 
> "Service 'My Service' (MyService) failed to start. Verify that you have
> sufficient privileges to start system services."
> 
> However, before files begin to be installed, the UAC prompts the user for
> permission to make system changes, which we believe is invoked by the
> following statement in our .wxs:
> 
> 
>   Privileged OR AdminUser
> 
> 
> Here are the service-related statements:
> 
> 
>Source='MyService.bat' KeyPath='yes' />
>  Id="MyService"
>   Account="LocalSystem"
>   Description="Runs my sensor service"
>   DisplayName="My Service"
>   ErrorControl="ignore"
>   Interactive="no"
>   Name="MyService"
>   Start="auto"
>   Type="ownProcess"
>   Vital="yes"
>   >
>   
> 
>  Id="StartService"
>   Name="MyService"
>   Remove="uninstall"
>   Start="install"
>   Stop="both"
>   Wait="yes"
>   />
> 
> 
> So any thoughts on why our service doesn't start? We haven't found
> anything that seemed relevant searching the internet, so any ideas would be
> most appreciated.
> 
> Thanks,
> Alain
> 
> 
> 
> --
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is
> your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> 
> --
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is
> your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel

Re: [WiX-users] Upgrades NOT working on a new install....

[Castro, Edwin G. (Hillsboro)]

What do you mean by "When I run the second it's like the first one was not 
installed, it was like running a fresh install"? Does the verbose log tell you 
whether 4.0.1.25 was detected and uninstalled? I guess I should also ask the 
obvious question, did you change UpgradeCode?

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com


> -Original Message-
> From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
> Sent: Thursday, December 20, 2012 12:13 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Upgrades NOT working on a new install
> 
> Okay I changed the ProductCode to be "*" as well as the Package Id="*"
> First MSI had a version number of 4.0.1.25 second MSI has a version number
> of 4.1.2.55
> 
> When I run the second it's like the first one was not installed, it was like
> running a fresh install... the newer MSI has a different version number
> (higher) and the ProductCode is different...
> 
> Steve
> 
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: December-20-12 2:55 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Upgrades NOT working on a new install
> 
> You need to change ProductCode *and* ProductVersion for a major upgrade
> to work as you expect. When you change ProductVersion and leave
> ProductCode the same you have a minor upgrade which requires a different
> style of install (I'm not expert on installing minor upgrades). The reason it 
> was
> suggested to set Product/@Id = "*" is so that WiX will automatically create a
> new guid on every build guaranteeing a major upgrade if and only if you also
> change ProductVersion on every build.
> 
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> 
> 
> > -Original Message-
> > From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
> > Sent: Thursday, December 20, 2012 11:26 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Upgrades NOT working on a new install
> >
> > Okay,
> >
> > I now have:
> >
> >  >Name="$(var.PlatformProductName)"
> >Language="1033"
> >Version="4.0.2.30"
> >Manufacturer="$(var.ProductCompany)"
> >UpgradeCode="$(var.UpgradeCode)">
> >  >  InstallPrivileges="elevated"
> >  Manufacturer="$(var.ProductCompany)"
> >  InstallerVersion="405"
> >  Compressed="yes"
> >  InstallScope="perMachine"/>
> >
> >
> > 
> >  
> >> Property="NEWERVERSIONDETECTED" />
> >> Maximum="$(var.ProductVersion)" IncludeMinimum="yes"
> > IncludeMaximum="no" Property="OLDERVERSIONBEINGUPGRADED" />
> 
> >
> > Where:  in an include file I
> > include in my product.wxs 
> >   
> >   
> >   
> >
> > 
> >   NOT NEWERVERSIONDETECTED
> > 
> >
> > 
> >   
> >
> > I create one msi with productversion of 4.0.1.25 install it, then
> > change productversion to 4.0.2.30 and run it and I get the same error:
> >
> > "Another version of this product is already installed. Installation of
> > this version cannot continue. To configure or remove the existing
> > version of this product, use Add/Remove Programs on the Control Panel"
> >
> > Sigh,
> >
> > Steve
> >
> > -Original Message-
> > From: Neil Sleightholm [mailto:n...@x2systems.com]
> > Sent: December-20-12 1:47 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Upgrades NOT working on a new install
> >
> > You seem to have the MajorUpgrade element and also the Upgrade
> > element, MajorUpgrade replaces the need for manually authoring the
> > upgrade table. Also, I wouldn't hard code Product/@Id just use "*" and
> > have WiX generate it for you, likewise Package/@Id isn't required just
> > let WiX do it.
> >
> > Neil
> >
> > -Original Message-
> > From: StevenOgilvie [mailto:sogil...@msn.com]
> > Sent: 20 December 2012 18:26
> > To: wix-users@lists.

Re: [WiX-users] Upgrades NOT working on a new install....

[Castro, Edwin G. (Hillsboro)]

You need to change ProductCode *and* ProductVersion for a major upgrade to work 
as you expect. When you change ProductVersion and leave ProductCode the same 
you have a minor upgrade which requires a different style of install (I'm not 
expert on installing minor upgrades). The reason it was suggested to set 
Product/@Id = "*" is so that WiX will automatically create a new guid on every 
build guaranteeing a major upgrade if and only if you also change 
ProductVersion on every build.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com


> -Original Message-
> From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
> Sent: Thursday, December 20, 2012 11:26 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Upgrades NOT working on a new install
> 
> Okay,
> 
> I now have:
> 
> Name="$(var.PlatformProductName)"
>Language="1033"
>Version="4.0.2.30"
>Manufacturer="$(var.ProductCompany)"
>UpgradeCode="$(var.UpgradeCode)">
>   InstallPrivileges="elevated"
>  Manufacturer="$(var.ProductCompany)"
>  InstallerVersion="405"
>  Compressed="yes"
>  InstallScope="perMachine"/>
> 
> 
> 
>  
>Property="NEWERVERSIONDETECTED" />
>Maximum="$(var.ProductVersion)" IncludeMinimum="yes"
> IncludeMaximum="no" Property="OLDERVERSIONBEINGUPGRADED" />
> 
> 
> Where:  in an include file I include in
> my product.wxs 
>   
>   
>   
> 
> 
>   NOT NEWERVERSIONDETECTED
> 
> 
> 
>   
> 
> I create one msi with productversion of 4.0.1.25 install it, then change
> productversion to 4.0.2.30 and run it and I get the same error:
> 
> "Another version of this product is already installed. Installation of this
> version cannot continue. To configure or remove the existing version of this
> product, use Add/Remove Programs on the Control Panel"
> 
> Sigh,
> 
> Steve
> 
> -Original Message-
> From: Neil Sleightholm [mailto:n...@x2systems.com]
> Sent: December-20-12 1:47 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Upgrades NOT working on a new install
> 
> You seem to have the MajorUpgrade element and also the Upgrade
> element, MajorUpgrade replaces the need for manually authoring the
> upgrade table. Also, I wouldn't hard code Product/@Id just use "*" and have
> WiX generate it for you, likewise Package/@Id isn't required just let WiX do
> it.
> 
> Neil
> 
> -Original Message-
> From: StevenOgilvie [mailto:sogil...@msn.com]
> Sent: 20 December 2012 18:26
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Upgrades NOT working on a new install
> 
> Hi all,
> 
> I have implemented upgrades by doing the following (I have an include file
> that has the product/package properties which I define and include the
> include file :)...
> 
> Name="$(var.PlatformProductName)"
>Language="1033"
>Version="4.0.1.25"
>Manufacturer="$(var.ProductCompany)"
>UpgradeCode="$(var.UpgradeCode)">
>   InstallPrivileges="elevated"
>  Manufacturer="$(var.ProductCompany)"
>  InstallerVersion="405"
>  Compressed="yes"
>  InstallScope="perMachine"/>Schedule="afterInstallInitialize"
>   DowngradeErrorMessage="A later version of
> $(var.PlatformProductName) is already installed. Setup will now exit."/>
> 
> then:
> 
>Property="NEWERVERSIONDETECTED" />
>Maximum="$(var.ProductVersion)"
>   IncludeMinimum="yes" IncludeMaximum="no"
>   Property="OLDERVERSIONBEINGUPGRADED" /> 
> where I have the following defined:
> 
> 
> and have a productcode and upgradecode that I don't change...
> 
> customactions:
> 
>  Value="amus"
> />
> 
>   CA: Setting REINSTALLMODE to
> amus...
> 
> 
> 
>   CA: Setting up
> NEWAPPFOUND...
> 
> 
> 
>   
>   
>   
>After="FindRelatedProducts">NEWAPPFOUND
> 
> 
>   NOT NEWERVERSIONDETECTED
> 
> 
> 
>   
>After="FindRelatedProducts">NEWAPPFOUND
> 
> I then built the .MSI and installed it...
> 
> I then changed the product version to 4.0.2.30 and change the Package ID to
> another GUID re built the .MSI and launched it...
> 
> Instead of a message regarding upgrade minor I get a message: "Another
> version of this product is already installed. Installation of this version 
> cannot
> continue. To configure or remove the existing version of this product, use
> Add/Remove Programs on the Control Panel"
> 
> What am I doing wrong? I followed the suggestions from:
> http://wix.tramontana.co.hu/tutorial/upgrades-and-modularization
> 
> This is a new install so I was just making sure I had upgrades covered for
> down the road :(
> 
> thanks,
> 
> STeve
> 
> 
> 
> 
>

Re: [WiX-users] Project reference question

[Castro, Edwin G. (Hillsboro)]

I think I understand what you are describing. I think we have a similar setup. 
We have a lot of solutions that follow this pattern (please let me know if this 
does not accurately describe what you are trying to describe):

The solution has one or more assembly projects, each with many file references 
for dependencies.
The solution has one project for the windows service host with one or more 
project references to other projects in the solution and file references to all 
required dependencies.
The solution as one wix project for the msi with a project reference to the 
windows service host project. In the wix source you use 
$(var.WindowsServiceHostProjectName.TargetDir) to locate all of the files that 
need to be packaged.

I believe this is a convenient way to locate all required files for your MSI as 
the windows service host project requires all of these files for dev testing 
anyway.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Brownfield, Cory [mailto:cbrownfi...@aeci.org]
> Sent: Tuesday, November 27, 2012 6:51 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Project reference question
> 
> My team has decided to add only the top-level project reference to the WiX
> project in each solution.  We typically have simple builds where each solution
> has one WiX project that builds a single MSI.  So if we have a service 
> solution,
> we will be adding a single project reference to our WiX project for the
> Windows Service Host.  Since that project gets a copy of all other project and
> library DLLs when built (we will be making sure of that), we will just be
> referencing the DLLs from this top-level build directory in the WiX script.
> 
> This seems to be wrong, but I can't come up with a compelling argument as
> to why.  What problems might be introduced by using this method?  If this is
> a perfectly valid method, let me know.
> --
> Monitor your physical, virtual and cloud infrastructure from a single web
> console. Get in-depth insight into apps, servers, databases, vmware, SAP,
> cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX Source howto?

[Castro, Edwin G. (Hillsboro)]

> From: Filip Balas [mailto:fba...@petersco.com]
> Is working with the latest version of WiX from source control what most
> people do? 

If you are looking to build the WiX source code then I think you should get the 
version of WiX that has the features you want/need. The latest version has 
build system improvements that make it much easier to build the WiX source code.

I think _most_ people do *NOT* build the WiX source code at any version. They 
instead consume WiX by using a published setup package.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Missing setup.exe

[Castro, Edwin G. (Hillsboro)]

Make sure you are building the same solution configuration|platform on both 
machines. My guess is that a different solution configuration|platform is 
selected (active) on the different machines resulting in a different subset of 
projects getting built. Perhaps one has the AnyCPU platform selected and the 
other has Mixed Platforms selected... or something similar.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Sidky Macatangay [mailto:y2k...@gmail.com]
> Sent: Monday, October 29, 2012 11:15 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Missing setup.exe
> 
> I have one machine where both setup.exe and the .msi files are being
> generated whenever a Build/Rebuild action is invoked on a WiX installer
> project inside VS, but on another machine the same project does not output
> the corresponding .exe file. No error is being thrown and I verified that the
> required bootstrapper files/packages exist on the machine.
> Any idea what else I should check for?
> --
> The Windows 8 Center - In partnership with Sourceforge Your idea - your app
> - 30 days.
> Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-
> style-apps/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
The Windows 8 Center - In partnership with Sourceforge
Your idea - your app - 30 days.
Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to override wix variable value in runtime(via command line)

[Castro, Edwin G. (Hillsboro)]

You want to use a public property, for example, [APPPOOLNAME]. The WiX 
authoring looks like this:



On the command line you simply specify the value of the public property, 
APPPOOLNAME, like this:

msiexec /i "Path\to\package.msi" APPPOOLNAME=MyAppPoolName

Note, that you can use a LaunchCondition to cause an error if the property 
doesn't have a value (the condition needs to be specified in  or a 
referenced  ):

Re: [WiX-users] define element for ProgramFilesFolder not working in include file :(

[Castro, Edwin G. (Hillsboro)]

I *think* you want to use the following in the same fragment where you define 
your CustomActions:



The documentation says: Use to suppress modularization of this property 
identifier in merge modules. Using this functionality is strongly discouraged; 
it should only be necessary as a workaround of last resort in rare scenarios.

I think it is acceptable to use in this scenario since we are asking that a 
system property not be modularized.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
> Sent: Thursday, September 13, 2012 9:56 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] define element for ProgramFilesFolder not working
> in include file :(
> 
> I appreciate the help!
> 
> Steve
> 
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: September-13-12 12:52 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] define element for ProgramFilesFolder not working
> in include file :(
> 
> Oh, I see that the properties are getting modularized:
> 
> SetEALNBService.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7
> EALNBService.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7
> ProgramFilesFolder.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7
> 
> There is a way to avoid that but I'm not familiar with the technique as I 
> don't
> use merge modules myself.
> 
> Perhaps somebody with more merge module experience can point us in the
> correct direction.
> 
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> P Please consider the environment before printing this e-mail
> 
> 
> > -Original Message-
> > From: StevenOgilvie [mailto:sogil...@msn.com]
> > Sent: Thursday, September 13, 2012 9:41 AM
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] define element for ProgramFilesFolder not
> > working in include file :(
> >
> > Hey Edwin,
> > did as you said and no go...
> >
> > got this in the merge module:
> > SetEALNBService.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D751
> > EALNBService.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7
> >
> """[ProgramFilesFolder.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7]\MyCo
> >
> mpany\MyProduct\Services\EnterpriseAuditLogService\NServiceBus.Host.e
> > xe""
> > /installInfrastructure"
> >
> > code was:
> >  >
> Value=""[$(var.PlatformProgramFilesFolder)]\MyCompany\MyProduc
> > t\Services\EnterpriseAuditLogService\NServiceBus.Host.exe"
> > /installInfrastructure" Execute="immediate" />
> >
> > in include:
> >   
> >   
> >   
> >> ="[%SystemRoot]\Microsoft.NET\Framework64\v4.0.30319\" ?>
> >   
> >   
> >   
> >   
> >> ="[%SystemRoot]\Microsoft.NET\Framework\v4.0.30319\" ?>
> >   
> >   
> >
> > Logfile results:
> > PROPERTY CHANGE: Adding
> > EALNBService.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7
> > property. Its value is
> >
> '"\MyCompany\MyProduct\Services\EnterpriseAuditLogService\NServiceBu
> > s.Host.exe"
> > /installInfrastructure'.
> >
> > ** Moving that out of the merge module and placing the custom action
> > into the product.wxs it works... **
> >
> > thanks,
> > Steve
> >
> >
> >
> > --
> > View this message in context: http://windows-installer-xml-wix-
> > toolset.687559.n2.nabble.com/define-element-for-ProgramFilesFolder-not
> > - working-in-include-file-tp7580463p7580484.html
> > Sent from the wix-users mailing list archive at Nabble.com.
> >
> > --
> > 
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the latest 
> > in
> malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> 

Re: [WiX-users] define element for ProgramFilesFolder not working in include file :(

[Castro, Edwin G. (Hillsboro)]

Oh, I see that the properties are getting modularized:

SetEALNBService.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7
EALNBService.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7
ProgramFilesFolder.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7

There is a way to avoid that but I'm not familiar with the technique as I don't 
use merge modules myself.

Perhaps somebody with more merge module experience can point us in the correct 
direction.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: StevenOgilvie [mailto:sogil...@msn.com]
> Sent: Thursday, September 13, 2012 9:41 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] define element for ProgramFilesFolder not working
> in include file :(
> 
> Hey Edwin,
> did as you said and no go...
> 
> got this in the merge module:
> SetEALNBService.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7  51
> EALNBService.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7
> """[ProgramFilesFolder.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7]\MyCo
> mpany\MyProduct\Services\EnterpriseAuditLogService\NServiceBus.Host.e
> xe""
> /installInfrastructure"
> 
> code was:
>  Value=""[$(var.PlatformProgramFilesFolder)]\MyCompany\MyProduc
> t\Services\EnterpriseAuditLogService\NServiceBus.Host.exe"
> /installInfrastructure" Execute="immediate" />
> 
> in include:
>   
>   
>   
>="[%SystemRoot]\Microsoft.NET\Framework64\v4.0.30319\" ?>
>   
>   
>   
>   
>="[%SystemRoot]\Microsoft.NET\Framework\v4.0.30319\" ?>
>   
>   
> 
> Logfile results:
> PROPERTY CHANGE: Adding
> EALNBService.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7
> property. Its value is
> '"\MyCompany\MyProduct\Services\EnterpriseAuditLogService\NServiceBu
> s.Host.exe"
> /installInfrastructure'.
> 
> ** Moving that out of the merge module and placing the custom action into
> the product.wxs it works... **
> 
> thanks,
> Steve
> 
> 
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/define-element-for-ProgramFilesFolder-not-
> working-in-include-file-tp7580463p7580484.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] define element for ProgramFilesFolder not working in include file :(

[Castro, Edwin G. (Hillsboro)]

If  includes:


  
  
  
  

  
  
  
  


Then I would expect the following to work:




Notice that I have $(var.PlatformProgramFilesFolder) enclosed in []. If you 
look at the custom action in the merge module using a table editor (orca and 
instedit come to mind) then it should look like this:

For $(var.Platform) = x64:

"[ProgramFiles64Folder]\MYCOMPANY\MYPRODUCTNAME\Services\EnterpriseAuditLogService\NServiceBus.Host.exe"
 /installInfrastructure

For $(var.Platform) != x64:

"[ProgramFilesFolder]\MYCOMPANY\MYPRODUCTNAME\Services\EnterpriseAuditLogService\NServiceBus.Host.exe"
 /installInfrastructure

You might also need to choose the DllEntry (CAQuietExec or CAQuietExec64) 
depending on $(var.Platform). I ran into problems where I had to choose 
depending on the bitness of the program I was running.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
> Sent: Thursday, September 13, 2012 2:20 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] define element for ProgramFilesFolder not working
> in include file :(
> 
> Preprocessor variables are case-sensitive. Does using $(var.PLATFORM) fix it
> ?
> 
> -Original Message-
> From: StevenOgilvie [mailto:sogil...@msn.com]
> Sent: 13 September 2012 00:05
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] define element for ProgramFilesFolder not working in
> include file :(
> 
> Hi
> I have an include file:  and it
> has the following:
> 
>   
>   
>="[%SystemRoot]\Microsoft.NET\Framework64\v4.0.30319\" ?>
>   
>   
>   
>   
>="[%SystemRoot]\Microsoft.NET\Framework\v4.0.30319\" ?>
>   
>   
> 
> I use it in a merge module like this: (I include the include file) BTW I need 
> the
> " around the exe pathname or the custom action fails...
>  Value=""$(var.PlatformProgramFilesFolder)\MYCOMPANY\MYPRODU
> CTNAME\Servic
> es\EnterpriseAuditLogService\NServiceBus.Host.exe"
> /installInfrastructure" Execute="immediate" />  Id="EALNBService" Impersonate="no" BinaryKey="WixCA"
> DllEntry="CAQuietExec" Execute="deferred" Return="ignore" />
> 
> it doesn't work, the logfile has this entry:
> MSI (s) (70:EC) [18:50:54:003]: PROPERTY CHANGE: Adding
> EALNBService.CA23A0DC_B2DE_4F2C_9E74_FD373F99E9D7 property. Its
> value is
> '"ProgramFilesFolder\MYCOMPANY\MYPRODUCTNAME\Services\Enterprise
> AuditLogServi
> ce\NServiceBus.Host.exe"
> /installInfrastructure'.
> 
> and obviously it doesn't work... (if I hard code the path in the custom action
> (i.e. C:\Program Files (x86)) it works...
> 
> What am I doing wrong?
> 
> thanks,
> 
> Steve
> 
> 
> 
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/define-
> element-
> for-ProgramFilesFolder-not-working-in-include-file-tp7580463.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> -
> -
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> 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.
> 
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accel

Re: [WiX-users] FW: WiX using with MSBuild can't reference other project: error CNDL0150: Undefined preprocessor variable

[Castro, Edwin G. (Hillsboro)]

Yes, wix2010.targets creates preprocessor variables for the referenced .sqlproj 
*if and only if* the referencing .wixproj (and its containing .sln) are 
building in Visual Studio.

If the referencing .wixproj (and its containing .sln) are building on the 
command line using MSBuild, then wix2010.targets does *not* create preprocessor 
variables for the referenced .sqlproj.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Bob Arnson [mailto:b...@joyofsetup.com]
> Sent: Thursday, August 30, 2012 6:34 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] FW: WiX using with MSBuild can't reference other
> project: error CNDL0150: Undefined preprocessor variable
> 
> On 27-Aug-12 13:32, Castro, Edwin G. (Hillsboro) wrote:
> > ShowTargetPath:
> >ShowTargetPath: D:\svn\sample\sample\bin\Debug\sample.dll
> Does wix2010.targets create any preprocessor variables for the .sqlproj?
> It mostly relies on metadata that other targets have set.
> 
> --
> sig://boB
> http://joyofsetup.com/
> 
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] FW: WiX using with MSBuild can't reference other project: error CNDL0150: Undefined preprocessor variable

[Castro, Edwin G. (Hillsboro)]

I created a new solution with a SQL Server Database Project (.sqlproj). I then 
created a target.proj in the same directory where my sample.sqlproj exists:


http://schemas.microsoft.com/developer/msbuild/2003"; ToolsVersion="4.0">
  

  sample
  {bd7cc11d-9e34-4d5f-b9db-7bc91549b53b}
  True
  True
  
Binaries;Content;Satellites
  INSTALLLOCATION

  
  

  


  
  

  


  


Notice that I'm calling GetTargetPath and GetSqlTargetPath. I found looking 
through the imports in sample.sqlproj that they define both GetTargetPath and 
GetSqlTargetPath. Here is the output of using my target.proj:

PS D:\svn\sample\sample> 
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe 
D:\svn\sample\sample\target.proj /t:"ShowTargetPath;ShowSqlTargetPath"
Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.269]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

Build started 8/27/2012 10:22:34 AM.
Project "D:\svn\sample\sample\target.proj" on node 1 
(ShowTargetPath;ShowSqlTargetPath target(s)).
ShowTargetPath:
  ShowTargetPath: D:\svn\sample\sample\bin\Debug\sample.dll
ShowSqlTargetPath:
  ShowSqlTargetPath: D:\svn\sample\sample\bin\Debug\sample.dacpac
Done Building Project "D:\svn\sample\sample\target.proj" 
(ShowTargetPath;ShowSqlTargetPath target(s)).


Build succeeded.
0 Warning(s)
0 Error(s)

Time Elapsed 00:00:00.19

The sample.dacpac output is the main project output which is used to deploy a 
database. I can use a tool called sqlpackage.exe to deploy a .dacpac.

I'm not sure why sample.sqlproj responds with the path to sample.dll when 
GetTargetPath is called.

Interestingly enough, I see that building the project does in fact generate a 
sample.dll!

PS D:\svn\sample\sample> 
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe 
D:\svn\sample\sample\sample.sqlproj /t:build
Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.269]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

Build started 8/27/2012 10:28:44 AM.
Project "D:\svn\sample\sample\sample.sqlproj" on node 1 (build target(s)).
GenerateSqlTargetFrameworkMoniker:
Skipping target "GenerateSqlTargetFrameworkMoniker" because all output files 
are up-to-date with respect to the input files.
CoreCompile:
  C:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe /noconfig 
/nowarn:1701,1702 /nostdlib+ /errorreport:prompt /warn:4 /define:DEBUG;TRACE 
/reference:"C:\Program Files (x86
  )\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll" 
/debug+ /debug:full /optimize- /out:obj\Debug\sample.dll /target:library 
/warnaserror- "C:\Users\e
  gcastro\AppData\Local\Temp\1\.NETFramework,Version=v4.0.SqlClrAttributes.cs"
SqlBuild:
  Creating a model to represent the project...
  Loading project references...
  Loading project files...
  Building the project model and resolving object interdependencies...
  Validating the project model...
  Writing model to D:\svn\sample\sample\obj\Debug\Model.xml...
CopyFilesToOutputDirectory:
  Copying file from "obj\Debug\sample.dll" to "bin\Debug\sample.dll".
  sample -> D:\svn\sample\sample\bin\Debug\sample.dll
  Copying file from "obj\Debug\sample.pdb" to "bin\Debug\sample.pdb".
SqlPrepareForRun:
  sample -> D:\svn\sample\sample\bin\Debug\sample.dacpac
Done Building Project "D:\svn\sample\sample\sample.sqlproj" (build target(s)).


Build succeeded.
0 Warning(s)
0 Error(s)

Time Elapsed 00:00:05.70

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Bob Arnson [mailto:b...@joyofsetup.com]
> Sent: Sunday, August 26, 2012 7:46 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] FW: WiX using with MSBuild can't reference other
> project: error CNDL0150: Undefined preprocessor variable
> 
> On 8/24/2012 12:29 AM, Castro, Edwin G. (Hillsboro) wrote:
> > A .sqlproj is a new project type that can be created after the SQL Server
> Data Tools are installed.
> Run 'msbuild /t:GetTargetPath proj.sqlproj' to see if it supports the stock
> flow.
> 
> --
> sig://boB
> http://joyofsetup.com/
> 
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>

Re: [WiX-users] FW: WiX using with MSBuild can't reference other project: error CNDL0150: Undefined preprocessor variable

[Castro, Edwin G. (Hillsboro)]

A .sqlproj is a new project type that can be created after the SQL Server Data 
Tools are installed. The new project type replaces the .dbproj project type for 
databases. If I understood better how the properties typically flow across the 
project references, then I could help figure out why it doesn't currently work 
for .sqlproj and what might need to change to support the new project type. Any 
hints or clues would be really appreciated.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Thursday, August 23, 2012 7:45 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] FW: WiX using with MSBuild can't reference other
> project: error CNDL0150: Undefined preprocessor variable
> 
> It's probably something unique about the .sqlproj that prevents the variables
> from flowing across the project references. I've never crated a ..sqlproj. How
> do you do that?
> 
> On Wed, Aug 22, 2012 at 6:17 PM, Castro, Edwin G. (Hillsboro) <
> edwin.cas...@fiserv.com> wrote:
> 
> > I'm building the .sln in both cases. It works in Visual Studio but
> > fails in the command line.
> >
> > I tried adding the
> > false to my
> > .wixproj but the behavior didn't change. :-(
> >
> > I can build the .sqlproj just fine from the command line (either by
> > itself or as part of the .sln).
> >
> > Edwin G. Castro
> > Software Developer - Staff
> > Digital Channels
> > Fiserv
> > Office: 503-746-0643
> > Fax: 503-617-0291
> > www.fiserv.com
> > P Please consider the environment before printing this e-mail
> >
> >
> > > -Original Message-
> > > From: Rob Mensching [mailto:r...@robmensching.com]
> > > Sent: Wednesday, August 22, 2012 4:30 PM
> > > To: General discussion for Windows Installer XML toolset.
> > > Subject: Re: [WiX-users] FW: WiX using with MSBuild can't reference
> > > other
> > > project: error CNDL0150: Undefined preprocessor variable
> > >
> > > What if you add
> > >
> > >   
> > > false
> > >   
> > > To your .wixproj?  I expect you're hitting an interplay between
> > solutions and
> > > projects. That MSBuild property disables Visual Studio from creating
> > magical
> > > properties only available when you build the .sln file. If that is
> > > set
> > and the
> > > build fails then my hypothesis is correct and .sqlproj variables are
> > dependent
> > > on solutions today the way .vcproj files were in the past.
> > >
> > >
> > > On Wed, Aug 22, 2012 at 1:16 PM, Edwin G. Castro
> > > wrote:
> > >
> > > > Ruslan Albu  kurtosys.com> writes:
> > > >
> > > > >
> > > > > But it doesn't work when I build it using MSBuild task. In my
> > > > > build definition I use the following:
> > > > >
> > > > >  > > Condition="'$(CreateSetup)'=='true'"
> > > > > Properties
> > > > > ="MsiInstallVersion=$(Major).$(Minor).$(Build).$(Revision);AutoB
> > > > > uild
> > > > > =Tru
> > > > > e"/>
> > > > >
> > > > > I'm getting this error when using MSBuild:
> > > > >
> > > > > Product.wxs(361): error CNDL0150: Undefined preprocessor
> > > > > variable '$(var.InstallDataBase.TargetDir)'.
> > > > >
> > > > > I checked the build outputs from both VS and MSBuild and the
> > > > > difference is that when building in MSBuild the candle.exe
> > > > > doesn't have the properties for the library project (for
> > > > > instance -dLibraryProjectName.ProjectDir, etc.).
> > > > >
> > > >
> > > > I'm running into this same problem.
> > > >
> > > > I have a WiX project with a reference to a .sqlproj. When I build
> > > > the solution the WiX project builds as expected but when I build
> > > > it on the command line I get error CNDL0150: Undefined
> > > > preprocessor variable similar to above.
> > > >
> > > > Similarly, when I checked the output for Visual Studio and
> > > > compared it to the output from MSBuild 

Re: [WiX-users] FW: WiX using with MSBuild can't reference other project: error CNDL0150: Undefined preprocessor variable

[Castro, Edwin G. (Hillsboro)]

I'm building the .sln in both cases. It works in Visual Studio but fails in the 
command line.

I tried adding the false 
to my .wixproj but the behavior didn't change. :-(

I can build the .sqlproj just fine from the command line (either by itself or 
as part of the .sln).

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Wednesday, August 22, 2012 4:30 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] FW: WiX using with MSBuild can't reference other
> project: error CNDL0150: Undefined preprocessor variable
> 
> What if you add
> 
>   
> false
>   
> To your .wixproj?  I expect you're hitting an interplay between solutions and
> projects. That MSBuild property disables Visual Studio from creating magical
> properties only available when you build the .sln file. If that is set and the
> build fails then my hypothesis is correct and .sqlproj variables are dependent
> on solutions today the way .vcproj files were in the past.
> 
> 
> On Wed, Aug 22, 2012 at 1:16 PM, Edwin G. Castro
> wrote:
> 
> > Ruslan Albu  kurtosys.com> writes:
> >
> > >
> > > But it doesn't work when I build it using MSBuild task. In my build
> > > definition I use the following:
> > >
> > >  Condition="'$(CreateSetup)'=='true'"
> > > Properties
> > > ="MsiInstallVersion=$(Major).$(Minor).$(Build).$(Revision);AutoBuild
> > > =Tru
> > > e"/>
> > >
> > > I'm getting this error when using MSBuild:
> > >
> > > Product.wxs(361): error CNDL0150: Undefined preprocessor variable
> > > '$(var.InstallDataBase.TargetDir)'.
> > >
> > > I checked the build outputs from both VS and MSBuild and the
> > > difference is that when building in MSBuild the candle.exe doesn't
> > > have the properties for the library project (for instance
> > > -dLibraryProjectName.ProjectDir, etc.).
> > >
> >
> > I'm running into this same problem.
> >
> > I have a WiX project with a reference to a .sqlproj. When I build the
> > solution the WiX project builds as expected but when I build it on the
> > command line I get error CNDL0150: Undefined preprocessor variable
> > similar to above.
> >
> > Similarly, when I checked the output for Visual Studio and compared it
> > to the output from MSBuild I noticed that the project preprocessor
> > variables are not getting defined in MSBuild.
> >
> > I see in wix2010.targets that the
> > CreateProjectReferenceDefineConstants
> > task is
> > responsible for setting the ProjectReferenceDefineConstants property.
> > I can also see that the CreateProjectReferenceDefineConstants task
> > uses
> > @(_ResolvedProjectReferencePaths) as ProjectReferencePaths.
> >
> > My guess is that the wix2010.targets is failing to resolve my project
> > dependency on the command line but it succeeds in Visual Studio. I
> > can't figure out why the difference occurs.
> >
> > Has anybody else experienced this? If so, how did you resolve it?
> >
> > --
> > Edwin G. Castro
> >
> >
> >
> >
> > --
> > 
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the
> > latest in malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> 
> 
> 
> --
> virtually,
> 
>Rob Mensching
>http://RobMensching.com LLC
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX Suppress ICE Validation When Using MSBUILD At The Commandline

[Castro, Edwin G. (Hillsboro)]

You don't need to had the  element to your .wixproj first.

If you do not want to suppress ICE by default then don't include the 
 element. When you call MSBuild from the command line and 
specify /p:SuppressIces="..." you'll still get the behavior you want.

Be aware that if you do add a  element to your .wixproj and you 
specify a different set of values on the command line, then the only ICE to get 
suppressed will be the ones specified on the command line. In other words, the 
values are not merged together. Also, MSBuild will not let you change a 
property set on the command line.

Assume the .wixproj has 
ICE82;ICE03

If you specify /p:SuppressIces="ICE01;ICE02" on the command line, then the only 
ICE suppressed are ICE01 and ICE02. If you want all four to be suppressed, then 
you'll need to specify all of them on the command line with 
/p:SuppressIces="ICE01;ICE02;ICE03:ICE82".

Using the following in the .wixproj doesn't work because property values 
specified on the command line cannot be changed:

$(SuppressIces);ICE82;ICE03
ICE82;ICE03

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Dirk Kuypers [mailto:kuypers.d...@gmail.com]
> Sent: Friday, August 17, 2012 4:01 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] WiX Suppress ICE Validation When Using MSBUILD
> At The Commandline
> 
> Hi,
> 
> I guess you need an initial property (it will not be there untill you add it
> manually once) like the one below in your wixproj file:
> ICE82;ICE03 
> After that you can override properties from the command line of MSBuild
> like this:
> msbuild /p:SuppressIces="ICE01;ICE02" /p:Configuration=Release
> /p:Platform=x86 /t:rebuild your.wixproj
> 
> HTH
> Dirk
> 
> 2012/8/16 Shaun Hayward :
> > Thanks, Palbinder
> >
> > That lead me to the problem. All of the settings for my wixproj were under
> the Release configuration but MSBUILD was using the Debug configuration
> because I hadn't told it to build Release. I'm good to go.
> >
> > Though since I did figure out how to specify preprocessor variables in the
> MSBUILD commandline, it would be nice to know how to specify ICE
> suppression through the MSBUILD commandline.
> >
> > Thanks again
> > - Shaun
> >
> >
> >
> >
> >
> > Shaun Hayward | Senior Software Developer | Omnivex | 905.761.6640 ext
> > 429 | www.omnivex.com
> >
> > -Original Message-
> > From: Pally Sandher [mailto:pally.sand...@iesve.com]
> > Sent: Thursday, August 16, 2012 6:44 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] WiX Suppress ICE Validation When Using
> > MSBUILD At The Commandline - Email found in subject
> >
> > Try using the "Suppress specific warnings" field in the individual wixproj
> files where appropriate.
> >
> > Palbinder Sandher
> > Software Platform Engineer
> > T: +44 (0) 141 945 8500
> > F: +44 (0) 141 945 8501
> > http://www.iesve.com
> >
> > **Design, Simulate + Innovate with the **
> > Integrated Environmental Solutions Limited. Registered in Scotland No.
> > SC151456 Registered Office - Helix Building, West Of Scotland Science
> > Park, Glasgow G20 0SP Email Disclaimer
> >
> >
> > -Original Message-
> > From: Shaun Hayward [mailto:shayw...@omnivex.com]
> > Sent: 15 August 2012 17:58
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: [WiX-users] WiX Suppress ICE Validation When Using MSBUILD At
> > The Commandline
> >
> > Hi everyone
> >
> > I've got a Visual Studio solution that contains two WiX Projects. In Visual
> Studio, I set the project properties to ignore the nearly-400 ICE30 output by
> light. The WiX code was written by another programmer and I don't currently
> have the time or the mandate to rewrite it so that it doesn't have any ICE
> errors.
> >
> > We were previously building it with Candle and Light, thus allowing us to do
> a -sice for ICE30. Right now, I'm trying to get it to work with MSBUILD at the
> commandline since we are changing our build process. I've managed to find
> all of the other commandline parameters I need through Google (such as
> setting the preprocessor variables) but I can't figure out how to set the
> parameter to suppress a specific ICE validation.
> >
> > Here are the two commandlines I've tried:
> >
> > MSBUILD "C:\Code\Moxie\Dev\6.10\Build Workflow\Installation\Moxie
> WiX\Moxie WiX.sln"
> /p:DefineConstants="BINARIESFOLDER=C:\Code\Moxie\Dev\6.10\Build
> Workflow\Binaries;LIBRARYFOLDER=C:\Code\Moxie\Dev\6.10\Build
> Workflow\Library;MANUALSFOLDER=C:\Code\Moxie\Dev\6.10\Build
> Workflow\Manuals;RESOURCESFOLDER=C:\Code\Moxie\Dev\6.10\Build
> Workflow\Installation\Installation
> Resources;MODULEZIPSFOLDER=C:\Code\Moxie\Dev\6.10\Build
> Workflow\Module
> Zips;PRODUCTVERSION=6.255.1.1;";OutputDir="C:\Code\Moxie\Dev\6.10\B
> ui

Re: [WiX-users] Relative Path cause Light unable to find sourcefiles.

[Castro, Edwin G. (Hillsboro)]

The first thing that comes to mind when relative paths are not found is that 
the expectation of the current working directory is incorrect. I believe that 
the WiX MSBuild tasks used by .wixproj use the location where the .wixproj 
exists as the working directory requiring that any relative paths begin in that 
directory. If you are calling light.exe yourself then you'll need to decide 
whether the working directory is what you expect.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: shengyixing [mailto:shengyix...@hotmail.com]
> Sent: Thursday, August 16, 2012 7:01 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Relative Path cause Light unable to find sourcefiles.
> 
> Even including all the full path of this file, there is only 180 characters.
> 
> Actually, I don't think it's a file length issue, because *absolute path works
> fine*. The issue *only happens on relative path*.
> 
> 
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/Relative-Path-cause-Light-unable-to-find-
> source-files-tp7579897p7579915.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX joins the Outercurve Foundation

[Castro, Edwin G. (Hillsboro)]

I would think that the content you are installing doesn't apply as it doesn't 
"use" WiX code.

But if you use the WiX UI .wxs code as a template and modify it for your own 
needs, then you would need to make your modified .wxs source available in some 
way. If you wrote a C++ custom action and linked the WiX C++ helper functions 
then your custom action "contains" WiX code and would need to make the source 
code to your C++ custom action available.

In both scenarios it is difficult what some of these words mean. For example, I 
have never felt that using a library regardless of whether it is dynamically or 
statically linked should be reason enough to require making the using code 
available but some interpretations would require it. What about generated code 
that was later modified? I don't feel such generated and modified code source 
needs to be make available but I'm sure some interpretations might also require 
it.

I think it is important to ask these questions if only to determine the 
intentions of the licensors and encourage that the license be more explicit 
about its intentions. These things should not be determined in court after the 
fact.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Peter Hull [mailto:peterhul...@hotmail.com]
> Sent: Wednesday, August 15, 2012 5:46 AM
> To: WiX Users
> Subject: Re: [WiX-users] WiX joins the Outercurve Foundation
> 
> 
> > Date: Wed, 15 Aug 2012 13:08:06 +0100
> > From: br...@cran.org.uk
> 
> > This sounds to me rather similar to requirement iv. under the previous CPL:
> >
> > iv. states that source code for the Program is available from such
> > Contributor, and informs licensees how to obtain it in a reasonable
> > manner on or through a medium customarily used for software exchange.
> 
> Maybe. In that case, (as I see it) 'the Program' means WiX so it seems
> reasonable to make available WiX's source. In the MS-RL, 'that file' implies
> the whole bundle i.e the bootstrapper's exe, any WiX extensions AND my
> program that I want to install. This seems rather onerous, am I reading it
> wrong?
> 
> Pete
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Status of WiX v3.6 Release

[Castro, Edwin G. (Hillsboro)]

WiX v3.6 RC0 was announced on 4/3/2012 and WiX v3.6 RC was announced on 
5/28/2012.

Does anybody have any guess as to how close we might be to WiX v3.6 RTM?

Hmm... let me ask a different question. We are not using burn yet and I 
understand most of the work right now revolves around burn. Would upgrading now 
to WiX v3.6 (RC or some newer weekly build) be considered stable enough for 
non-burn functionality?

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
P Please consider the environment before printing this e-mail


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] vs 2010 integration

[Castro, Edwin G. (Hillsboro)]

The Product.wxs is not modified by the automatic harvest functionality. A new 
temporary file in the intermediate directory (obj) is generated and included in 
the list of files to compile. This is why the harvested files show up in the 
MSI package as expected. Look in the obj directory for generated files and 
you'll find one with the harvested files.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Garry, Joseph [mailto:jga...@enghouse.com]
> Sent: Tuesday, July 10, 2012 1:00 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] vs 2010 integration
> 
> I'm new to WiX and trying to determine if this tool will work for our 
> purposes.
> We're using VS 2010.
> In working through the instructions for Creating a Simple Setup under
> Working in Visual Studio, it appears that when I build the setup after adding
> the reference nothing is added to the Product.wxs file(Harvest is set to
> True). If I manually edit the file, the intellisense doesn't seem to be 
> working.
> However when I build the generated setup does seem to work correctly.
> Just wondering what I'm doing wrong, if anything, that the integration
> doesn't seem to be working quite right?
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Creating an installer through the command line

[Castro, Edwin G. (Hillsboro)]

The WiX setup installs that stuff under C:\Program Files\MSBuild.

For example, I found the following in one of my .wixproj:

$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets
$(MSBuildExtensionsPath)\Microsoft\WiX\v3.x\Wix.targets

The MSBuild documentation at 
http://msdn.microsoft.com/en-us/library/ms164309.aspx tells me that the 
MSBuildExtensionsPath32 and MSBuildExtensionsPath properties resolve to 
C:\Program Files\MSBuild or C:\Program Files (x86)\MSBuild depending on whether 
I'm running 32-bit or 64-bit MSBuild.exe.

So you should expect to find the files at C:\Program 
Files\MSBuild\Microsoft\WiX\v3.x\Wix.targets or C:\Program Files 
(x86)\MSBuild\Microsoft\WiX\v3.x\Wix.targets in a normal WiX installation.

I can't speak to what SharpDevelop does.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Dan Muller [mailto:dmuller...@comcast.net]
> Sent: Wednesday, June 27, 2012 12:44 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Creating an installer through the command line
> 
> Before reading this post i did do a search for msbuild and found it in my .NET
> folders, and i have a copy of wix.target and wixtasks.dll, however they are
> not actually from the wix installation but my sharpdevelop install. So my
> question is, is there a wix.target and wixtasks.dll that is distributed with 
> the
> rest of the wix binaries?
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/Creating-an-installer-through-the-command-
> line-tp7579149p7579159.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Creating an installer through the command line

[Castro, Edwin G. (Hillsboro)]

If you have WiX installed on the computer, then you have everything you  need, 
even if Visual Studio is not installed. Give it a try. Let us know if you run 
into any problems. Try to provide as much information as possible about your 
configuration.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Dan Muller [mailto:dmuller...@comcast.net]
> Sent: Wednesday, June 27, 2012 10:15 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Creating an installer through the command line
> 
> I don't know what I was doing but I had tried msbuild but must have supplied
> the wrong argument. My problem now is that there is no w.target in my
> C:\Program Files\Windows Installer XML v3.6\bin directory. It exists in my
> sharp develop directory and I am sure I can find it in the visual studios
> directory, but how would you be able to run msbuild on a computer without
> sharpdevelop or visual studios
> 
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/Creating-an-installer-through-the-command-
> line-tp7579149p7579152.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Sets of files installed at different times.

[Castro, Edwin G. (Hillsboro)]

I've seen many installers by others where their bootstrapper installs 
"installation tools" before the real installer begins to execute so I think 
this kind of approach certainly has a lot of precedence already.

I have not personally used burn so I'm not much help myself. If I was going to 
start I would look here, 
http://wix.sourceforge.net/manual-wix3/authoring_bundle_intro.htm, first. The 
consensus on the mailing list is that the documentation for burn is still 
lacking quite a bit so you might need to ask others here for help as you 
explore using burn.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail



> -Original Message-
> From: Dan Muller [mailto:dmuller...@comcast.net]
> Sent: Friday, June 15, 2012 1:08 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Sets of files installed at different times.
> 
> Thank you for your in depth response. Since reading your post we have
> looked in to burn, and have a few questions that we hope someone could
> answer.
> 
> An idea that is being thrown around is that of a first MSI that would lay down
> the necessary files in the form of perl scripts, and a second that would 
> install
> the actual program.
> 
> It doesn't seem that burn.exe is currently in my Program Files folder, so
> where would I be able to get it, and where could I find any sort of docs on 
> it?
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/Sets-of-files-installed-at-different-times-
> tp7578867p7578879.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Sets of files installed at different times.

[Castro, Edwin G. (Hillsboro)]

Windows Installer uses a declarative language (implemented in an embedded 
database) to describe the end state of the system. This means that all files in 
selected components are installed at the same conceptual time in no specific 
order. Components can have Conditions that decide whether the component will be 
selected (assuming its parent Feature has already been selected). Perhaps one 
way to do this would be to construct Component Conditions such that they use 
the value of a Property (or Properties as the case might be) whose value is set 
by an immediate CustomAction you execute before the InstallFiles action. Since 
the Windows Installer does not actually install files until the install script 
is executed (at "deferred" time) you cannot use a Component/File to copy your 
dependencies.

Ideally, the immediate CustomAction is implemented in C/C++ with no external 
dependencies (statically linked, for example). WiX provides a very easy way to 
author custom actions in .NET by using the DTF but this will introduce a 
dependency to the .NET runtime of your choice. If you cannot guarantee that the 
appropriate .NET runtime will be installed before your package is installed, 
then you'll need to use a bootstrapper (like Burn) to make sure the .NET 
runtime gets installed before your package is installed. If you decide to use 
scripts to implement your immediate CustomAction (not recommended as they are 
often very fragile and difficult to debug, also anti-virus and anti-malware 
software tend to hate them), then the Windows Installer support JScript and 
VBScript out-of-the-box. You have various options here including adding your 
JScript or VBScript to the Binary table or including the text of the script 
"inline".

For any other kind of script, you'll need to be responsible for making sure the 
script runtime is available (provide it yourself, detect it exists, or provide 
it yourself) and you'll be responsible for providing your own scripts as well. 
If you need to provide the engine and scripts, then you would need to write a 
custom action (using one of the methods in the previous paragraph) to extract 
your script engine and/or scripts from some location (probably the Binary 
table), execute your scripts, and finally clean up after yourself. There are 
two major things to consider here:

1.) You are already writing a custom action in C/C++ or .NET (JScript and 
VBScript do not seem to provide enough features to extract files but I could be 
wrong) so perhaps you should just implement your real custom action in C/C++ or 
.NET.
2.) You lose the ability to interact with the Windows Installer engine (for 
example, you cannot set properties to communicate with other custom actions or 
to affect Conditions on Components) so using these kinds of scripts are only 
really useful to actually make changes to the system (they need to run 
deferred) that are harder to make using another technique.

Perhaps someday WiX can provide a built-in mechanism to extract arbitrary files 
from the Binary table but I suspect that type of functionality is extremely low 
on the WiX developers' priority list (if it is there at all).

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Dan Muller [mailto:dmuller...@comcast.net]
> Sent: Friday, June 15, 2012 9:23 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Sets of files installed at different times.
> 
> Our installer needs to run a set of scripts on install and uninstall, is 
> there a
> way to write a specific set of files to the disk, then call them using some
> custom actions we made and depending on whether some of them
> produced proper files outputs, wix would then install the rest of the files to
> the specified INSTALLDIR.
> 
> What would be the best way to do this? Would we be able to add them as
> components and have a custom action to install them? Is there another way
> built into wix, or is there something missing?
> 
> Thanks in advance,
> Dan
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/Sets-of-files-installed-at-different-times-
> tp7578867.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--

Re: [WiX-users] Perl Script on initialization

[Castro, Edwin G. (Hillsboro)]

The Id of the property with the command line needs to match the Id of the 
custom action you are executing. Also, I don't think CAQuietExec how to execute 
non-executable files. In my experience you need to provide the executable to 
execute first _in quotes_ before any arguments you want to pass to the 
executable.

In the case of opening a file in notepad you would want to use something like 
this:







The above is just an example, you'll need to change SetProperty/@Value to what 
you need. I think Directory Ids and File Ids are not available until later in 
the sequence but I forget the specific action that needs to complete before 
they resolve correctly.

You'll want to look at the documentation for  to learn more about 
it. It schedules a custom action to set the QtExecExample property that will 
contain the command line to execute.

I think you'll need to use AppSearch to find the perl executable and then use 
 to set the command line using the perl executable to execute 
your script.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Dmuller720 [mailto:dmuller...@comcast.net]
> Sent: Friday, June 08, 2012 7:35 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Perl Script on initialization
> 
> yes, perl is in my path, but I do not think that it is a problem with perl, I 
> think
> that it is something that I am not doing right in Wix.
> 
> So me and my team have sort of refocused and we are at the moment, just
> trying to make wix open notepad.exe after AppSearch.
> 
> ...
> 
>  DllEntry="CAQuietExec" Execute="immediate" Return="check"/>
> 
> 
> 
>  
> 
> 
> ...
> 
> Are we on the right track?
> 
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/Perl-Script-on-initialization-
> tp7578584p7578740.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] In .wixproj, default Build Configuration ignored or not settable?

[Castro, Edwin G. (Hillsboro)]

If you are building the .wixproj directly then the defaults specified in the 
.wixproj should be true but the environment might have a say.

If you are building the .sln that contains the .wixproj then MSBuild will 
choose a Configuration|Platform dependent on the .sln. You'll want to 
investigate the solution Configuration|Platform to make sure the correct 
project Configuration|Platform is selected. Again the environment might have a 
say in choosing the Configuration|Platform at the solution level when it is not 
specified.

We've ran into scenarios where the default Configuration|Platform chosen varied 
depending on whether you are calling MSBuild without using the vsvars32.bat to 
configure the environment or whether you are running in an environment 
configured by vsvars32.bat or one of the other batch scripts delivered by 
Visual Studio. For example, the "Visual Studio Command Prompt (2010)" chooses 
different defaults for Configuration|Platform than "Visual Studio x64 Win64 
Command Prompt (2010)".

If you are running this from a script then my suggestion is that you always 
specify the Configuration|Platform in your script and specify the defaults you 
want in your script.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Monday, May 21, 2012 10:13 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] In .wixproj, default Build Configuration ignored or 
> not
> settable?
> 
> A verbose MSBuild log file should show you how the property values are
> changing. If not, I've found sprinkling Message tasks in the MSBuild files is
> often the fastest way to see why values are not what I want them to be.
> 
> Just had to do that today to fix the bundle signing bug. 
> 
> On Fri, May 18, 2012 at 10:45 AM, john.burak 
> wrote:
> 
> > It's my understanding that with MSBuild, the configuration and
> > platform used when none are specified is defined near the top of the
> > project file in the elements with "blank" conditions, like this:
> >
> >   > DefaultTargets="Build"
> > xmlns="http://schemas.microsoft.com/developer/msbuild/2003";>
> >  
> > *Debug
> >x86
> > *
> >
> > This doesn't seem to be happening for a wixproj I have.  I've added
> > two new build configurations, and it keeps building one of those by
> > default, called "Debug SU".  I want it to build "Debug" by default.
> > I'm calling MSBuild from a script.
> >
> > Does anyone know how to have a specific configuration used by default
> > when one isn't specified to MSBuild?  I could add logic to check for
> > this one solution and pass in a specific configuration, but that's a
> > bit ugly if there is supposed to be a settable default.
> >
> > Thanks,
> >
> > - John
> >
> > --
> > View this message in context:
> > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/In-wixpr
> > oj-default-Build-Configuration-ignored-or-not-settable-tp7565859.html
> > Sent from the wix-users mailing list archive at Nabble.com.
> >
> >
> > --
> > 
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the
> > latest in malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> 
> 
> 
> --
> virtually, Rob Mensching - http://RobMensching.com LLC
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w

Re: [WiX-users] Does wix support calling bcdedit?

[Castro, Edwin G. (Hillsboro)]

The log you sent did not show this command line (with the quotes) as the 
command that executed. If you did in fact change your MSI to remote the extra 
quotes and you can see in the log that they are no longer there and it still 
didn't work then you have an interesting issue to resolve. In that case, my 
next guess might be to check whether perhaps the MSI package is getting marked 
as 32-bit and getting installed on a 64-bit system and bcdedit.exe doesn't 
actually exist in the 32-bit location for [SystemFolder] (just a guess, I have 
no real idea). Or perhaps the target system simply doesn't have the file?

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: victorwhiskey [mailto:victorhwhis...@yahoo.com]
> Sent: Monday, May 14, 2012 7:40 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Does wix support calling bcdedit?
> 
> I forgot to put down that
> 
> 
> "C:\Windows\system32\\bcdedit.exe" /set testsigning on - worked on a
> command line that was "run as administrator"
> 
> but not in the quiet custom action during the install.
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/Does-wix-support-calling-bcdedit-
> tp7551749p7556546.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Does wix support calling bcdedit?

[Castro, Edwin G. (Hillsboro)]

References on the web suggest that you have too many quotes (and you didn't run 
the command as I copied it).

Did you run the following:

"C:\Windows\system32\\bcdedit.exe" /set testsigning on

Instead of what I asked you to execute:

"C:\Windows\system32\\bcdedit.exe" /set "testsigning on"

All the examples I see online suggest that the one without quotes should work. 
I haven't tried either because this seems like a bad idea but I have a feeling 
you ran the command without quotes.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Vincent Wong [mailto:victorhwhis...@yahoo.com]
> Sent: Friday, May 11, 2012 4:40 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Does wix support calling bcdedit?
> 
> Thanks Phil and Edwin,
> 
> I tried out my command and I know it works, but it works when I right click on
> command prompt and select "run as administrator".  I thought with
> perMachine mode, install privileges="elevated" and deferred custom action
> would cover, but I'm still getting the same error.
> 
> 
> 
> --- On Fri, 5/11/12, Wilson, Phil  wrote:
> 
> From: Wilson, Phil 
> Subject: Re: [WiX-users] Does wix support calling bcdedit?
> To: "General discussion for Windows Installer XML toolset."  us...@lists.sourceforge.net>
> Date: Friday, May 11, 2012, 9:44 PM
> 
> ...which is why I suggested deleting that extra "\" as something to try.
> 
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: Friday, May 11, 2012 2:37 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Does wix support calling bcdedit?
> 
> HRESULT 0x80070002 means ERROR_FILE_NOT_FOUND
> 
> See http://msdn.microsoft.com/en-us/library/windows/desktop/dd319335.aspx
> 
> 
> Open up a cmd prompt and execute the following command (don't change the
> quotes or anything else):
> 
> "C:\Windows\system32\\bcdedit.exe" /set "testsigning on"
> 
> Verify whether the command above (exactly) succeeds or fails. The command
> above is the exact command that your custom action is attempting to execute.
> If it works, then you'll need to continue investigating. If it doesn't then 
> there's
> something wrong in the way you set the SetInstallCmd property.
> 
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> P Please consider the environment before printing this e-mail
> 
> 
> > -Original Message-
> > From: Vincent Wong [mailto:victorhwhis...@yahoo.com]
> > Sent: Friday, May 11, 2012 1:23 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Does wix support calling bcdedit?
> >
> > Sorry,
> >
> > Here's the CA codes and I'm running elevated as perMachine install
> >
> >  >   Property="SetInstallCmd"
> >   Value='"[System64Folder]\bcdedit.exe" /set
> > "testsigning on"' />
> >      >   BinaryKey="WixCA"
> >   DllEntry="CAQuietExec"
> >   Return="ignore"
> >   Execute="deferred"
> >   Impersonate="no"/>
> >
> > --- On Fri, 5/11/12, victorwhiskey  wrote:
> >
> > From: victorwhiskey 
> > Subject: [WiX-users] Does wix support calling bcdedit?
> > To: wix-users@lists.sourceforge.net
> > Date: Friday, May 11, 2012, 8:07 PM
> >
> > Hi,
> >
> > I'm trying to call bcdedit from a deferred custom action to set the
> > machine in test mode.  I'm trying to install unsigned drivers at the
> > moment so I want to put the machine in test mode with the command
> "bcdedit /set testsigning on".
> >
> > I'm calling CAQuietExec byt I'm getting Error 0x80070002
> >
> > These are snips of my log:
> >
> > MSI (s) (B8:74) [11:25:49:046]: Note: 1: 2205 2:  3: PatchPackage
> > Action ended
> > 11:25:49: InstallFiles. Return value 1.
> > MSI (s) (B8:74) [11:25:49:046]: Doing action: SetInstallCmd_Cmd Action
> > start
> > 11:25:49: SetInstallCmd_Cmd.
> > MSI (s) (B8:74) [11:25:49:046]: PROPERTY CHANGE: Adding SetInstallCmd
> > property. Its value is &

Re: [WiX-users] Does wix support calling bcdedit?

[Castro, Edwin G. (Hillsboro)]

HRESULT 0x80070002 means ERROR_FILE_NOT_FOUND

See http://msdn.microsoft.com/en-us/library/windows/desktop/dd319335.aspx

Open up a cmd prompt and execute the following command (don't change the quotes 
or anything else):

"C:\Windows\system32\\bcdedit.exe" /set "testsigning on"

Verify whether the command above (exactly) succeeds or fails. The command above 
is the exact command that your custom action is attempting to execute. If it 
works, then you'll need to continue investigating. If it doesn't then there's 
something wrong in the way you set the SetInstallCmd property.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Vincent Wong [mailto:victorhwhis...@yahoo.com]
> Sent: Friday, May 11, 2012 1:23 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Does wix support calling bcdedit?
> 
> Sorry,
> 
> Here's the CA codes and I'm running elevated as perMachine install
> 
>    Property="SetInstallCmd"
>   Value='"[System64Folder]\bcdedit.exe" /set "testsigning 
> on"' />
>        BinaryKey="WixCA"
>   DllEntry="CAQuietExec"
>   Return="ignore"
>   Execute="deferred"
>   Impersonate="no"/>
> 
> --- On Fri, 5/11/12, victorwhiskey  wrote:
> 
> From: victorwhiskey 
> Subject: [WiX-users] Does wix support calling bcdedit?
> To: wix-users@lists.sourceforge.net
> Date: Friday, May 11, 2012, 8:07 PM
> 
> Hi,
> 
> I'm trying to call bcdedit from a deferred custom action to set the machine in
> test mode.  I'm trying to install unsigned drivers at the moment so I want to 
> put
> the machine in test mode with the command "bcdedit /set testsigning on".
> 
> I'm calling CAQuietExec byt I'm getting Error 0x80070002
> 
> These are snips of my log:
> 
> MSI (s) (B8:74) [11:25:49:046]: Note: 1: 2205 2:  3: PatchPackage Action ended
> 11:25:49: InstallFiles. Return value 1.
> MSI (s) (B8:74) [11:25:49:046]: Doing action: SetInstallCmd_Cmd Action start
> 11:25:49: SetInstallCmd_Cmd.
> MSI (s) (B8:74) [11:25:49:046]: PROPERTY CHANGE: Adding SetInstallCmd
> property. Its value is '"C:\Windows\system32\\bcdedit.exe" /set "testsigning
> on"'.
> Action ended 11:25:49: SetInstallCmd_Cmd. Return value 1.
> MSI (s) (B8:74) [11:25:49:046]: Doing action: SetInstallCmd Action start
> 11:25:49: SetInstallCmd.
> Action ended 11:25:49: SetInstallCmd. Return value 1.
> MSI (s) (B8:74) [11:25:49:062]: Doing action: InstallAHCI64
> 
> ...
> 
> MSI (s) (B8:74) [11:25:49:140]: Executing op:
> ActionStart(Name=SetInstallCmd,,)
> MSI (s) (B8:74) [11:25:49:140]: Executing op:
> CustomActionSchedule(Action=SetInstallCmd,ActionType=3137,Source=BinaryD
> ata,Target=CAQuietExec,CustomActionData="C:\Windows\system32\\bcdedit.e
> xe"
> /set "testsigning on")
> MSI (s) (B8:74) [11:25:49:140]: Creating MSIHANDLE (4) of type 790536 for
> thread 1908 MSI (s) (B8:D8) [11:25:49:140]: Invoking remote custom action.
> DLL:
> C:\Windows\Installer\MSIC31B.tmp, Entrypoint: CAQuietExec MSI (s) (B8:C4)
> [11:25:49:140]: Generating random cookie.
> MSI (s) (B8:C4) [11:25:49:140]: Created Custom Action Server with PID 1884
> (0x75C).
> MSI (s) (B8:48) [11:25:49:498]: Running as a service.
> MSI (s) (B8:48) [11:25:49:498]: Hello, I'm your 32bit Elevated custom action
> server.
> MSI (s) (B8!44) [11:25:49:514]: Creating MSIHANDLE (5) of type 790531 for
> thread 2628
> CAQuietExec:  Error 0x80070002: Command failed to execute.
> MSI (s) (B8!44) [11:25:49:514]: Closing MSIHANDLE (5) of type 790531 for
> thread 2628 MSI (s) (B8!44) [11:25:49:514]: Creating MSIHANDLE (6) of type
> 790531 for thread 2628
> CAQuietExec:  Error 0x80070002: CAQuietExec Failed MSI (s) (B8!44)
> [11:25:49:514]: Closing MSIHANDLE (6) of type 790531 for thread 2628
> CustomAction SetInstallCmd returned actual error code 1603 but will be
> translated to success due to continue marking MSI (s) (B8:D8) [11:25:49:514]:
> Closing MSIHANDLE (4) of type 790536 for thread 1908 MSI (s) (B8:74)
> [11:25:49:514]: Executing op:
> ActionStart(Name=InstallAHCI64,Description="Installing ",) MSI (s) (B8:74)
> [11:25:49:514]: Executing op:
> CustomActionSchedule(Action=InstallAHCI64,ActionType=3138,Source=BinaryD
> ata,Target=/F
> /PATH "C:\Program Files\\\",)
> CustomAction InstallAHCI64 returned actual error code 1073741825 but will be
> translated to success due to continue marking
> 
> 
> Any ideas?
> 
> Thank you
> 
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/Does-wix-support-calling-bcdedit-
> tp7551749.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover al

Re: [WiX-users] using wix with powershell

[Castro, Edwin G. (Hillsboro)]

PowerShell gives you lots of options to log the output. For example you could 
collect the output in a variable and then do something about it like write it 
in a file or to the event log or whatever. You could also pipe the output to 
Tee-Object which will automatically write the output to a file and then send 
the output along the pipeline so that you could do something else with it, like 
showing it on the console.

But, in the case of MSBuild, I find all of the PowerShell options unnecessary 
as MSBuild has the ability to write to a log file (as well as the console) 
already built-in. The /fl and /flp arguments control how file logging works. My 
example lets MSBuild use the default log file name (MSBuild.log in the current 
working directory) but you could even configure the log file to generate by 
setting the LogFile property with /flp. The /fl and /flp arguments are actually 
very powerful as you can define up to 10 different log files to produce with 
different content in each (while still getting regular output on the console). 
See MSBuild /? for details on MSBuild's logging features as well as other 
possible command line arguments.

PowerShell automatically puts the exit code in the $LASTEXITCODE variable. This 
is similar to how %ERRORLEVEL% contains the exit code in batch scripts. I would 
use $LASTEXITCODE rather than Start-Process. In my opinion, Start-Process, 
simply adds a layer of indirection that is unnecessary.

In fact, I tried to say in my previous email that using a function or script to 
wrap MSBuild might already be a layer of indirection that is unnecessary 
depending on what your goal is. I find that a wrapper script is useful for 
command line usage where I want a specific type of invocation to occur every 
time. The script allows me to encapsulate MSBuild usage for developers that are 
less familiar with its capabilities. If I simply needed to call MSBuild as part 
of an existing build script that does other stuff as well as calling MSBuild, 
then I might just call MSBuild directly. I think KISS applies here quite a bit.

For example, if I have a Solution.sln in the same directory as the automation 
script that I need to call without a lot of fluff and I know I need to call it 
with a single Configuration|Platform combo and I don't need anything special 
else special (because perhaps the CI server that calls my automation script 
already automatically captures my output) then I would simply use it like this:

$ProjectPath = Join-Path -Path (Split-Path -Path $MyInvocation.MyCommand.Path) 
-ChildPath Solution.sln

& $MSBuildCmd $ProjectPath /p:Configuration=Release /p:Platform=x86 /t:Rebuild

If you can guarantee that MSBuild.exe will be in your PATH, then you can write 
it more simply like this:

msbuild $ProjectPath /p:Configuration=Release /p:Platform=x86 /t:Rebuild

I didn't enclose $ProjectPath in double quotes even though it might have spaces 
in it. PowerShell will automatically wrap it in double quotes when it passes 
the argument to MSBuild if necessary. This is another example of how people 
unnecessarily complicate their PowerShell scripts.

In any case, questions about command invocation in PowerShell probably should 
be posted at
http://www.powershellcommunity.com/Forums.aspx
There are a lot of active members and they are very friendly.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: john.burak [mailto:john.bu...@telvent.com]
> Sent: Friday, May 11, 2012 9:09 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] using wix with powershell
> 
> As Edwin could have more tactfully pointed out, his script does have some
> advantages over mine.  Thanks, Edwin.  Mine is intended to get you in the 
> right
> direction, while his is more production ready except for one point: I still
> suggesting using Start-Process to launch msbuild so that you can get the 
> return
> code to see if it failed (and conveniently log the output).
> 
> Things I would use from his script:
> 
> - His msbuild args are in an array, which is nicer than the literal string in 
> mine.
> - He reads a registry key to find msbuild which is less appropriate for a 
> quick
> "how to" email, but better for production code.
> - Parameter validation, if you want to be pedantic about it.
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/using-wix-with-powershell-
> tp7537541p7550930.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest

Re: [WiX-users] using wix with powershell

[Castro, Edwin G. (Hillsboro)]

Here is what I consider a better powershell script to execute msbuild. What I 
really like about this script is that it finds msbuild on its own and sets a 
number of default values that can be overridden at call-time. This script is 
really good for command line usage. If I just needed to automate the call of 
msbuild with hard coded values in another powershell script then I wouldn't use 
this script. In this case I would just call msbuild directly with the hard 
coded values.

#-
# build.ps1
[CmdletBinding(PositionalBinding = $false)]
param (
[ValidateSet('Build', 'Clean', 'Rebuild')]
[string]
$Target = 'Build',

[ValidateSet('Release', 'Debug')]
[string]
$Configuration = 'Release',

[ValidateSet('Mixed Platforms', 'Any CPU', 'x64', 'x86')]
[string] $Platform = 'Mixed Platforms',

[Parameter(ValueFromRemainingArguments = $true)]
[Alias('Args')]
[string[]] $ArgumentList
)

$MSBuildCmd = $(
Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0 |
Select-Object -ExpandProperty MSBuildToolsPath |
Join-Path -ChildPath MSBuild.exe
)

$MSBuildArgs = @(
, '/fl'
, '/flp:PerformanceSummary;Verbosity=normal'
, '/v:normal'
, '/tv:4.0'
, "/p:Configuration=${Configuration}"
, "/p:Platform=${Platform}"
, "/t:${Target}"
)

& $MSBuildCmd $MSBuildArgs $ArgumentList


Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: john.burak [mailto:john.bu...@telvent.com]
> Sent: Thursday, May 10, 2012 2:36 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] using wix with powershell
> 
> I've done it and it works fine.  One tricky thing was working with 
> PowerShell's
> parsing modes to get the arguments passed-in correctly (notice the back-tick-
> escaped double quotes in the $msBuildArgs parameter,  below).
> If you manually use Candle/Light you have to worry about compiling fragments
> ahead of time and passing them into Light (ugh).  It's much easier to set up a
> Visual Studio project and call msbuild on it. :)
> 
> Here is a stripped down version of the script I call to compile .sln files.
> I haven't tested this exact code, but it should get you in the right 
> direction.  I'd
> call it with a command somewhat like /c:\path\MyInstaller.sln |
> c:\buildTools\compileWixSolution.ps1/ , assuming you save it to
> "compileWixSolution.ps1" and the defaults for the last two parameters are
> correct.  You can also pipe in multiple solutions, which I do.  It will 
> create a nice
> log file if msbuild had errors compiling the project.
> 
> param
> (
> [parameter(
> Mandatory=$true,
> ValueFromPipeline=$true)]
> [System.IO.FileInfo]
> # The solution to compile
> $file,
> 
> [System.IO.FileInfo]
> # The handle to the MSBuild executable.
> $msBuild =
> "C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\msbuild.exe",
> 
> [String]
> $msbuildArgs = "`"$file`" /target:rebuild
> `"/property:Configuration=Debug;Platform=x86`" /v:minimal /maxcpucount:2"
> )
> Process
> {
> $log = ("" + $file.FullName + "_msbuild.log")
> if(Test-Path $log){ Remove-Item $log } # Remove old, previous log file.
> 
> # Run msbuild
> $process = Start-Process $msBuild -ArgumentList $msbuildArgs -Wait -
> PassThru -NoNewWindow -RedirectStandardOutput $log
> if($process.ExitCode)
>   { Write-Error "Error from $msBuild.  See $log" } }
> 
> 
> Edwin G. Castro wrote
> >
> > Are you trying to build a wix project? The easiest way to do this is
> > to simply call
> >
> > msbuild solution.sln
> >
> > Or perhaps
> >
> > msbuild project.wixproj
> >
> > Passing the usual command line arguments to msbuild.
> >
> > If you are truly looking to call candle.exe, light.exe, etc. then just
> > call them with the appropriate arguments.
> >
> > What exactly is your goal?
> >
> >> -Original Message-
> >> From: Sean Farrow [mailto:sean.farrow@.co]
> >> Sent: Monday, May 07, 2012 7:29 PM
> >> To: wix-users@.sourceforge
> >> Subject: [WiX-users] using wix with powershell
> >>
> >> Hi All:
> >> Has anybody got any experience of automating wix from powershell,
> >> either from the standard interface or writing cmdlets.
> >> I'm looking to automate a build system.
> >> Any help appreciated.Regards
> >> Sean.
> >
> 
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/using-wix-with-powershell-
> tp7537541p7548429.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respon

Re: [WiX-users] using wix with powershell

[Castro, Edwin G. (Hillsboro)]

Are you trying to build a wix project? The easiest way to do this is to simply 
call

msbuild solution.sln

Or perhaps

msbuild project.wixproj

Passing the usual command line arguments to msbuild.

If you are truly looking to call candle.exe, light.exe, etc. then just call 
them with the appropriate arguments.

What exactly is your goal?

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk]
> Sent: Monday, May 07, 2012 7:29 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] using wix with powershell
> 
> Hi All:
> Has anybody got any experience of automating wix from powershell, either
> from the standard interface or writing cmdlets.
> I'm looking to automate a build system.
> Any help appreciated.Regards
> Sean.
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] bug in wix 3.6?

[Castro, Edwin G. (Hillsboro)]

Option 1: Select Configuration Manager from the Build menu.
Option 2: Select Configuration Manager... from the solution context menu in 
Solution Explorer or Solution Navigator.
Option 3: Select Configuration Manager... from the Solution Configurations drop 
down on the Standard toolbar

In the Configuration Manager dialog you can select the solution Configuration 
and Platform and it will show you all of the projects in your solution and what 
Configuration|Platform will be built for that solution Configuration|Platform 
combination.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk]
> Sent: Friday, April 27, 2012 12:09 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] bug in wix 3.6?
> 
> Hi:
> And where finally can I see what is building for what platform?
> I know I can see but don't know where!
> Cheers
> Sean.
> 
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: 27 April 2012 20:02
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] bug in wix 3.6?
> 
> That is correct. You will still need to build twice as only one platform gets 
> built
> at a time.
> 
> You'll want to take a look at what projects are selected for each solution
> platform and make decisions about how to build your solution. Perhaps you
> need to build 3 times: AnyCPU, x86, x64.
> 
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> P Please consider the environment before printing this e-mail
> 
> 
> > -Original Message-
> > From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk]
> > Sent: Friday, April 27, 2012 10:58 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] bug in wix 3.6?
> >
> > Hi:
> > I am building one msi for x86, and x64 from the same project. If I am
> > interpreting you correctly, I can let visual studio create the new
> > solution platform for me.
> > Please correct me if I'm wrong!
> > Cheers
> > Sean.
> >
> > -Original Message-
> > From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> > Sent: 27 April 2012 17:57
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] bug in wix 3.6?
> >
> > Last time I looked at the WiX .targets files I noticed that they
> > create an InstallerPlatform property that is passed to candle. The
> > InstallerPlatform property can be explicitly set in your .wixproj.
> > When it is not explicitly set, the WiX .targets files use the Platform
> > property to determine what the value of InstallerPlatform should be. I
> > have found there is no need to specify Package/@Platform if you
> > directly or indirectly set InstallerPlatform. I personally set
> > Platform to be what I expect and let the WiX .targets files automatically 
> > set
> InstallerPlatform for me.
> >
> > If you want to build _one_ .wixproj as 32-bit _and_ 64-bit, then
> > you'll need two Platform variants in your .wixproj: x86 and x64. The
> > easiest way to accomplish this is to let Visual Studio do it for you.
> > WiX will automatically create the x86 Platform when you create the
> > project. If you have Visual Studio create the new
> > x64 Platform as a copy of x86 you'll be good to go. Note that you'll
> > need to build the project twice specifying the Platform to build in each 
> > case.
> >
> > If instead you have _one_ .wixproj that will always build as 32-bit
> > and a _second_ .wixproj that will always build as 64-bit, then you
> > just want to do a search/replace operation on the second .wixproj.
> > Search for x86 and replace it with x64 and you are done.
> >
> > If the general guidelines above do not apply to your build, then
> > please explain what your build intent is in more detail and I'll try
> > to help you configure your projects accordingly.
> >
> > FYI: The error you reported is saying that the schema used to validate
> > the .wxs XML says that you cannot use preprocessor variables as a
> > value for Package/@Platform. I don’t know whether that is intentional or 
> > not.
> >
> > Edwin G. Castro
> > Software Developer - Staff
> > Digital Channels
> > Fiserv
> > Office: 50

Re: [WiX-users] bug in wix 3.6?

[Castro, Edwin G. (Hillsboro)]

That is correct. You will still need to build twice as only one platform gets 
built at a time.

You'll want to take a look at what projects are selected for each solution 
platform and make decisions about how to build your solution. Perhaps you need 
to build 3 times: AnyCPU, x86, x64.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk]
> Sent: Friday, April 27, 2012 10:58 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] bug in wix 3.6?
> 
> Hi:
> I am building one msi for x86, and x64 from the same project. If I am
> interpreting you correctly, I can let visual studio create the new solution
> platform for me.
> Please correct me if I'm wrong!
> Cheers
> Sean.
> 
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: 27 April 2012 17:57
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] bug in wix 3.6?
> 
> Last time I looked at the WiX .targets files I noticed that they create an
> InstallerPlatform property that is passed to candle. The InstallerPlatform
> property can be explicitly set in your .wixproj. When it is not explicitly 
> set, the
> WiX .targets files use the Platform property to determine what the value of
> InstallerPlatform should be. I have found there is no need to specify
> Package/@Platform if you directly or indirectly set InstallerPlatform. I
> personally set Platform to be what I expect and let the WiX .targets files
> automatically set InstallerPlatform for me.
> 
> If you want to build _one_ .wixproj as 32-bit _and_ 64-bit, then you'll need 
> two
> Platform variants in your .wixproj: x86 and x64. The easiest way to accomplish
> this is to let Visual Studio do it for you. WiX will automatically create the 
> x86
> Platform when you create the project. If you have Visual Studio create the new
> x64 Platform as a copy of x86 you'll be good to go. Note that you'll need to
> build the project twice specifying the Platform to build in each case.
> 
> If instead you have _one_ .wixproj that will always build as 32-bit and a
> _second_ .wixproj that will always build as 64-bit, then you just want to do a
> search/replace operation on the second .wixproj. Search for x86 and replace it
> with x64 and you are done.
> 
> If the general guidelines above do not apply to your build, then please 
> explain
> what your build intent is in more detail and I'll try to help you configure 
> your
> projects accordingly.
> 
> FYI: The error you reported is saying that the schema used to validate the 
> .wxs
> XML says that you cannot use preprocessor variables as a value for
> Package/@Platform. I don’t know whether that is intentional or not.
> 
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> P Please consider the environment before printing this e-mail
> 
> > -Original Message-
> > From: Rob Mensching [mailto:r...@robmensching.com]
> > Sent: Friday, April 27, 2012 9:12 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] bug in wix 3.6?
> >
> > IIRC, by default it picks it up from your VS Configuration.
> >
> > On Fri, Apr 27, 2012 at 9:04 AM, Sean Farrow
> > wrote:
> >
> > > Is there a way to specify that in visual studio?
> > > Cheers
> > > Sean.
> > >
> > > -Original Message-
> > > From: Rob Mensching [mailto:r...@robmensching.com]
> > > Sent: 27 April 2012 15:37
> > > To: General discussion for Windows Installer XML toolset.
> > > Subject: Re: [WiX-users] bug in wix 3.6?
> > >
> > > Use the arch switch on the candle coomand-line and remove the
> > > Platform attribute.
> > >
> > > On Fri, Apr 27, 2012 at 5:10 AM, Sean Farrow
> > > wrote:
> > >
> > > > Hi Focks:
> > > > I think I've found a bug in wix 3.6:
> > > > I'm trying to create a solution that allows building two msi's one
> > > > x86
> > > and
> > > > one x64.
> > > > I have to following in my package element to this end:
> > > >  > > >  InstallerVersion="300"
> > > >  Compressed="yes"
> > > >  InstallScope="perMa

Re: [WiX-users] bug in wix 3.6?

[Castro, Edwin G. (Hillsboro)]

Last time I looked at the WiX .targets files I noticed that they create an 
InstallerPlatform property that is passed to candle. The InstallerPlatform 
property can be explicitly set in your .wixproj. When it is not explicitly set, 
the WiX .targets files use the Platform property to determine what the value of 
InstallerPlatform should be. I have found there is no need to specify 
Package/@Platform if you directly or indirectly set InstallerPlatform. I 
personally set Platform to be what I expect and let the WiX .targets files 
automatically set InstallerPlatform for me.

If you want to build _one_ .wixproj as 32-bit _and_ 64-bit, then you'll need 
two Platform variants in your .wixproj: x86 and x64. The easiest way to 
accomplish this is to let Visual Studio do it for you. WiX will automatically 
create the x86 Platform when you create the project. If you have Visual Studio 
create the new x64 Platform as a copy of x86 you'll be good to go. Note that 
you'll need to build the project twice specifying the Platform to build in each 
case.

If instead you have _one_ .wixproj that will always build as 32-bit and a 
_second_ .wixproj that will always build as 64-bit, then you just want to do a 
search/replace operation on the second .wixproj. Search for x86 and replace it 
with x64 and you are done.

If the general guidelines above do not apply to your build, then please explain 
what your build intent is in more detail and I'll try to help you configure 
your projects accordingly.

FYI: The error you reported is saying that the schema used to validate the .wxs 
XML says that you cannot use preprocessor variables as a value for 
Package/@Platform. I don’t know whether that is intentional or not.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Friday, April 27, 2012 9:12 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] bug in wix 3.6?
> 
> IIRC, by default it picks it up from your VS Configuration.
> 
> On Fri, Apr 27, 2012 at 9:04 AM, Sean Farrow
> wrote:
> 
> > Is there a way to specify that in visual studio?
> > Cheers
> > Sean.
> >
> > -Original Message-
> > From: Rob Mensching [mailto:r...@robmensching.com]
> > Sent: 27 April 2012 15:37
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] bug in wix 3.6?
> >
> > Use the arch switch on the candle coomand-line and remove the Platform
> > attribute.
> >
> > On Fri, Apr 27, 2012 at 5:10 AM, Sean Farrow
> > wrote:
> >
> > > Hi Focks:
> > > I think I've found a bug in wix 3.6:
> > > I'm trying to create a solution that allows building two msi's one
> > > x86
> > and
> > > one x64.
> > > I have to following in my package element to this end:
> > >  > >  InstallerVersion="300"
> > >  Compressed="yes"
> > >  InstallScope="perMachine"
> > >  Manufacturer="$(var.ProductAuthor)"
> > >  Platform="$(var.Platform)" /> Everything else is
> > > substituted except the var.platform and I am told that the value is
> > > invalid:
> > > 1 The 'Platform' attribute is invalid - The value '$(var.Platform)'
> > > is invalid according to its datatype 'NmToken' - The '$' character,
> > > hexadecimal value 0x24 cannot appear in the string.
> > > Anyone know whether this is a bug, or another way to achieve what
> > > I'm after?
> > > Any help appreciated.
> > > Regards
> > > Sean.
> > >
> > >
> > >
> > --
> > 
> > > Live Security Virtual Conference
> > > Exclusive live event will cover all the ways today's security and
> > > threat landscape has changed and how IT managers can respond.
> > > Discussions will include endpoint security, mobile security and the
> > > latest in malware threats.
> > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> >
> >
> >
> > --
> > virtually, Rob Mensching - http://RobMensching.com LLC
> >
> > --
> > 
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the
> > latest in malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > -

Re: [WiX-users] Using property when creating directory

[Castro, Edwin G. (Hillsboro)]

Define your directory like this:



And don't create a property for WEBSITEDIRNAME.

Essentially all directory ids behave like properties. Since you need to change 
the directory with a control that requires a public property so the directory 
id must be all uppercase.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: b.p.fal...@accenture.com [mailto:b.p.fal...@accenture.com]
> Sent: Tuesday, April 24, 2012 9:28 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Using property when creating directory
> 
> I have a property bound to control, named WEBSITEDIRNAME, and I would like
> to use the value when creating a  instead
> of static Name value.
> 
> Regards,
> 
> Benjamin Fallar III | Microsoft Developer Lead Avanade Software & Cloud
> Services (ASCS) Accenture | Manila
> 
> 
> "Plan Ahead. Be Ahead. Plan BCM."
> 
> www.accenture.com
> 
> 
> 
> Subject to local law, communications with Accenture and its affiliates 
> including
> telephone calls and emails (including content), may be monitored by our
> systems for the purposes of security and the assessment of internal compliance
> with Accenture policy.
> 
> __
> 
> www.accenture.com
> 
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Condition under component is not working

[Castro, Edwin G. (Hillsboro)]

This example still contains the Condition/@Level attribute. Make sure that 
attribute is removed!

Follow Rob's suggestion to check the verbose log to make sure the property 
values are what you expect.

I assume the Component in question is part of a Feature that has been selected 
to be installed, right?

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Sujitha Ramamoorthy [mailto:sujitha.ramamoor...@aspiresys.com]
> Sent: Monday, April 16, 2012 8:55 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Condition under component is not working
> 
> Even if I compare IISMAJORVERSION with number it is not working.
> 
> 
> 
> 
>   Description="$(var.EnterpriseWebSiteDescription)"
> Directory='ServerWebDIR'> 
>  
> 
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Monday, April 16, 2012 9:30 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Condition under component is not working
> 
> "#7" is a string. What string are you comparing it too? I don't think I've 
> used a
> string comparisons with any greater or less than before.
> 
> On Mon, Apr 16, 2012 at 8:33 AM, Sujitha Ramamoorthy <
> sujitha.ramamoor...@aspiresys.com> wrote:
> 
> > Hi,
> >
> > I added condition for IIS version under component but it is not working.
> >
> > 
> > 
> >   > Description="$(var.EnterpriseWebSiteDescription)"
> > Directory='ServerWebDIR'>  > />  
> >
> > Please anyone help for this problem.
> >
> > Thanks,
> > Sujitha
> >
> >
> > --
> >  For Developers, A Lot Can Happen In A Second.
> > Boundary is the first to Know...and Tell You.
> > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> > http://p.sf.net/sfu/Boundary-d2dvs2
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> 
> 
> 
> --
> virtually, Rob Mensching - http://RobMensching.com LLC
> --
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> 
> --
> Better than sec? Nothing is better than sec when it comes to monitoring Big
> Data applications. Try Boundary one-second resolution app monitoring today.
> Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] User-Friendly Site-Specific Installation

[Castro, Edwin G. (Hillsboro)]

Somebody is going to have to provide the site-specific information. The 
question is how do you want to specify it. Are you in a position to provide a 
small subset of your client a MSI package that has already been transformed? If 
not, then the client will need to be responsible for customizing the data.

One option is to use transforms which requires knowledge of the creation _and_ 
execution of transforms.

Another option might be to build a custom action that can read the data out of 
a file (XML, INI, what-have-you). In this case the client needs to be able to 
compose the file correctly and they'll still need to specify the file so that 
the MSI can find it... Or perhaps the MSI looks in a specific place and 
contains reasonable defaults if it doesn't find the file.

The last option is that the client interacts with the MSI UI to provide the 
data.

If you have a bootstrapper then your bootstrapper can help setup data for 
execution but the content of the data still needs to be provided by the client.

Double clicking without interaction implies that all the defaults used by the 
package apply to the target. I don't think there's a way to pass in custom data 
without the client putting some effort whether it is interacting with a UI, 
composing a file, or generating a transform.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail



> -Original Message-
> From: David Cramlet [mailto:decram...@gmail.com]
> Sent: Monday, March 19, 2012 4:04 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] User-Friendly Site-Specific Installation
> 
> Hi Edwin, Dirk, and All,
> 
> Those are some interesting ideas to ponder. But I also think I should clarify
> my situation. In my case, the issue isn't so much with creating the site-
> specific transforms. That task is performed by support staff proficient with
> the tools, and we have other reasons to have the transforms handy.
> 
> Rather the issue is with applying the transform; when the installer and
> appropriate transform are handed to the "end user" groups. (As I mentioned
> previously, even this isn't a problem if the group is familiar with assigning
> software via GPO, since they can just pick the transform file as part of the
> policy.) However, where we run into problems is with groups where IT has
> limited experience with large-scale deployment.
> 
> They really want to just "double-click the MSI and move on". The idea of
> using a command-line, or (bafflingly) even a batch file, makes them...
> grouchy. (Almost as much as when they decide to skip the transform and
> have to answer the installer's questions via UI on each of however-many
> workstations.)
> 
> Thank you for your thoughts,
> David Cramlet
> 
> --
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-
> msazure ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] User-Friendly Site-Specific Installation

[Castro, Edwin G. (Hillsboro)]

I haven't had time to do this yet but I'll throw it over the wall and see if 
anybody likes it as an idea.

In my case, all of the data we might want to customize on a per-site basis is 
exposed via public properties. I just need to provide the correct set of 
command line arguments, one for each customized public property.

I considered creating transforms to customize the values of these properties 
allowing each site to generate their own transform but the process for 
generating a transform seem rather difficult to me as you need the base package 
and the end-result package to generate the transform I often ask myself, if 
I have to create an end-result package anyway, then why not just use it 
directly?

Anyway, it makes a lot of sense in my case to build custom action that knows 
how to parse an XML file (or some other data format) that can be specified on 
the command line (similar to the TRANSFORMS property). The custom action would 
need to run early enough to customize public properties before the rest of the 
actions in the various sequences.

I haven't looked into building this yet for our deployments because we already 
have scripts that generate the appropriate command lines for us. I have not use 
burn yet but would love to see something similar to this available 
out-of-the-box without requiring a custom BA (I think that is what is required 
today for a burn generated bootstrapper).

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: David Cramlet [mailto:decram...@gmail.com]
> Sent: Friday, March 16, 2012 11:41 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] User-Friendly Site-Specific Installation
> 
> This may be more of a general Windows Installer question than a WiX
> question.
> 
> I have a deployment group asking if there is any way to make site-specific
> installation any easier than the "msiexec command-line magic" or "Orca
> voodoo" that transforms seem to require. Notably, this is for sites that are
> not using GPO-style deployment, since Windows takes care of applying the
> transforms in that case.
> 
> After some initial research, I am beginning to think the only other options
> would be a transform-aware bootstrapper, or just building a custom MSI for
> each site.
> 
> Since they always have exactly one transform for the product in question,
> the first thing I (perhaps foolishly) tried was adding the TRANSFORMS
> property to the Property table of the MSI, with a value along the lines of
> "@SiteSpecific.mst" (with such an MST in the same folder as the MSI). As you
> might expect, this (and various variations
> thereof) had no discernible effect.
> 
> Any thoughts would be much appreciated.
> 
> Thank you,
> David Cramlet
> decram...@gmail.com
> 
> --
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-
> msazure ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Setting MsiLogFileLocation property

[Castro, Edwin G. (Hillsboro)]

In addition, the Windows Installer engine starts producing log messages before 
it loads the MSI package to determine what log file to use.

In short, one can set a log file:
* On the command line
* As an argument to MsiProductInstall()
* In the registry (global and applies to all MSI packages, cannot be changed on 
a per package basis)

The MsiLogFileLocation property is automatically set by the Windows Installer 
engine to allow a MSI UI to display the log file location on a dialog. Changing 
the value of MsiLogFileLocation within the MSI package itself does not change 
where the Windows Installer engine is logging to (as evidenced by the tests 
performed by various people).

To automatically set a log file you'll need to use a bootstrapper as was 
already suggested so that the bootstrapper can set it on the command line or as 
an argument to MsiProductInstall().

Your system administrator could use the registry approach to control whether 
all MSI packages generate a log file to a specific folder location with a 
random: MSI*.LOG name.

This is documented in the MSDN documentation so if anybody wants to use this 
approach I suggest they check MSDN at 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372847.aspx

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail



> -Original Message-
> From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
> Sent: Thursday, March 15, 2012 11:22 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Setting MsiLogFileLocation property
>
> A good test anyone can try. Run a command something like this.
>
> MSIEXEC.EXE /L*v C:\Foobar\test.log /I 
>
> For that log folder that you point to make sure the C:\Foobar directly DOES
> NOT EXIST.
>
> Note how MSIEXEC.EXE will simply error out rather than creating the Foobar
> folder in which to create the log file.
>
> I feel this shows an example of what Edwin and others are talking about. Log
> file must be established before MSIEXEC calls into the MSI.
>
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: Thursday, March 15, 2012 11:10 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Setting MsiLogFileLocation property
>
> WiX is not in control of the MsiLogFileLocation property. This is 
> functionality
> provided by Windows Installer.
>
> As mentioned earlier, the log file location must be set before the MSI
> package is loaded by the Windows Installer engine. This is how Windows
> Installer works and the WiX team has no control over it.
>
> Please refer to http://msdn.microsoft.com/en-
> us/library/windows/desktop/aa372847.aspx for information on Windows
> Installer Logging. In particular check the Normal Logging  section at
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa370536.aspx
> for an explanation of your options.
>
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> P Please consider the environment before printing this e-mail
>
>
>
> > -Original Message-
> > From: Alec Swan [mailto:alecs...@gmail.com]
> > Sent: Thursday, March 15, 2012 10:44 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Setting MsiLogFileLocation property
> >
> > Phil, thank you for sharing your experience.
> >
> > I would like to keep this thread active until we get a definite answer
> > from the WIX team. Whether it is "You can't enable MSI logging in the
> > current version of WIX but will be available in version x.x" or "This
> > is how you do this ..." - it will still be very helpful.
> >
> > Thanks,
> >
> > Alec
> >
> > On Thu, Mar 15, 2012 at 11:32 AM, Wilson, Phil
> > 
> > wrote:
> > > You can't set MsiLogFileLocation, as the MSDN docs pretty much say.
> > > You
> > can try to set it but it's ineffective. If you set it in the property
> > table it just gets overwritten. If you set it with a type 51 it just gets 
> > ignored.
> > >
> > > Phil W
> > >
> > > -Original Message-
> > > From: Alec Swan [mailto:alecs...@gmail.com]
> > > Sent: Thursday, March 15, 2012 10:09 AM
> > > To: General discussion for Windows Installer XML toolset.
> > > Subject: Re: [WiX-users] Setting MsiLogFileLocation property
> > >
> > > Adam,
> > >
> > > This post indicates that it is 

Re: [WiX-users] Setting MsiLogFileLocation property

[Castro, Edwin G. (Hillsboro)]

WiX is not in control of the MsiLogFileLocation property. This is functionality 
provided by Windows Installer.

As mentioned earlier, the log file location must be set before the MSI package 
is loaded by the Windows Installer engine. This is how Windows Installer works 
and the WiX team has no control over it.

Please refer to 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372847.aspx for 
information on Windows Installer Logging. In particular check the Normal 
Logging  section at 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa370536.aspx for an 
explanation of your options.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail



> -Original Message-
> From: Alec Swan [mailto:alecs...@gmail.com]
> Sent: Thursday, March 15, 2012 10:44 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Setting MsiLogFileLocation property
> 
> Phil, thank you for sharing your experience.
> 
> I would like to keep this thread active until we get a definite answer from 
> the
> WIX team. Whether it is "You can't enable MSI logging in the current version
> of WIX but will be available in version x.x" or "This is how you do this ..." 
> - it
> will still be very helpful.
> 
> Thanks,
> 
> Alec
> 
> On Thu, Mar 15, 2012 at 11:32 AM, Wilson, Phil 
> wrote:
> > You can't set MsiLogFileLocation, as the MSDN docs pretty much say. You
> can try to set it but it's ineffective. If you set it in the property table 
> it just
> gets overwritten. If you set it with a type 51 it just gets ignored.
> >
> > Phil W
> >
> > -Original Message-
> > From: Alec Swan [mailto:alecs...@gmail.com]
> > Sent: Thursday, March 15, 2012 10:09 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Setting MsiLogFileLocation property
> >
> > Adam,
> >
> > This post indicates that it is possible to set MSI property from WIX:
> > http://blogs.technet.com/b/alexshev/archive/2009/05/16/from-msi-to-
> wix
> > -part-23-dll-custom-actions-logging-and-setting-properties.aspx
> >
> > If this is true, shouldn't I be able to use this approach to set some
> > kind of MSI property to force logging and/or configure location of the
> > log file?
> >
> > Enabling logging seems to be a pretty common question on the WIX
> > forum, can we have WIX team to provide a recommendation on how to do
> > this?
> >
> > Thanks,
> >
> > Alec
> >
> > On Thu, Mar 15, 2012 at 10:54 AM, Adam Kadzban
> >  wrote:
> >> Alec,
> >>
> >> As far as I know, you can't set the log file location inside WIX
> >> because you need to tell msiexec where to write the log file to
> >> before actually starting the MSI.  You need some sort of bootstrapper
> >> that calls msiexec with the logging options. I've used IExpress in
> >> the past, but I think I'll be switching to dotNetInstaller soon.
> >>
> >> -Adam
> >>
> >> On Thu, Mar 15, 2012 at 11:43 AM, John Cooper
> wrote:
> >>
> >>> I've seen the same bugs CP has seen.  I've got it set in my
> >>> installers, but only because CD demands it.  Setting it causes a
> >>> fair number of install failures, particular in install/repair/uninstall 
> >>> cycles.
> >>>
> >>> --
> >>> 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: Alec Swan [mailto:alecs...@gmail.com]
> >>> Sent: Thursday, March 15, 2012 11:30 AM
> >>> To: General discussion for Windows Installer XML toolset.
> >>> Subject: Re: [WiX-users] Setting MsiLogFileLocation property
> >>>
> >>> The following thread implied that the file log location can be set
> >>> through MsiLogFileLocation property in WIX:
> >>>
> >>> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Msi-Lo
> >>> gging-td707004.html#a707011
> >>>
> >>> But it sounds like Rob is saying this is not possible.
> >>>
> >>> So, how can I reliably enable MSI logging programmatically in WIX
> >>> code and ideally set the location of the log file? We need to
> >>> support Windows XP SP2 and higher.
> >>>
> >>> Thanks,
> >>>
> >>> Alec
> >>>
> >>> On Thu, Mar 15, 2012 at 10:05 AM, Christopher Painter
> >>> 
> >>> wrote:
> >>> > I don't know if this is common knowledge but I don't set the
> >>> > MsiLogging property anymore.  There' s a known bug in Windows 7
> >>> > where Explorer / Shell can lose reference to the installer log
> >>> > file location and it causes the installer to crash out.    It can
> >>> > manifest itself on uninstall  which means you are stuck unless you
> >>> > run the uninstall from the command line passing in an explicit path.
> >>> >
> >>> > 
> >>> >
> >>> > From: "Rob Mensching" 
> >>> >
> >>

Re: [WiX-users] Running a single MSI on the same machine more than once concurrently

[Castro, Edwin G. (Hillsboro)]

We have a webservice package and a database package. We run the webservice 
package one 1 or more servers while we only run the database package on a 
single server.

We started with a single package that installed both. That caused problems 
because we could not choose separately when to deploy the webservice and when 
to deploy the database.

Now we have two packages. The database package used to install the database 
deployment tools _and_ deploy the database using those tools. Now it only 
installs the tools. The database deployment needs to be started separately.

Perhaps in the future we can combine both packages again and allow database 
deployment from _any_ server with the webservice installed. That does mean that 
we *MUST* install the webservice to get access to the tools for database 
deployment. Hmm... perhaps we'll keep them separate...

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Michael Osmond [mailto:mosm...@baytech.com.au]
> Sent: Wednesday, March 14, 2012 5:08 PM
> To: chr...@iswix.com; General discussion for Windows Installer XML toolset.;
> John Cooper
> Subject: Re: [WiX-users] Running a single MSI on the same machine more
> than once concurrently
>
> Hi
>
> >From experience of shipping to customers an installer that can do both
> scenarios, the two part install might be intuitive, but it's a right pain in
> practice.   I now avoid doing the two part installs if at all possible.
>
> Also the single install location is generally much easier if the database is
> moved (depending on app design).  We change a single registry entry
> dbServer, and that's it for the install.  When the DB Install is on the 
> database
> server you end up with all sorts of contortions when the database is moved.
>
> Michael
>
>
> -Original Message-
> From: Christopher Painter [mailto:chr...@iswix.com]
> Sent: Thursday, 15 March 2012 5:20 AM
> To: John Cooper; General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Running a single MSI on the same machine more
> than once concurrently
>
> Understood.  Which actually illustrates why it can make sense to split the
> database setup from the main install because one day you might want to
> relocate the database and reconfigure the application server and it might be
> difficult if only the installer knows how to service the database.
>
>
> Still, as I said, people seem to be more concerned with me just getting it
> done for them then worrying about that scenario.
>
> 
>
> From: "John Cooper" 
>
> Sent: Wednesday, March 14, 2012 12:14 PM
>
> To: "chr...@iswix.com" , "General discussion for
> Windows Installer XML toolset." 
>
> Subject: RE: [WiX-users] Running a single MSI on the same machine more
> than once concurrently
>
>
> Application on the server farm and database on a (separate) database server
> is the norm for my applications. Reality is that the database servers
> aren't even generally in the same physical location as the server farm, and
> the installing account on the server farm only has just enough rights to
> make the connection string authenticate and create/update a database. No
> drop rights (for instance) at all.
>
>
> --
>
> 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: Christopher Painter [mailto:chr...@iswix.com]
>
> Sent: Wednesday, March 14, 2012 11:19 AM
>
> To: General discussion for Windows Installer XML toolset.; General
> discussion for Windows Installer XML toolset.
>
> Subject: Re: [WiX-users] Running a single MSI on the same machine more
> than
> once concurrently
>
>
> I've often wondered this myself and designed my installer per customer
> requirements.
>
>
> I agree, it seems wierd to have MSI state data on one machine registering
> resource data on another machine. Still, it does work in situations where
> the person doing the installer has DBA rights on the instance but not SA
>
> rights on the instances OS. Othertimes I've restricted the instance name
>
> for the connection to the local machine.
>
>
> The only way I see to solve this dilema is to remove all database
> functionality from the installer and put it into a deployment/configruation
> utility that can then be run multiple times. However most of my clients
> have said no when I suggested this with sort of an attitude of "I want the
> installer to do it, that's why I'm paying you... I don't have time to do it
> myself."
>
>
> So I usually just make sure they are happy with what I give them and
> collect my $200 when I pass go.
>
>
> FWIW, I've developed a lot of installers over the years doing various
>
> client/server an

Re: [WiX-users] Wow!

[Castro, Edwin G. (Hillsboro)]

Bruce, can you provide a direct link to the thread? I'm having trouble finding 
it.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Bruce Cran [mailto:br...@cran.org.uk]
> Sent: Monday, March 05, 2012 9:14 AM
> To: General discussion for Windows Installer XML toolset.
> Cc: Castro, Edwin G. (Hillsboro); chr...@iswix.com
> Subject: Re: [WiX-users] Wow!
> 
> On 05/03/2012 17:03, Castro, Edwin G. (Hillsboro) wrote:
> > Often corporate policies restrict internet access in such a way where asking
> each development machine to download the packages is actually very painful.
> Local caches (which should be accessible directly on the target server _or_ a
> local network share _or_ on a local web server) should be supported for
> enterprise deployments.
> >
> > I'm not saying that download and verification provides absolutely no value
> because that functionality provides value to the average user that is 
> installing
> software to their home computer. What I'm saying is that when there is an IT
> department between you and management of your machine then features like
> download and verification only provide marginal value because IT departments
> often want to be in more control.
> 
> There was a rather lengthy discussion about this wrt driver development at
> http://www.osronline.com/cf.cfm?PageURL=showlists.cfm?list=NTDEV a few
> days ago.
> 
> --
> Bruce Cran
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wow!

[Castro, Edwin G. (Hillsboro)]

Often corporate policies restrict internet access in such a way where asking 
each development machine to download the packages is actually very painful. 
Local caches (which should be accessible directly on the target server _or_ a 
local network share _or_ on a local web server) should be supported for 
enterprise deployments.

I'm not saying that download and verification provides absolutely no value 
because that functionality provides value to the average user that is 
installing software to their home computer. What I'm saying is that when there 
is an IT department between you and management of your machine then features 
like download and verification only provide marginal value because IT 
departments often want to be in more control.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Albert van Peppen [mailto:alb...@insad.nl]
> Sent: Monday, March 05, 2012 8:52 AM
> To: chr...@iswix.com; General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wow!
> 
> I agree 100% with this. That is basically why I keep the entire history of 
> WiX in
> my repository (diskspace isn't that expensive nowadays :) )
> 
> 
> Best regards,
> 
> Albert van Peppen
> Senior System Engineer
> 
> Insad Grafisch b.v.
> Mollevite 28
> 6931 KG  Westervoort
> The Netherlands
> 
> Phone: *31 (0) 26 319 01 50
> Email: alb...@insad.nl
> Website: www.insad.nl
> 
> -Oorspronkelijk bericht-
> Van: Christopher Painter [mailto:chr...@iswix.com]
> Verzonden: 05 March 2012 16:49
> Aan: Rob Mensching; General discussion for Windows Installer XML toolset.
> Onderwerp: Re: [WiX-users] Wow!
> 
> Rob,
> 
> Regarding /layout,  all developers *SHOULD* be doing it despite losing those
> "savings".  (Assuming any savings is actually realized based on how many
> developers are installing the software. )
> 
> 
> Anyone involved in the process of developing software ( especially build and
> release engineering )  should have mature policies regarding the
> ability to track and archive changes to the development environment.If
> I have to rebuild a build machine or developer machine I have to be able go
> back and reinstall all of the tools exactly the way they were originally 
> intended.
> 
> 
> Relying on content for a web-enabled installer to be available 1,5,10 years
> down the road ( we still get requests to rebuild VB6 applications! )  is a 
> horrible
> practice as the external dependency is outside of your control.
> You must keep your own archive of the tool to ensure the SLA can b met.
> Everyone who understands CM should be doing this.
> 
> 
> Thus /layout is not only an annoyance to me, it's an antipattern.
> 
> 
> Chris
> 
> 
> 
> From: "Rob Mensching" 
> 
> Sent: Monday, March 05, 2012 9:38 AM
> 
> To: chr...@iswix.com, "General discussion for Windows Installer XML toolset."
> 
> 
> Subject: Re: [WiX-users] Wow!
> 
> 
> 1. The WiX install *does* chain NETFX 4 in because that is needed before the
> WiX BA can show UI (since the WiX BA is written in WPF).
> 
> 2. Dogfooding is the primary reason.
> 
> 3. We save *significant* bandwidth using Burn because during normal installs 
> it
> only downloads the portions of the product that you actually need.
> 
> If *everyone* start using /layout those savings will be lost. 
> 
> 4. The wixstdba UI is not as functional as we'd like but the web install
> experience is significantly better. Click download like, survive the web 
> browser
> screening process (this gets better if we can get WiX signed), click "Run" 
> and in
> a second the ~500kb exe is verified and running. Then you have a nice
> experience while the process downloads and installs only the parts you need.
> 
> Admittedly, if you want a full layout, then you do "Save" and have to run
> another command-line. That scenario is not optimized.
> 
> 5. ISOs are inferior to /layout because they do not get the built-in robust
> downloading of Burn. You could use a 3rd party downloader but that 3rd party
> download cannot verify the downloaded ISO file the way Burn will verify and
> retry each file.
> 
> 
> We are moving the cheese a little bit here to challenge the status quo and see
> if we can't make things better for advanced users and less-advanced users at
> the same time. My takeaway is that we may have deprioritized the /layout
> scenario too much and should evaluate that going into the home stretch.
> 
> 
> 
> On Mon, Mar 5, 2012 at 7:06 AM, Christopher Painter 
> wrote:
> 
> Other then being allowing WiX to dogfood Burn,  what benefit does the WiX
> 
> installer even gain from using Burn?  I thought the old Mondo UI looked
> 
> just fine and it was a simpler 1 MSI story to boot.   My experience with
> 
> the Burn based WiX installers is that user experience is inferior relative
> 
> to w

Re: [WiX-users] Uninstallation

[Castro, Edwin G. (Hillsboro)]

You have a few options for generating a verbose log file.
See http://msdn.microsoft.com/en-us/library/windows/desktop/aa370536.aspx

Probably the easiest way to generate a verbose log file at *install-time* is to 
do it on the command line:

msiexec /i "path\to\package.msi" /l*v "path\to\install.log"

To generate a verbose log file at *uninstall-time" it would probably be easiest 
to do it on the command line as well:

msiexec /x "path\to\package.msi" /l*v "path\to\uninstall.log"

Sounds like you want to focus on which actions are selected to execute during 
uninstall. Since you have customized the UI dialogs, you might want to start 
there.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


-Original Message-
From: DellaRosa, James [mailto:jdellar...@aspexcorp.com] 
Sent: Tuesday, February 28, 2012 11:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Uninstallation

It is from my understanding that when someone creates their own custom dialogs 
that they are extending (so to speak) the WixUI_InstallDir.  That being said 
the .msi that is used to install my application should also be able to 
uninstall that same application.  However whenever I click on it to uninstall 
it just runs the installer again. There is no error message, and the program 
continues through the installation fully (i.e. it overwrites everything).  I 
guess my question here is, is there something I missed?  Am I supposed to make 
a call to an uninstall method like the following?

 
 


Also embarrassingly enough I am not sure how to access the verbose installer 
logs...

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers is just 
$99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style 
Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] error LGHT0103: The system cannot find the file '[filename]' with type ''.

[Castro, Edwin G. (Hillsboro)]

.NET limits paths to 260 characters (or something very similar). With a 
filename that is 195 characters long you'll need to make sure the rest of the 
path is short enough to not hit the path limit in .NET.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


-Original Message-
From: Joe Osman [mailto:joe.os...@taitradio.com] 
Sent: Thursday, February 16, 2012 11:22 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] error LGHT0103: The system cannot find the file 
'[filename]' with type ''.

I am getting Light error 0103 when the full file name length is longer than 195 
characters.
This is the error (I replaced the real file name with [filename]):
  error LGHT0103: The system cannot find the file '[filename]' with type ''.

No issue when I shorten the name of the build folder so that the total file 
name length is shorter than 195 characters.

Is there any solution to this issue?

Thanks

===
This email, including any attachments, is only for the intended addressee.  It 
is subject to copyright, is confidential and may be the subject of legal or 
other privilege, none of which is waived or lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our apologies, 
notify us by return, delete all copies and perform no other act on the email.
Unfortunately, we cannot warrant that the email has not been altered or 
corrupted during transmission.
===


--
Virtualization & Cloud Management Using Capacity Planning Cloud computing makes 
use of virtualization - but cloud computing also focuses on allowing computing 
to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WIX Example

[Castro, Edwin G. (Hillsboro)]

A component in Windows Installer is the smallest "atom" available. It is 
immutable. In particular, the Windows Installer engine decides which resources 
to process based on which components are selected. When you place more than one 
physical resource in a component you lose the ability to patch/update/upgrade 
the files separately. For example, if the helper dll changes but the executable 
doesn't then any patches/updates/upgrades MUST change both the helper dll and 
the executable because the component as a whole is processed. Users are not 
allowed to select components directly. The setup developer is responsible for 
collecting components that must be installed together into features that are 
selectable by the user.

Understanding the component rules and types of updates/upgrades is crucial to 
understanding the rationale for features and components in Windows Installer.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail



-Original Message-
From: Phillip Wu [mailto:phillip...@lpi.nsw.gov.au] 
Sent: Sunday, February 05, 2012 4:11 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WIX Example

I am reading the tutorial:
http://wix.tramontana.co.hu/tutorial
In the first example presented (samplefirst.wxs) there is an executeable, 
helper dll, pdf instruction manual.

When the example is built it makes the executeable, icons, shortcuts one 
component.
The helper dll is put into another component.

Should not the executeable, icons, shortcuts and helper dll be in the same 
component as the executeable will not function without the dll?

***
This message is intended for the addressee named and may contain confidential 
information. If you are not the intended recipient, please delete it and notify 
the sender. Views expressed in this message are those of the individual sender, 
and are not necessarily the views of the NSW Government. This email message has 
been swept by MIMEsweeper for the presence of computer viruses.
***
Please consider the environment before printing this email.
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers is just 
$99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style 
Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Harvesting dll's referenced in a c# project in VS

[Castro, Edwin G. (Hillsboro)]

To share my experience with harvesting:

We had a very simple setup (no COM, no installutil automated setup, etc.). The 
projects producing built assemblies were responsible for staging all required 
files in such a way that we could use heat to harvest a directory into the 
setup. We didn't use project harvesting because it didn't harvest everything we 
wanted/needed to harvest. In this particular case, there were a number of files 
that were not part of the project proper but we included them as links so that 
we could have the project copy them into the output directory of the project. A 
developer accidentally removed these files from the project file causing the 
files to disappear from the MSI package. This was unfortunately not discovered 
until after release and became a huge embarrassment to our organization. This 
is a simple case of inadequate testing at both DEV and QA levels but had we not 
depended on harvesting (we no longer use automatic harvesting as part of our 
build process) we would have discovered the missing files at build time rather 
than much, much later.

Using * to allow WiX to manage component GUIDs is so easy and robust now that 
whenever I hear somebody complain that they don't want to take the time to 
manage their component GUIDs I simply hear "I don't want to invest the time 
learning WiX, Windows Installer, nor what proper setup should look like on 
Windows platforms." Even heat can be told to use * rather than generating GUIDs 
which makes a great tool to generate WiX source initially. Heat can even 
post-process a file using XSLT to perform simple transformations. With nearly 
all development frameworks using XML to such a large degree I STILL find it 
confusing how so many people cannot work with XML, XPATH, nor XSLT. I *am* paid 
to produce quality software and that includes quality setup packages. I 
personally make it my mission to learn all the technology I use well enough to 
produce quality software. There is a time and place to use automation, code 
generation, and other software tools. In the case of Windows Installer 
packages, you rarely want to use automatic harvesting as part of your build 
process. Many of us share this advice multiple times a month out of our own 
experiences. We haven't failed to use it (we use it successfully) but have 
learned (more importantly) when _not_ to use it.

Edwin G. Castro

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com] 
Sent: Sunday, February 05, 2012 1:53 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Harvesting dll's referenced in a c# project in VS

Yes probably a bug but bottom line is VS deployment projects suck! It is more 
an issue with maintaining a reliable build or my installation project when 
moving the build between development and build machine, mainly it is related to 
COM references but I have also had issues with different versions of enterprise 
library. Also, its behaviour changes depending on whether the component is in 
the GAC for not often dev machines will have local references but build 
machines don't.

I think I may not have explained what I do clearly. I do use harvesting but 
only at the start, I build all the source and write the output to a single 
folder or folder layout that matches the deployment. This picks up all the 
files and the references (as long as "Copy local" is set). I then run heat on 
that folder to generate a WiX source file. After that I maintain that file 
manually as I find it rarely changes but if it does I simply re-run the heat 
step. I find this keeps my install in a known state and if references are added 
I can validate them. For example, if someone adds a reference to v2 of a 
component and all other projects use v1 I need to validate whether the target 
system will support that or whether I need to deploy a new runtime install. 

Neil

-Original Message-
From: Michael Powell [mailto:mwpowel...@gmail.com]
Sent: 04 February 2012 22:45
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Harvesting dll's referenced in a c# project in VS

Yessir, which to me sounds like a bug. At least in our project, there are a 
MASSIVE number of assemblies with an equally MASSIVE number of references.
There simply aren't enough hours in the day to maintain all that by hand over 
the long haul.

On Sat, Feb 4, 2012 at 4:27 PM, Neil Sleightholm  wrote:

> Like you say each to his own but I have wasted a ridiculous amount of 
> time sorting out the mess Visual Studio deployment projects make of 
> auto harvesting.
>
> Neil
>
> -Original Message-
> From: Michael Powell [mailto:mwpowel...@gmail.com]
> Sent: 04 February 2012 20:10
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Harvesting dll's referenced in a c# project 
> in VS
>
> Personally, each to his own I suppose. Professionally, I'm not being 
> paid to sit on top of my resource

Re: [WiX-users] Patch building with Torch, all .NET assemblies "changed"

[Castro, Edwin G. (Hillsboro)]

My initial guess is that your assembly's versions are changing between builds.

I'm very interested in a proposed approach to this as we have a build that 
results in changed versions on every build. I haven't personally investigated 
an approach to handle this yet. I haven't had the time yet to do it.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: john.burak [mailto:john.bu...@telvent.com]
> Sent: Thursday, January 26, 2012 11:00 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Patch building with Torch, all .NET assemblies "changed"
> 
> We recently implemented patch building using Torch/Pyro.  We are keeping
> the old MSI and totally rebuilding a new one for Torch to diff with.  The
> problem is that Torch sees all of our .NET assemblies as changed even though
> the source code only changed in a few.  We did some digging and it turns out
> that if we recompile an assembly with the same source code, the binary result
> (DLL or EXE) is different from the first build.  Perhaps it's putting a date 
> stamp
> inside.  Our guess is that Torch is doing a binary comparison and sees the 
> file as
> changed.  We need a patch with only the few files who's source code has
> changed.
> 
> So the question is, how do people handle this situation?  We could try to 
> change
> our build process so that we don't rebuild every project the second time (let
> MSBuild pick just the changed ones), but then we won't get "clean"
> builds and we won't detect circular references between assemblies (developers
> sometimes accidentally do that).  We can limit the impact by doing a non-clean
> build for only the patch.  This may be the only option, but I wanted to get 
> some
> opinions first.  Maybe there is something I'm missing here.
> 
> Thanks for your input!
> 
> - John
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/Patch-building-with-Torch-all-NET-assemblies-
> changed-tp7227881p7227881.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers is 
> just
> $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style
> Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec

[Castro, Edwin G. (Hillsboro)]

I have noticed a weird scenario similar to 1). In my case, I'm using the IIs 
custom actions in WiX 3.5. Sometimes the package fails with a 1603 error during 
WriteIIs7ConfigChanges. Rerunning the package succeeds. The error information I 
see in the log is always consistent and looks like this:

MSI (s) (04:48) [10:20:12:899]: Executing op: 
CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**)
MSI (s) (04:30) [10:20:12:906]: Invoking remote custom action. DLL: 
C:\Windows\Installer\MSI259A.tmp, Entrypoint: WriteIIS7ConfigChanges
WriteIIS7ConfigChanges:  Error 0x80070103: Failed read webDir webkey
WriteIIS7ConfigChanges:  Error 0x80070103: Failed to configure IIS web svc ext.
WriteIIS7ConfigChanges:  Error 0x80070103: WriteIIS7ConfigChanges Failed.
CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this 
may not be 100% accurate if translation happened inside sandbox)
Action ended 10:20:13: InstallFinalize. Return value 3.

I looked through the WiX code to try to identify what might generated the 
"Failed read webDir webkey" message and found a few locations. I think the 
error occurs when the custom action is trying to parse the data out of 
CustomActionData but when I try to follow the data back to its source (I 
struggled here...) it seemed to me that CustomActionData should not have had 
anything in it for that particular piece of code because the source table does 
not exist in my package.

I don't know whether this is a bug in the WiX IIs custom actions or something 
more sinister, like a Windows Installer API bug!

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


-Original Message-
From: Christopher Painter [mailto:chr...@iswix.com] 
Sent: Tuesday, January 24, 2012 8:35 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec

I have an installer that I wrote that I've been pushing out through SCCM.  
We have deployed to about 600 servers so far and so far I've seen 6 failures.  
There are 3 of one failure mode and 3 of another.


1) C# DTF terminates with 1603

   This one is wierd.  It's a deferred CA that get's it's CustomActionData 
property and then does something for each record in the collection.  
There's actually no records in the collection so therefore nothing to do.  
I don't get any kind of .NET stack dump it just simply logs that it started 
and then poof the CA returns with a 1603.  On the other 597 servers it 
works ( i.e. does nothing ) just fine.  ( Trivia: it's really an uninstall 
custom action  that can be instructed to remove something during an install 
I just haven't neeed to yet. )   If I run this install again on the same 
machine it works. 


2) I use a QuietExecCA64  to call dism to install a Windows feature.  I see 
in the log that DISM added the feature and completed successfully but then 
that's the end of my MSI log.  It's like either DISM didn't actually 
terminate of the C++ code didn't terminate and it hung MSI.   SCCM then 
waited a period of time ( 20 minutes ) and decided that the MSI was 
orphaned and killed it followed by a reboot.  


All of these machines are Server 2008 R2 SP1.


Does anyone have any thoughts about this?  I could redo #1 as a C++ CA and 
I could factor the DISM call out of the MSI and into the SCCM task sequence 
but I think at this point people are willing to take their changes since we 
are already 25% into the deployment.   I'm wondering if there are any bugs 
in DTF and or the QuietExec patterns that need to be investigated.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Generated MSI Name

[Castro, Edwin G. (Hillsboro)]

How do you want to generate your name? This will determine how we change 
OutputName.

OutputName is just a MSBuild property but one that is used by all project 
types. I believe (but have not verified) that if you build your solution from 
the command line providing a different value for OutputName you'll end up with 
all of your projects in that solution with the same name.

msbuild sample.sln /p:OutputName=GeneratedName /t:build

You'll probably want to define a new custom property in your .wixproj  so that 
you can change only the OutputName in the .wixproj.


  
...
DefaultValue
$(SetupName)
...
  
  ...


In the sample above I define a new property, SetupName, before OutputName. I 
use the value of SetupName as the value for OutputName. Note that you'll need 
to hand edit the .wixproj.

Now we should be able to set SetupName on the command line to whatever 
generated name we want and not affect OutputName for any other projects.

msbuild sample.sln /p:SetupName=GeneratedName /t:build

This all assumes that the name is generated before the solution begins building.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Daniel Sniderman [mailto:dani...@magenic.com]
> Sent: Thursday, January 12, 2012 9:24 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Generated MSI Name
> 
> I see that it's set in the Designer as "Output Name" which is a MSBuild
> Property.  Is there any way (other than having the build edit the .wixproj or
> copy/rename after the it's generated) to change the output MSI?
> 
> Thanks
> 
> Daniel P. Sniderman| Sr Consultant| Magenic MCSD.NET, MCTS: Team
> Foundation Server 2010 Administration
> 
> 333 E. Butterfield Rd. Suite 100, Lombard, IL 60148
> Mobile: 847-668-4882  | eFax 847-390-7810 magenic.com |
> dani...@magenic.com
> 
> 
> --
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Accessing file in MSI before it's installed

[Castro, Edwin G. (Hillsboro)]

A CustomAction cannot have more than one BinaryKey.

The CheckEmailExists function will need to be responsible for extracting any 
resources it needs from the Binary table as well as cleanup.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Kevin Hebert [mailto:ke...@legendary-immersion.com]
> Sent: Tuesday, January 03, 2012 11:14 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Accessing file in MSI before it's installed
> 
> This might sound incredibly silly, but can a custom action have more than one
> BinaryKey?  I currently have:
> 
>  DllEntry="CheckEmailExists" />
> 
> Currently, the BinaryKey here is the file that holds the custom action.
> But I'm wanting to access a server and root pem file.  Thanks.
> 
> On 1/3/2012 12:35 PM, Kevin Hebert wrote:
> > Thanks.  I'll take a look into that.  The function I'm writing that is
> > calling the sslConnect function is a custom action in itself.  So this
> > shouldn't be too difficult.  Hopefully.
> >
> > On 1/3/2012 12:24 PM, Adam Kadzban wrote:
> >> You could include the file as a Binary, then have a custom action call it:
> >>
> >>   >> Id="DoMyThing" BinaryKey="MyEXE" Execute="deferred" />
> >>
> >> -Adam
> >>
> >> On Tue, Jan 3, 2012 at 12:06 PM, Kevin
> >> Hebert >>> wrote:
> >>> I have an sslConnect function which requires a file that is normally
> >>> installed before the function is called.  However, due to a change
> >>> in what the client wants, I need to call the function before its
> >>> installed.  Is there a way to access the file before installation?  
> >>> Thanks.
> >>>
> >>> --
> >>> Kevin Hebert
> >>>
> >>>
> >>> 
> >>> --
> >>> Write once. Port to many.
> >>> Get the SDK and tools to simplify cross-platform app development.
> >>> Create new or port existing apps to sell to consumers worldwide.
> >>> Explore the Intel AppUpSM program developer opportunity.
> >>> appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev
> >>> ___
> >>> WiX-users mailing list
> >>> WiX-users@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>>
> >> -
> >> -
> >> Write once. Port to many.
> >> Get the SDK and tools to simplify cross-platform app development.
> >> Create new or port existing apps to sell to consumers worldwide.
> >> Explore the Intel AppUpSM program developer opportunity.
> >> appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev
> >> ___
> >> WiX-users mailing list
> >> WiX-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>
> >>
> >
> 
> 
> --
> Kevin Hebert
> 
> 
> --
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] files and components

[Castro, Edwin G. (Hillsboro)]

Remember that a user never selects components directly. They select features.

My guess is that you want 7 or 8 features that will select the components 
required on a per-feature basis.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Michael Scheepers [mailto:mscheep...@tool-links.de]
> Sent: Wednesday, December 21, 2011 6:37 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] files and components
> 
> Hi there,
> 
> I am very new to WiX and I ask me if it is possible (recommended) to define
> multiple files in one component?
> 
> Unfortunately I have to create a msi for about 4.500 files and in my opinion
> that might be 7 or 8 components to install.
> 
> So is it ok to combine a thousand files in one component (because they
> depend on each other)?
> 
> Regards
> Michel
> 
> 
> 
> --
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the Intel
> AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Per User Install Question - Eventlog Message Dll Placement?

[Castro, Edwin G. (Hillsboro)]

I think Christopher was trying to say that you cannot install an event log 
Per-User since it requires access to a Per-Machine registry location. I am not 
aware of Per-User event logs either.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: John Bergman [mailto:john.berg...@xpedienttechnologies.com]
> Sent: Tuesday, December 13, 2011 1:06 PM
> To: chr...@iswix.com; General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Per User Install Question - Eventlog Message Dll
> Placement?
> 
> That's my point.
> 
> My install is Per-User, but I don't want a Per-User placement or registration 
> of
> the Eventlog Resource Dll.  Will the installer just magically handle the
> registration of the eventlog and dll via reference counting?
> 
> -Original Message-
> From: Christopher Painter [mailto:chr...@iswix.com]
> Sent: Tuesday, December 13, 2011 3:00 PM
> To: General discussion for Windows Installer XML toolset.; General discussion
> for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Per User Install Question - Eventlog Message Dll
> Placement?
> 
> 
> 
> I wasn't aware that you could have a per-user event log as the registry
> (HKLM\System\CurrentControlSet\Services\EventLog ) used by the EventLog
> service is in HKLM.  Therefore I don't se how you could have a per-user
> message file.
> 
> 
> Am I missing something?
> 
> 
> 
> From: "John Bergman" 
> 
> Sent: Tuesday, December 13, 2011 2:54 PM
> 
> To: "General discussion for Windows Installer XML toolset."
> 
> 
> Subject: [WiX-users] Per User Install Question - Eventlog Message Dll
> Placement?
> 
> 
> I have a Per-User application and a WiX installer that is working for us
> quite well now.
> 
> 
> I was recently asked to improve our eventlog capabilities by writing to a
> custom eventlog. I have created the message dll, and have it all
> registering correctly using the util:Eventlog utilities method.
> 
> 
> My question is one of placement. Since this is a per-user application,
> where should I place the message dll? It seems wrong that it would be
> placed for each user. Anyone have any guidance on how this should really be
> done?
> 
> 
> Thanks,
> 
> John
> 
> 
> 
> --
> 
> Systems Optimization Self Assessment
> 
> Improve efficiency and utilization of IT resources. Drive out cost and
> 
> improve service delivery. Take 5 minutes to use this Systems Optimization
> 
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> 
> ___
> 
> WiX-users mailing list
> 
> WiX-users@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> --
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and
> improve service delivery. Take 5 minutes to use this Systems Optimization
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> --
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and
> improve service delivery. Take 5 minutes to use this Systems Optimization
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and 
improve service delivery. Take 5 minutes to use this Systems Optimization 
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Need some help on Deferred Custom Actions

[Castro, Edwin G. (Hillsboro)]

From http://msdn.microsoft.com/en-us/library/windows/desktop/aa368268.aspx

A deferred execution custom action must be scheduled in the execute sequence 
table within the section that performs script generation. Deferred execution 
custom actions must come after InstallInitialize and come before 
InstallFinalize in the action sequence.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Robert Hermann [mailto:rob.herm...@nicewareintl.com]
> Sent: Thursday, December 08, 2011 1:20 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Need some help on Deferred Custom Actions
> 
> I've got a deferred custom action  that I need the installer to run after
> "InstallFinalize" as I  need it see a directory...
> 
> Is this possible ???
> 
> Note:  It used to be immediate but I'm trying to get the installer to work 
> with
> UAC ( to get proper elevation) so I'm setting it to Deferred ...
> 
> 
> 
> Rob
> 
> 
> 
> 
> 
> --
> Cloud Services Checklist: Pricing and Packaging Optimization This white paper
> is intended to serve as a reference, checklist and point of discussion for 
> anyone
> considering optimizing the pricing and packaging model of a cloud services
> business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of 
discussion for anyone considering optimizing the pricing and packaging model 
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Conditionally Including CustomActionRefs

[Castro, Edwin G. (Hillsboro)]

Do you mean buildtime? Check the preprocessor conditional statements: 
http://wix.sourceforge.net/manual-wix3/preprocessor.htm

If you really mean runtime, when the package is getting installed, then you 
don't want to think of it as conditionally including a CustomActionRef. In this 
case you want to always include the CustomActionRef and use an appropriate 
condition in the schedule to determine whether it runs or not.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Ian Williams [mailto:iawil...@microsoft.com]
> Sent: Monday, November 21, 2011 4:17 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Conditionally Including CustomActionRefs
> 
> I'm trying to conditionally include some CustomActionRef's based on a property
> at runtime.  I'm on WiX 3.6 beta right now.  I can't figure out how to do 
> this.
> Does anyone know if this is possible?
> 
> Thanks,
> Ian
> 
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity, and more. Splunk takes this data and makes sense of it. 
> IT
> sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] add reference to C++ project

[Castro, Edwin G. (Hillsboro)]

C++ projects in VS2010 are MSBuild style projects so WiX projects will be able 
to reference them fine.

C++ projects in VS2008 are not MSBuild style projects and are not supported as 
WiX project references.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Daniel Madill [mailto:dan.mad...@quanser.com]
> Sent: Friday, November 18, 2011 1:41 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] add reference to C++ project
> 
> I reference C/C++ projects all the time from WiX 3.5 with no problems at all.
> You didn't actually name your project "myC++Project" (i.e. with '+' signs in 
> the
> name) did you?
> 
> Daniel Madill
> 
> -Original Message-
> From: RaoHuiFei [mailto:rhf...@hotmail.com]
> Sent: November-18-11 4:33 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] add reference to C++ project
> 
> 
> I have a VS2008 solution which contains a couple of C++ projects and C#
> projects. Within this solution, a WiX3.5 setup project is created to generate 
> a
> MSI installation package. All the outputs of my C++ projects and C# projects
> need to be added into the installation package. I follow the instruction of
> (http://wix.sourceforge.net/manual-wix3/votive_project_references.htm). It
> works fine with C# projects. However, it does not work with C++ project:
> - After I add reference to a C++ project, its "Full Path" property will show
> "Object reference not set to an instance of an object"
> - If I add a component as shown below, I will get "error CNDL0150: Undefined
> preprocessor variable '$(var.myC++Project.TargetFileName)'"
>
>  Source="$(var.myC++Project.TargetPath)" DiskId="1" />
>   
> 
> 
> I googled this issue and found some 2-years-ago posts saying that referencing
> C++ project with WiX was not supported at that time and will probably be
> supported in the future. However, it look like it is still not supported now. 
> How
> could I add references to C++ projects with WiX?  Thanks.
> 
> 
> 
> 
> --
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> --
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] add reference to C++ project

[Castro, Edwin G. (Hillsboro)]

You still cannot add VS2008 C++ projects as references to WiX projects.

You'll need to either author the WXS manually or use heat to harvest the output 
directory for the C++ project. You can automate heat execution by customizing 
the WiX project file (it is all MSBuild anyway). It may be easier to author the 
WXS manually if you don't have much MSBuild experience or cannot find another 
way to automate heat. Of course, you could use heat to generate a WXS to add to 
your WiX project...

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: RaoHuiFei [mailto:rhf...@hotmail.com]
> Sent: Friday, November 18, 2011 1:33 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] add reference to C++ project
> 
> 
> I have a VS2008 solution which contains a couple of C++ projects and C#
> projects. Within this solution, a WiX3.5 setup project is created to generate 
> a
> MSI installation package. All the outputs of my C++ projects and C# projects
> need to be added into the installation package. I follow the instruction of
> (http://wix.sourceforge.net/manual-wix3/votive_project_references.htm). It
> works fine with C# projects. However, it does not work with C++ project:
> - After I add reference to a C++ project, its "Full Path" property will show
> "Object reference not set to an instance of an object"
> - If I add a component as shown below, I will get "error CNDL0150: Undefined
> preprocessor variable '$(var.myC++Project.TargetFileName)'"
>
>  Source="$(var.myC++Project.TargetPath)" DiskId="1" />
>   
> 
> 
> I googled this issue and found some 2-years-ago posts saying that referencing
> C++ project with WiX was not supported at that time and will probably be
> supported in the future. However, it look like it is still not supported now. 
> How
> could I add references to C++ projects with WiX?  Thanks.
> 
> 
> 
> 
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity, and more. Splunk takes this data and makes sense of it. 
> IT
> sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix or MSI bug ?

[Castro, Edwin G. (Hillsboro)]

I use this type of search in WiX 3.5 successfully but I have not tried to 
confirm its behavior in  WiX 3.6.


  

  


Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Pally Sandher [mailto:pally.sand...@iesve.com]
> Sent: Tuesday, November 08, 2011 2:19 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix or MSI bug ?
> 
> Phil the bug is that the path returned by FileSearch is of the format
> C:\Directory\Filename.ext\ The trailing slash after the filename makes the 
> path
> returned by FileSearch all but useless unless you use a custom action to 
> remove
> it first, in which case you may as well just use a custom action to return the
> correct value in the first place.
> 
> Palbinder Sandher
> Software Platform Engineer
> T:+44 (0) 141 945 8500
> F:+44 (0) 141 945 8501
> http://www.iesve.com
> 
> **Design, Simulate + Innovate with the ** Integrated
> Environmental Solutions Limited. Registered in Scotland No. SC151456
> Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20
> 0SP Email Disclaimer
> 
> 
> -Original Message-
> From: Wilson, Phil [mailto:phil.wil...@invensys.com]
> Sent: 07 November 2011 17:58
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix or MSI bug ?
> 
> And most Windows Installer paths end with a \ too, in the path properties.
> 
> Phil Wilson
> 
> 
> -Original Message-
> From: Pally Sandher [mailto:pally.sand...@iesve.com]
> Sent: Monday, November 07, 2011 6:45 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix or MSI bug ?
> 
> Old bug with FileSearch which has been "closed" but never actually fixed as 
> far
> as I can see ->
> http://sourceforge.net/tracker/?func=detail&atid=642714&aid=1648267&grou
> p_id=105970 &
> http://sourceforge.net/tracker/index.php?func=detail&aid=1273447&group_id=
> 105970&atid=642714
> 
> Palbinder Sandher
> Software Platform Engineer
> T: +44 (0) 141 945 8500
> F: +44 (0) 141 945 8501
> http://www.iesve.com
> 
> **Design, Simulate + Innovate with the **
> Integrated Environmental Solutions Limited. Registered in Scotland No.
> SC151456
> Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20
> 0SP
> Email Disclaimer
> 
> 
> 
> -Original Message-
> From: Nicolas Penin [mailto:n.pe...@happly.fr]
> Sent: 07 November 2011 09:02
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Wix or MSI bug ?
> 
> Dear all,
> 
> I believe this is a bug in wix 3.6, but not sure...
> 
> If I do the following :
> 
>Key="SOFTWARE\Microsoft\Microsoft SQL Server\100\Tools\ClientSetup"
> Type="directory" Name="Path">
> 
>   
> 
> 
> I have the appropriate path, except it is terminating with a \
> 
> If I change the Type of RegistrySearch to file, the content of SQLCMDPATH is
> 'C:\'
> 
> Any idea ?
> 
> Regards,
> Nicolas Penin
> 
> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> 
> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> ___
> 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 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 go to http://www.invensys.com/en/legal/default.aspx.
> 
> 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 

Re: [WiX-users] Ensure that a property is set in setup with UI orunattended setup.

[Castro, Edwin G. (Hillsboro)]

The WiX documentation for the CustomAction element already says what the Error 
attribute is for:

http://wix.sourceforge.net/manual-wix3/wix_xsd_customaction.htm

That page even includes a link to the Custom Action Types page in the Windows 
Installer documentation that describes what a type 19 custom action is:

http://msdn.microsoft.com/library/aa372048.aspx

"Displays a specified error message and returns failure, terminating the 
installation."

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Robert Brunhuber [mailto:w...@rbrunhuber.de]
> Sent: Monday, November 07, 2011 1:44 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Ensure that a property is set in setup with UI
> orunattended setup.
> 
> I'll try this, thank you for your suggestion. Just to understand your example
> shouldn't the InstallExecute Sequence be this way:
> 
> 
> After="FindRelatedProducts">NOT PROPERTYTHATMUSTBESET
> 
> 
> instead of this:
> 
> 
> 
>NOT
> PROPERTYTHATMUSTBESET 
> 
> But I wonder is this request of mine so unusual or why is this not documented 
> in
> any way (neither the wix chm nor the book of Nick Ramirez nor any google
> search I could think of)?
> 
> Am I doing something wrong?
> 
> Thanks,
> 
> Robert
> 
> On 07.11.2011 22:05, Hoover, Jacob wrote:
> > One would think a simple condition within the InstallExecute table
> > could then trigger a custom action.
> >
> > Ex:
> >  > Error="!(loc.LaunchCondition_PropertyNotSet)" />
> >
> > 
> > > After="FindRelatedProducts">NOT PROPERTYTHATMUSTBESET
> > 
> >
> > -Original Message-
> > From: Robert Brunhuber [mailto:w...@rbrunhuber.de]
> > Sent: Monday, November 07, 2011 1:44 PM
> > To:wix-users@lists.sourceforge.net
> > Subject: [WiX-users] Ensure that a property is set in setup with UI
> > orunattended setup.
> >
> > Hi,
> >
> > I have a Wix project, that should create a installer that can be
> > installed either with UI or without UI. So I want to make sure that a
> > property gets set either from the command line or the UI otherwise the
> > installer should abort with a message like "Property PROPRERTYNAME
> > must be set", similar to a launch condition. I searched the web up and
> > down also my searches in the Wix help did not yield anything.
> >
> > I tried to use LaunchCondition but that aborted even before the UI was
> > loaded.
> >
> > Is this possible? If yes, what is the recommended way to do this?
> > I'm using Wix 3.5.
> >
> > Any ideas?
> >
> > Thanks,
> >
> > Robert
> 
> 
> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Get installer final status (return code) from custom action

[Castro, Edwin G. (Hillsboro)]

I don't think you can have the Windows Installer engine report the exit code 
before it exits back to custom actions in a MSI package before the installation 
completes.

If you are trying to get information after the installation completes and you 
have PowerShell v2 available to you then you could try the following command:

Get-EventLog -LogName Application -Source MsiInstaller -Newest 20

Obviously, you'll want to modify (or skip entirely) the -Newest parameter to 
your purposes.

To learn more about the Get-EventLog cmdlet run the following:

Get-Help -Name Get-EventLog -Full

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Wilson, Phil [mailto:phil.wil...@invensys.com]
> Sent: Thursday, October 27, 2011 10:31 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Get installer final status (return code) from custom
> action
> 
> You could write something to monitor or read the Application Event log.
> There are MsiInstaller entries created when a product is installed (and I 
> think
> one for failure too). They seem to be event ID 1033, and there's a
> ProductCode, result and ProductName in the entry.
> 
> Phil Wilson
> 
> -Original Message-
> From: Elanius [mailto:elani...@gmail.com]
> Sent: Thursday, October 27, 2011 4:44 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Get installer final status (return code) from custom
> action
> 
> Hi
> 
> I am working on installer of our product and I got another requirement from
> my beloved product manager.
> 
> So I need collect some statistic about installer and main problem is get final
> return code of installer. It would be simple task if I had some top level
> application which calls installer through MsiInstallProduct but I it is not my
> case. I managed to add Custom Actions on positions -1, -2 and -3 in
> InstallExecuteSequence so I know if installation ends with success, user exit
> or some error.
> 
> But I can not obtain last msi error a mean error code which is normally
> returner by API function MsiInstallProduc. It have to be stored somewhere
> because in this time (sequence -3) is obvious that installer is finishing with
> some error. But question is if it is accessible?
> 
> thanks for any reply,
> elanius.
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn about
> Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> 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 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 go to
> http://www.invensys.com/en/legal/default.aspx.
> 
> 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).
> 
> 
> 
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more r

Re: [WiX-users] "Add/Remove Programs" doesn't refresh sometimes

[Castro, Edwin G. (Hillsboro)]

I can't think of anything I know about the MSI database schema that would 
change ARP/P&F refresh.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: john.burak [mailto:john.bu...@telvent.com]
> Sent: Tuesday, October 25, 2011 10:06 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] "Add/Remove Programs" doesn't refresh
> sometimes
> 
> 
> Edwin G. Castro wrote:
> >
> > ARP/P&F can and does list things that are not MSI products. Could some
> > of those non-MSI products use an external API to perform the wholesale
> > refresh?
> >
> 
> That was the only guess I had.  On closer inspection, I bet Notepad++ isn't
> using Windows Installer.  I guess the question is, is it Windows Installer's 
> fault
> for the inconsistency within my single MSI (one method of uninstall
> refreshes, another doesn't)?  If so, I probably can't fix it per se.  On the 
> other
> hand, if it's something about the MSI file, then maybe I could.
> 
> - John
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/Add-Remove-Programs-doesn-t-refresh-
> sometimes-tp6918973p6929590.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn about
> Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] "Add/Remove Programs" doesn't refresh sometimes

[Castro, Edwin G. (Hillsboro)]

ARP/P&F can and does list things that are not MSI products. Could some of those 
non-MSI products use an external API to perform the wholesale refresh?

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: john.burak [mailto:john.bu...@telvent.com]
> Sent: Tuesday, October 25, 2011 9:03 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] "Add/Remove Programs" doesn't refresh
> sometimes
> 
> 
> Bob Arnson-6 wrote:
> >
> > Nope. ARP/P&F doesn't do a wholesale refresh of the program list for
> > MSI packages. When you click Uninstall and it succeeds, it just
> > deletes that one entry.
> >
> 
> Okay.  I wonder what the difference is between doing an uninstall via the
> usual method and doing an uninstall via "Change > Remove".   I tried a few
> times and the first method triggers refresh and the second doesn't.  It
> sounds like it's not on the MSI side of the wall, so I won't worry about it.
> Just makes me curios.
> 
> Thanks, Bob :)
> 
> - John
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/Add-Remove-Programs-doesn-t-refresh-
> sometimes-tp6918973p6929327.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn about
> Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Fwd: iis website creation fails for windows server 2008R2 with SP1

[Castro, Edwin G. (Hillsboro)]

The services I deploy also get deployed correctly on IIS 7.5 on Windows Server 
2008 R2 SP1.

Perhaps the components for IIS configuration are not getting selected? The 
verbose log would show whether this is the case or not.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: John Cooper [mailto:jocoo...@jackhenry.com]
> Sent: Friday, October 07, 2011 5:58 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Fwd: iis website creation fails for windows server
> 2008R2 with SP1
> 
> The main installer I support creates a web site with several web services and
> is specifically targeted at IIS7.5 and Windows Server 2008R2 including SP1.
> While Wix doesn't support all the configurations I need to do to IIS7.5, the
> ones it does support work fine.
> 
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: Thursday, October 06, 2011 5:24 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Fwd: iis website creation fails for windows server
> 2008R2 with SP1
> 
> David suggested that you check a verbose log. That really should be
> everybody's first step to determining why an install (or uninstall) didn't 
> work
> as expected. Always, always, always check a verbose log first.
> 
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> P Please consider the environment before printing this e-mail
> 
> 
> > -Original Message-
> > From: Bhaumik Barot [mailto:bhaumik...@gmail.com]
> > Sent: Thursday, October 06, 2011 2:57 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Fwd: iis website creation fails for windows
> > server
> > 2008R2 with SP1
> >
> > So I have WIX 3.6 and latest and gratest windows server 2008 r2 sp1
> > with windows updates installed.
> >
> > My installer does not throw any error but it does not create
> > application pool or does not create website.
> >
> > But everything works fine in windows server 2008 R2 . I don't know is
> > it SP1 issue or with my wix.
> >
> > My current version of installer is being used in production for
> > windows server
> > 2008 R2 and so far no issues have come up. But now Microsoft has new
> > SP1 released and I need to support that.
> >
> > Thanks,
> > Bhaumik
> > On Wed, Sep 14, 2011 at 6:49 AM, David Watson 
> wrote:
> >
> > > How is it failing?
> > >
> > > Check a verbose log.
> > >
> > > -Original Message-
> > > From: Bhaumik Barot [mailto:bhaumik...@gmail.com]
> > > Sent: 13 September 2011 19:00
> > > To: wix-users@lists.sourceforge.net
> > > Subject: [WiX-users] Fwd: iis website creation fails for windows
> > > server
> > > 2008R2 with SP1
> > >
> > > -- Forwarded message --
> > > From: Bhaumik Barot 
> > > Date: Tue, Sep 13, 2011 at 12:57 PM
> > > Subject: iis website creation fails for windows server 2008 R2 with
> > > SP1
> > > To: wix-d...@lists.sourceforge.net
> > >
> > >
> > > code works fine with windows server 2008 r2 but fails when I installed
> sp1.
> > > I read the online about some compatibility issue that iis has with new 
> > > SP1.
> > >
> > > I am creating custom app pool and website under that app pool for .net
> 4.0.
> > >
> > > --
> > > Bhaumik
> > >
> > >
> > >
> > > --
> > > Bhaumik Barot
> > >
> > > 
> > > --
> > > ---
> > > -
> > > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn
> > > about the latest advances in developing for the BlackBerry®
> > > mobile platform with sessions, labs & more.
> > > See new tools and technologies. Register for BlackBerry® DevCon
> > today!
> > > http://p.sf.net/sfu/rim-devcon-copy1
> > > ___
> > > 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 intende

Re: [WiX-users] Fwd: iis website creation fails for windows server 2008R2 with SP1

[Castro, Edwin G. (Hillsboro)]

David suggested that you check a verbose log. That really should be everybody's 
first step to determining why an install (or uninstall) didn't work as 
expected. Always, always, always check a verbose log first.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Bhaumik Barot [mailto:bhaumik...@gmail.com]
> Sent: Thursday, October 06, 2011 2:57 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Fwd: iis website creation fails for windows server
> 2008R2 with SP1
> 
> So I have WIX 3.6 and latest and gratest windows server 2008 r2 sp1 with
> windows updates installed.
> 
> My installer does not throw any error but it does not create application pool
> or does not create website.
> 
> But everything works fine in windows server 2008 R2 . I don't know is it SP1
> issue or with my wix.
> 
> My current version of installer is being used in production for windows server
> 2008 R2 and so far no issues have come up. But now Microsoft has new
> SP1 released and I need to support that.
> 
> Thanks,
> Bhaumik
> On Wed, Sep 14, 2011 at 6:49 AM, David Watson  wrote:
> 
> > How is it failing?
> >
> > Check a verbose log.
> >
> > -Original Message-
> > From: Bhaumik Barot [mailto:bhaumik...@gmail.com]
> > Sent: 13 September 2011 19:00
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] Fwd: iis website creation fails for windows
> > server
> > 2008R2 with SP1
> >
> > -- Forwarded message --
> > From: Bhaumik Barot 
> > Date: Tue, Sep 13, 2011 at 12:57 PM
> > Subject: iis website creation fails for windows server 2008 R2 with
> > SP1
> > To: wix-d...@lists.sourceforge.net
> >
> >
> > code works fine with windows server 2008 r2 but fails when I installed sp1.
> > I read the online about some compatibility issue that iis has with new SP1.
> >
> > I am creating custom app pool and website under that app pool for .net 4.0.
> >
> > --
> > Bhaumik
> >
> >
> >
> > --
> > Bhaumik Barot
> >
> > --
> > ---
> > -
> > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn
> > about the latest advances in developing for the BlackBerry® mobile
> > platform with sessions, labs & more.
> > See new tools and technologies. Register for BlackBerry® DevCon
> today!
> > http://p.sf.net/sfu/rim-devcon-copy1
> > ___
> > 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.
> >
> >
> >
> > --
> >  BlackBerry® DevCon Americas, Oct. 18-20, San Francisco,
> > CA Learn about the latest advances in developing for the
> > BlackBerry® mobile platform with sessions, labs & more.
> > See new tools and technologies. Register for BlackBerry® DevCon
> today!
> > http://p.sf.net/sfu/rim-devcon-copy1
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> 
> 
> 
> --
> Bhaumik Barot
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity and more. Splunk takes this data and makes sense of it.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] majorupgrade when signing and merge

[Castro, Edwin G. (Hillsboro)]

Sounds like your original package was per-user. The VC9 merge module very 
likely accesses per-machine locations. That merge module must have required 
that you change the package to per-machine so that it compiled successfully.

If your source control system does not show any other changes then perhaps the 
per-user/per-machine setting wasn't set then WiX might have picked a "smart" 
default based on the contents of the package. I don't know if WiX would really 
do that...

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Martin Kulov [mailto:mar...@kulov.net]
> Sent: Thursday, October 06, 2011 2:55 PM
> To: wix-users
> Subject: Re: [WiX-users] majorupgrade when signing and merge
> 
> 
> So I guess you were right. Here is excerpt of the log: MSI (c) (D8:18)
> [14:49:27:908]: Doing action: FindRelatedProducts MSI (c) (D8:18)
> [14:49:27:908]: Note: 1: 2205 2:  3: ActionText Action 14:49:27:
> FindRelatedProducts. Searching for related applications Action start 14:49:27:
> FindRelatedProducts.
> MSI (c) (D8:18) [14:49:27:908]: FindRelatedProducts: current install is per-
> machine.  Related install for product '{AB5B1162-D4DE-4C59-BAB3-
> 020B2323AF98}' is per-user.  Skipping...
> MSI (c) (D8:18) [14:49:27:908]: FindRelatedProducts: current install is per-
> machine.  Related install for product '{AB5B1162-D4DE-4C59-BAB3-
> 020B2323AF98}' is per-user.  Skipping...
> Action ended 14:49:27: FindRelatedProducts. Return value 1.
> I do not get it why adding an MSM merge module will have any effect on the
> per-machine vs per-user mode. How can I fix it back to per-machine mode?
> Thanks,
> 
> 
> Martin Kulov
> Microsoft Regional Director
> VS ALM MVP, MCT, INETA Speaker
> www.kulov.net | (+359) 88 821 3255
> 
> 
>  > From: phil.wil...@invensys.com
> > To: wix-users@lists.sourceforge.net
> > Date: Thu, 6 Oct 2011 13:17:06 -0400
> > Subject: Re: [WiX-users] majorupgrade when signing and merge
> >
> > Two entries in Add/Remove Programs usually means you tried to upgrade a
> per-system product with a per-user install, or vuice versa (all other things
> being correct to do the upgrade). A verbose log will say something near the
> FindRelatedProducts action.
> 
> >
> > Phil Wilson
> >
> > -Original Message-
> > From: Martin Kulov [mailto:mar...@kulov.net]
> > Sent: Thursday, October 06, 2011 3:59 AM
> > To: John Robbins; wix-users
> > Subject: Re: [WiX-users] majorupgrade when signing and merge
> >
> >
> > So I verified that digitally signing the MSI does NOT break MajorUpgrade
> process and product gets upgraded just fine.Also adding the MSM Merge
> module DOES break MajorUpgrade process.When I add the following two
> lines Merge and MergeRef I end up with two installations of my product:
> 
> > ...
> >  SourceFile="Microsoft_VC90_CRT_x86.msm" DiskId="1" />
> > 
> >  >  Title="$(var.ProductName) Setup"
> >  Level="1"
> >  Display="expand"
> >  Absent="disallow"
> >  AllowAdvertise="no"
> >  ConfigurableDirectory="INSTALLLOCATION" > Id="Microsoft_VC90_CRT_x86" />
> > ...
> > Moving the merge module in another feature does not help
> either. Any ideas? Thanks,Martin
> >
> > > From: mar...@kulov.net
> > > To: j...@wintellect.com; wix-users@lists.sourceforge.net
> > > Date: Thu, 6 Oct 2011 09:58:17 +
> > > Subject: Re: [WiX-users] majorupgrade when signing and merge
> > >
> > >
> > > Hey John,nice to hear from you :) Yes, I did change the Product Id and
> Version. I used to publish 3 more upgrades already. However when I digitally
> signed the MSI, integrated a merge module and changed the Package
> InstallerVersion from 200 to 300 now the upgrade is not recognizing the old
> version. I keep the UpgradeCode the same. I will try adding the changes one
> by one and see what the problem is. Thanks,Martin
> > >
> > >  > From: j...@wintellect.com
> > > > To: wix-users@lists.sourceforge.net; mar...@kulov.net
> > > > Date: Wed, 5 Oct 2011 17:20:29 -0700
> > > > Subject: RE: [WiX-users] majorupgrade when signing and merge
> > > >
> > > > Hi Martin,
> > > >
> > > > Did you change the Product ID and the version number? Both of those
> have to change to be called a major upgrade.
> > > >
> > > > http://wix.sourceforge.net/manual-wix3/major_upgrade.htm shows
> how to integrate a major upgrade into your .WXS file.
> > > >
> > > > John
> > > > Wintellect
> > > > http://www.wintellect.com
> > > > +1-877-968-5528
> > > >
> > > >
> > > > -Original Message-
> > > > From: Martin Kulov [mailto:mar...@kulov.net]
> > > > Sent: Wednesday, October 05, 2011 2:59 PM
> > > > To: wix-users
> > > > Subject: [WiX-users] majorupgrade when signing and merge
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I have an MSI installer built few months ago. It used to work fine 
> > > > during
> MajorUpgrade.
> 

Re: [WiX-users] Heat duplicating components

[Castro, Edwin G. (Hillsboro)]

You want to change the component group id as well (-cg).

I would use command lines like the following:

heat.exe dir manualEN -out manualEN.wxs -cg manualEN -dr manualEN -ag -srd 
-sfrag -var var.ProjectDir
heat.exe dir manualFR -out manualFR.wxs -cg manualFR -dr manualFR -ag -srd 
-sfrag -var var.ProjectDir

Notes:
* Explicitly specify different component group id.
* Explicitly specify different directory ref id.
* Use -ag flag to have GUIDs created at compile time. (I prefer this to -gg -g1)

Explicitly specifying different component group id will cause heat / candle to 
generate different guids. If you use the same component group id then how are 
you supposed to choose one component group from the other?

Explicitly specifying the directory ref id will not root the harvested 
directory under TARGETDIR. You can specify where the directories exist 
explicitly using  elements:


  

  


  

  


I try to let the compiler (candle) generate GUIDs wherever possible.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Caio Monteiro [mailto:cmonte...@modulo.com.br]
> Sent: Monday, September 26, 2011 7:35 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Heat duplicating components
> 
> This is the command line:
> 
> heat.exe dir manualEN -cg manualEN -gg -g1 -sfrag -srd -var "var.ProjectDir" -
> out manualEN.wxs
> 
> I change the dir and the output for the other folder.
> 
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: Monday, September 26, 2011 10:06 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Heat duplicating components
> 
> What are your heat command lines?
> 
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> P Please consider the environment before printing this e-mail
> 
> > -Original Message-
> > From: Caio Monteiro [mailto:cmonte...@modulo.com.br]
> > Sent: Monday, September 26, 2011 7:01 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Heat duplicating components
> >
> > Ok, I figured it out, but still need help. :( What is happening is
> > that although the files are different, the names are the same.
> > So now I only need to discover any way to mass change the xml nodes.
> > Does anyone have a good solution for that?
> >
> > Thanks in advance.
> >
> > -Original Message-
> > From: Caio Monteiro [mailto:cmonte...@modulo.com.br]
> > Sent: Monday, September 26, 2011 6:36 PM
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] Heat duplicating components
> >
> > Hi all,
> >
> > I´m struggling with Heat once more.
> > I´m harvesting two different folders with a lot of files in it.
> > I´ve ran heat twice, but it keeps generating me the same component
> > ids. So I can´t really compile anything.
> >
> > Do you know how I can force it to generate new ids?
> >
> > Regards,
> > Caio
> > --
> >  All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity and more. Splunk takes this data
> > and makes sense of it.
> > Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> > --
> >  All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity and more. Splunk takes this data
> > and makes sense of it.
> > Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> --
> All the data continuously generated in your IT in

Re: [WiX-users] Heat duplicating components

[Castro, Edwin G. (Hillsboro)]

What are your heat command lines?

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Caio Monteiro [mailto:cmonte...@modulo.com.br]
> Sent: Monday, September 26, 2011 7:01 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Heat duplicating components
> 
> Ok, I figured it out, but still need help. :( What is happening is that 
> although
> the files are different, the names are the same.
> So now I only need to discover any way to mass change the xml nodes.
> Does anyone have a good solution for that?
> 
> Thanks in advance.
> 
> -Original Message-
> From: Caio Monteiro [mailto:cmonte...@modulo.com.br]
> Sent: Monday, September 26, 2011 6:36 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Heat duplicating components
> 
> Hi all,
> 
> I´m struggling with Heat once more.
> I´m harvesting two different folders with a lot of files in it.
> I´ve ran heat twice, but it keeps generating me the same component ids. So I
> can´t really compile anything.
> 
> Do you know how I can force it to generate new ids?
> 
> Regards,
> Caio
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity and more. Splunk takes this data and makes sense of it.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity and more. Splunk takes this data and makes sense of it.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Dependency warnings I don't quite get...

[Castro, Edwin G. (Hillsboro)]

Is it possible that the Fragment containing the  is 
not getting referenced from your Product package?

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Mark Modrall [mailto:mmodr...@mzinga.com]
> Sent: Saturday, September 24, 2011 12:07 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Dependency warnings I don't quite get...
> 
> I know that's what the error message description says, but I'm not seeing
> what I'm missing.  In the example below, PTCoreModule is declared as
> described, and all 8 other modules that have a Dependency on it declare that
> dependency as below - yet all 8 are issuing the ICE25 errors.
> 
> I mean, it *looks* like PTCoreModule is declaring the same language and
> version as all the Dependencies, but the errors are coming anyway.
> 
> That's what i don't get...
> 
> Thanks
> Mark
> 
> 
> From: Rob Mensching [r...@robmensching.com]
> Sent: Saturday, September 24, 2011 2:33 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Dependency warnings I don't quite get...
> 
> The Merge Modules you're are pulling in have declared dependencies on
> Merge Modules you have not added to your project.  Or the identifiers are
> not matching correctly.
> 
> On Fri, Sep 23, 2011 at 10:53 AM, Mark Modrall 
> wrote:
> 
> > Hi...
> >
> >I'm getting a bunch of ICE25 warnings about
> > dependencies missing, and I'm not quite getting what I'm doing wrong...
> >
> >To give some examples, I have a merge module with
> >  ...
> >  
> >
> >  There are several other merge modules that have  > RequiredId="PTCoreModule" RequiredLanguage="1033"
> > RequiredVersion="1.0.0.0" />
> >
> >My Product package merges a lot of these modules  > Id="PTCoreModule" Language="1033"
> > SourceFile="..\PTCoreModule\bin\Release\PTCoreModule.msm"
> DiskId="1"
> > />  > SourceFile="..\OtherModule\bin\Release\PTCookiesModule.msm"
> DiskId="1"
> > /> ...
> > 
> >
> > But I'm getting these warnings from every module that has a dependency
> > on
> > PTCoreModule:
> > 23>light.exe(0,0): warning LGHT1076: ICE25: Possible dependency
> > 23>failure as
> > we do not find PTCoreModule@1033 v1.0.0.0 in ModuleSignature table
> >
> >I tried re-ordering the merge list so the main
> > dependencies came first, thinking it might have been a single-pass
> > process that hadn't seen it yet but that didn't help.
> >
> >I'm getting ~20-30 of these warnings for every package
> > built.  Looks like things should be okay, so what am I missing?
> >
> > Thanks
> > Mark
> >
> >
> > --
> >  All of the data generated in your IT infrastructure is
> > seriously valuable.
> > Why? It contains a definitive record of application performance,
> > security threats, fraudulent activity, and more. Splunk takes this
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy2
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> 
> 
> --
> virtually, Rob Mensching - http://RobMensching.com LLC
> --
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> --
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_

Re: [WiX-users] Best way to invoke Wix from a TFS build workflow?

[Castro, Edwin G. (Hillsboro)]

Can somebody send me some links that explain, describe, or document what a 
"Workflow based build" is? This completely new to me and I have to wonder how 
you build a regular C# project using a "Workflow based build"...

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: John Bergman [mailto:john.berg...@xpedienttechnologies.com]
> Sent: Friday, September 23, 2011 10:11 PM
> To: John Robbins; General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Best way to invoke Wix from a TFS build workflow?
>
> John,
>
>I got that, but how would you invoke the build task from a Workflow based
> build, rather than a MSBuild-based build?
>
>You're right, Austin is pretty close.  WE have a pretty big .Net community 
> in
> our area too, not sure why we seem to always get bypassed for anything
> substantial.
>
> John
>
> -Original Message-
> From: John Robbins [mailto:j...@wintellect.com]
> Sent: Saturday, September 24, 2011 12:05 AM
> To: John Bergman; General discussion for Windows Installer XML toolset.
> Subject: RE: [WiX-users] Best way to invoke Wix from a TFS build workflow?
>
> Hi John,
>
> Sorry for the misunderstanding. What my MSBuild files do is pull in
> Microsoft.TeamFoundation.Build.ProcessComponents.dll, which has a bunch
> of MSBuild tasks in it. The key task is GetBuildProperties where you can have
> it set a few properties through OutProperty elements. Here's the relevant
> code:
>
>   
>TaskName="Microsoft.TeamFoundation.Build.Tasks.GetBuildProperties"
>
> AssemblyFile="$(TeamBuildRefPath)\Microsoft.TeamFoundation.Build.Proce
> ssComponents.dll"
>  Condition="'$(WintellectBuildType)'=='TFSBUILD'"/>
>
>   
>  Condition="'$(WintellectBuildType)'=='TFSBUILD'">
>
>  TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
> BuildUri="$(BuildUri)"
> Condition=" '$(IsDesktopBuild)' != 'true' ">
>   
>PropertyName="BuildDefinitionName" />
>/>
> 
> 
>
>   
>
> You can see all of this in action with the Wintellect.TFSBuildNumber.targets
> file in the samples I mentioned below.
>
> Dallas isn't that far away from Austin. Anyway, you needed to get out of the
> office for a few days anyway. :D
>
> Hope it helps!
>
> John
> Wintellect
> http://www.wintellect.com
> +1-877-968-5528
>
>
> -Original Message-
> From: John Bergman [mailto:john.berg...@xpedienttechnologies.com]
> Sent: Friday, September 23, 2011 9:58 PM
> To: John Robbins; General discussion for Windows Installer XML toolset.
> Subject: RE: [WiX-users] Best way to invoke Wix from a TFS build workflow?
>
> No, what I was asking was how do you get the build number out of the TFS
> build server into the files?
>
> You guys need to bring Devscovery to Dallas/Ft. Worth...
>
> -Original Message-
> From: John Robbins [mailto:j...@wintellect.com]
> Sent: Friday, September 23, 2011 4:46 PM
> To: General discussion for Windows Installer XML toolset.; John Bergman
> Subject: RE: [WiX-users] Best way to invoke Wix from a TFS build workflow?
>
> Hi John (Bergman :) )
>
> As I mentioned all my build number stuff is part of your normal C#/VB/C++
> .CS/VB/VCXPROJ files. Once you've edited your project files to create the
> version numbers targets (see the example I included), you'll just tell TFS 
> Build
> to build your solution and the build numbers are automatically created.
>
> Is that what you were asking?
>
> John
> Wintellect
> http://www.wintellect.com
> +1-877-968-5528
>
>
> -Original Message-
> From: John Bergman [mailto:john.berg...@xpedienttechnologies.com]
> Sent: Friday, September 23, 2011 10:16 AM
> To: General discussion for Windows Installer XML toolset.;
> chr...@deploymentengineering.com
> Subject: Re: [WiX-users] Best way to invoke Wix from a TFS build workflow?
>
> John (Robbins),
>
>Hey John, I don't see how the MSBuild items get invoked from a TFS
> Workflow-based build based on the information in your blog;  How do you
> connect the two together?
>
>For others...  John's blog has a link to Jim Lamb's article about how to 
> create
> a custom WorkFlow activity
> (http://blogs.msdn.com/b/jimlamb/archive/2010/02/12/how-to-create-a-
> custom-workflow-activity-for-tfs-build-2010.aspx).
>
> John
>
> -Original Message-
> From: John Robbins [mailto:j...@wintellect.com]
> Sent: Thursday, September 22, 2011 9:01 PM
> To: General discussion for Windows Installer XML toolset.;
> chr...@deploymentengineering.com
> Subject: Re: [WiX-users] Best way to invoke Wix from a TFS build workflow?
>
> Hi,
>
> Just to throw out an alternative way of getting the TFS build number into you
> version data here's how I did it:
>
> http://www.wintellect.com/cs/blogs/jrobbins/archive/2009/11/09/tfs-2010-
> build-number-and-assem

Re: [WiX-users] Best way to invoke Wix from a TFS build workflow?

[Castro, Edwin G. (Hillsboro)]

I have never experienced this scenario because we have an automated deployment 
and smoke test suite that executes immediately after a build. Things that are 
not tested by our automated smoke test are tested by our QA people who test 
installers built by our automated build. They uncover anything that got left 
out that needs to be verified manually.

On the other hand, I have experienced scenarios where files didn't make it into 
the installer because we were harvesting using heat and the harvested project 
changed in a way that it still built successfully but a few files were no 
longer copied to the harvested directory. We unfortunately didn't discover the 
missing files until *after* we released. That was quite embarrassing! QA did 
not discover the missing files because of project management structure, we were 
not testing that part of the product because of the way the project(s) were 
structured... *sigh*.

Anyway, the point is that missing required files are a much bigger problem when 
you harvest because you expect the correct files to be picked up always. You 
tend to forget that the automated process that populates your harvested 
location might change accidentally (just like a human accidentally forgetting 
to update a .wxs file) and then you are stuck in the same place. The risk never 
goes away.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: David Rickard (USA) [mailto:davri...@microsoft.com]
> Sent: Wednesday, September 21, 2011 11:27 AM
> To: chr...@iswix.com; General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Best way to invoke Wix from a TFS build workflow?
> 
> Thanks for the advice.
> 
> Though our devs work with the raw built files and our TFS builds clearly
> identify build breaks. Installer issues (like someone adding a file to the
> solution but forgetting to add it to the installer) would be at risk of going
> unnoticed.
> 
> From: Christopher Painter [mailto:chr...@iswix.com]
> Sent: Wednesday, September 21, 2011 10:48 AM
> To: David Rickard (USA); General discussion for Windows Installer XML
> toolset.
> Subject: RE: [WiX-users] Best way to invoke Wix from a TFS build workflow?
> 
> Open the solution up and click properties on the merge module project.  Go
> to the build events tab then type your command into the pre-build event
> command line.
> 
> I still wouldn't do it though.  This type of dynamic authoring frequently 
> masks
> up stream problems.  What should have been a build break will end up being
> a runtime break.
> 
> 
> From: "David Rickard (USA)"
> mailto:davri...@microsoft.com>>
> Sent: Wednesday, September 21, 2011 12:44 PM
> To:
> "chr...@deploymentengineering.com ng.com>"
> mailto:chrpai@deploymentengineeri
> ng.com>>, "General discussion for Windows Installer XML toolset."  us...@lists.sourceforge.net>
> Subject: RE: [WiX-users] Best way to invoke Wix from a TFS build workflow?
> 
> Alright. In this case how would you run a program to add all the files in a 
> given
> directory to the MSI? Before we had an EXE that generated a merge module
> of files based on a directory. Could this hook in somehow?
> 
> -Original Message-
> From: Christopher Painter
> [mailto:chr...@deploymentengineering.com] mentengineering.com]>
> Sent: Tuesday, September 20, 2011 4:09 PM
> To: General discussion for Windows Installer XML toolset.; wix-
> us...@lists.sourceforge.net
> Subject: Re: [WiX-users] Best way to invoke Wix from a TFS build workflow?
> 
> 
> 
> 
> The simplest way is to use Votive to generate a .SLN / .WIXPROJ and then
> add the sln configuration | platform to to the build parameters in the build
> definition. You shouldn't have to do any customizations in workflow as the
> Default Template will work out of the box. Passing a ProductVersion property
> takes a little bit more work on the msbuild side ( build parameters and
> preprocessor definitions in the wixproj and wixs ) but it doesn't require any
> workflow changes.
> 
> 
> 
> From: "David Rickard (USA)"
> mailto:davri...@microsoft.com>>
> 
> Sent: Tuesday, September 20, 2011 5:11 PM
> 
> To: "wix-users@lists.sourceforge.net us...@lists.sourceforge.net>"  us...@lists.sourceforge.net>
> 
> Subject: [WiX-users] Best way to invoke Wix from a TFS build workflow?
> 
> 
> I need to build some MSIs with Wix during our TFS build. Our current TFS
> build is using the Windows Workflow XAML files to declare the build logic.
> What's the best way to invoke Wix from there? Directly invoking the process
> from an activity? Going down to a powershell

Re: [WiX-users] DirectorySearch/FileSearch not executed if msiexecruns with qb ?

[Castro, Edwin G. (Hillsboro)]

Here's a list of the properties provided by Windows Installer.

http://msdn.microsoft.com/en-us/library/aa370905.aspx

WiX does not include any additional properties by default.

Your selection of extensions (WixNetFxExtension or WixUIExtension for example) 
might add additional properties used by those extensions.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Marc Bauer [mailto:marc@gmx.net]
> Sent: Friday, September 09, 2011 4:25 PM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] DirectorySearch/FileSearch not executed if
> msiexecruns with qb ?
> 
> Hi
> 
> Heck, I found the reason... I copied this code from someone and just used it
> and now in the debugs I see [SOURCEDIR] property is *not* set if /qb is
> used. I switched this variable to [CURRENTDIRECTORY] that seems to exist in
> all cases and DirectorySearch now searches for the File. Setup with /qb
> command line switches now works and copied the file over.
> 
> Is there any documentation that lists all available properties that exists by
> default?
> 
> I'm not yet sure if [CURRENTDIRECTORY] really always exists... from MSI
> debug it looks like it does, but a confirmation from one of the gurus would be
> great.
> 
> PS: Currently the WiX project site hosted at sourceforge is "temporarily
> blocked for exceeding its bandwidth threshold"!???
> 
> 
> Regards
> Marc
> 
> 
> --
> Why Cloud-Based Security and Archiving Make Sense Osterman Research
> conducted this study that outlines how and why cloud computing security
> and archiving is rapidly being adopted across the IT space for its ease of
> implementation, lower cost, and increased reliability. Learn more.
> http://www.accelacomm.com/jaw/sfnl/114/51425301/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT 
space for its ease of implementation, lower cost, and increased 
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX Project Local VS Build vs TFS 2010 Build

[Castro, Edwin G. (Hillsboro)]

TFS Team Build eventually calls MSBuild to perform the build.
Local VS eventually calls MSBuild to perform the build.

You'll want to determine whether there are TFS specific properties that are 
passed to the solution to build (and thus are available in the .wixproj). 
You'll then want to update the .wixproj in question to pass that value as a 
preprocessor constant (DefineConstants) or use the value in some way to define 
a preprocessor constant that you can use in the .wxi.

Perhaps your problem could be solved by using project references.

http://wix.sourceforge.net/manual-wix3/votive_project_references.htm

I find $(var.ProjectName.ProjectDir), $(var.ProjectName.TargetDir), and 
$(var.ProjectName.SolutionDir) particularly useful.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Prabhat Nath [mailto:prabhat.n...@gmail.com]
> Sent: Wednesday, August 17, 2011 11:48 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] WiX Project Local VS Build vs TFS 2010 Build
> 
> Hello,
> 
> 
> 
> I have a WiX Project that has a .wxi file with all variables, where one of the
> variable is the “SourcePath” for all files that are included in MSI.
> 
> Is there a way I can check if the build/compile is done from Local VS or from
> TFS Team Build, so that I can set the path of above variable accordingly?
> 
> 
> 
> Thanks,
> Prabhat Nath
> --
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
> administration capabilities and model configuration. Take the hassle out of
> deploying and managing Subversion and the tools developers use with it.
> http://p.sf.net/sfu/wandisco-d2d-2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Populating a ListBox At Runtime - VB.NET Custom Action Project...

[Castro, Edwin G. (Hillsboro)]

This blog post has a C# example:

http://blog.torresdal.net/2008/10/24/WiXAndDTFUsingACustomActionToListAvailableWebSitesOnIIS.aspx

Here are the relevant pieces:

The ListBox table has these four columns:
  * Property
  * Order
  * Value
  * Text

private static void StoreWebSiteDataInListBoxTable(DirectoryEntry webSite, int 
order, View listBoxView)
{
Record newListBoxRecord = new Record(4);
newListBoxRecord[1] = "WEBSITE";
newListBoxRecord[2] = order;
newListBoxRecord[3] = webSite.Name;
newListBoxRecord[4] = webSite.Properties["ServerComment"].Value;
listBoxView.Modify(ViewModifyMode.InsertTemporary, newListBoxRecord);
}

The listBoxView parameter above is passed this value:

View listBoxView = session.Database.OpenView("select * from ListBox");

Translating this to VB.NET should not be too difficult.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Matt Walker [mailto:mawa...@rcn.com]
> Sent: Monday, August 08, 2011 1:07 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Populating a ListBox At Runtime - VB.NET Custom Action
> Project...
> 
> I don't know if I'm on the right path, but maybe someone can help me.
> I'm
> 
> currently using InstallShield, but have dabbled in WiX a bit.
> 
> I'm trying to creat a custom action using the WiX VB.NET custom action
> 
> project type in VS 2010. Eventually this custom action will query the 
> target
> 
> system for existing web sites by name and populate a combo box for
> 
> selection, but for now, I just have an array of values that I want to 
> shove
> 
> into the listbox just to see that I have working code.
> 
> The associated property on my listbox is WEBSITECHOICES and I know that I
> 
> have to get the choices into the listbox table, but that is where I hit 
> the
> 
> wall. I've tried so much that my head is spinning. Does someone out there
> 
> have a VB.Net code snippet of how to use the Session.OpenView, etc to
> 
> populate this table with my array values?
> 
> 
> 
> --
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-
> attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Need foolproof way to change system path in WIX

[Castro, Edwin G. (Hillsboro)]

The process executing the custom action needs to be restarted after the 
environment variable is modified and before the custom action executes for the 
new environment variable value to be visible to that process.

What process is executing the custom action? My gut says it's either the client 
side or server side Windows Installer process and they are both busy installing 
your MSI package. Sounds like such a change would need require a pre-install 
"installer" to modify the environment variable...

Perhaps a better solution would be to statically link the code to the custom 
action so that you don't need to load the library?

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Brown Boiler [mailto:brown_boi...@yahoo.com]
> Sent: Monday, August 08, 2011 11:54 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Need foolproof way to change system path in WIX
> 
> I am using Wix 4.5 and installing on Windows 7 64 Bit and Windows Server
> 2008 R2 64 bit.
> 
> 
> I am trying to do a LoadLibrary and lineAddProvider from a custom action that
> initiates a C++ method.  Everything works correctly as long as I manually add
> two directories to the system path environment variable and reboot before
> running my MSI.  I manually update the system path using the Environment
> Variables dialog in System...Advanced System Settings.  Obviously this is an
> unacceptable solution for deployment, so I tried to find a way to have WIX
> update the system path for me.
> 
> 
> I have tried numerous ways to get my installer to change the system path so
> that the LoadLibrary and lineAddProvider are successful, but I have not had
> success.  I have tried unsuccessfully in the following ways:
> - Using  Permanent="no" Name="Path" Part="last" System="yes"
> Value="[INSTALLDIR64];[INSTALLDIR]"/>
> - Using a custom routine we have that modifies the path in the registry
> - Using CAQuietExec (running a setx command to modify the path)
> 
> Using the first two methods, I see that the system path indeed was updated
> in the Environment Variable Dialog, but the LoadLibrary still fails.  I even
> created a new feature in my install in which I had the installer update the
> system path, rebooted, and then did a change install on the correct feature
> to try to do the LoadLibrary and lineAddProvider, but I still get the errors.
> 
> So basically I need to find a foolproof way to permanently change the system
> path in an install, even if it requires a reboot in the system.  Anyone have 
> any
> ideas?
> 
> Thanks.
> 
> Adam
> --
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-
> attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Files aren't removed on uninstall

[Castro, Edwin G. (Hillsboro)]

You'll need to generate a verbose log file.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Joe Tilley [mailto:jtil...@fwmurphy.com]
> Sent: Tuesday, August 02, 2011 9:29 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Files aren't removed on uninstall
> 
> Based on the example in the book "WiX: A Developer's Guide To Windows
> Installer XML", I added an Upgrade element along with a launch Condition
> inside my Product element to detect older versions and remove them during
> installation.  That part works wonderfully.  However, when I run the
> uninstallation, only the desktop shortcut is removed.  None of the
> files/folders in Program Files are removed.
> 
> This behavior started after I added the following section of markup:
> 
> 
>   
> 
> 
> 
> 
>Maximum="$(var.ProductVersion)" IncludeMaximum="no"
> OnlyDetect="no" IgnoreRemoveFailure="yes" MigrateFeatures="yes" />
>Minimum="$(var.ProductVersion)" IncludeMinimum="no" OnlyDetect="yes"
> />
> 
> 
> 
> 
>   
> 
> 
> 
> There is probably something I'm doing wrong in there.  The uninstall
> completes with no error.  Any ideas as to what I'm doing wrong?
> 
> Thanks in advance
> _
> 
> Joe Tilley
> 
> FW Murphy
> 
> Software Engineer
> 
> Office
> 
> (918) 317-4130
> 
> Email
> 
> jtil...@fwmurphy.com
> 
> 
> 
> 
> 
> 
> “This message and any attachments may contain FW Murphy
> information that is highly confidential, privileged, and exempt from
> disclosure.  Any recipient other than the intended recipient is advised that
> dissemination, distribution, copying, or other use of this message is strictly
> prohibited.  If you have received this message in error, please notify the
> sender immediately, plus delete the message and any backups.”
> 
> --
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-
> attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5

[Castro, Edwin G. (Hillsboro)]

> >It's a cliché but... I can imagine Rob saying/thinking "Do you know who
> >I am!?" Of course, Rob would never actually say or think anything like
> >that. ;-)
> 
> Well I could say the same about myself and I think most first time visitors to
> WiX could as well. For the most part we're fairly experienced IT people. Being
> new to WiX doesn't make us idiots. And those offering help would be well
> advised to keep that in mind. Also, being new to WiX doesn't mean our
> critiques are necessarily without merit. If it was such a perfect product 
> would
> there be this much email in the WiX-users group?

When you have valid critiques of WiX then we can talk. For Windows Installer 
critiques I would direct you to the Windows Installer team at Microsoft. We 
answer many Windows Installer questions here because it is necessary to 
understand Windows Installer since WiX produced Windows Installer packages. 
Critique the WiX extensions (these represent functionality that is not part of 
Windows Installer) all you want but if we tell you something is a Windows 
Installer issue, then go complain to Microsoft if you don't like it. We are 
living with the same constraints as you and are making it work.

> Your putting words in my mouth. Regarding item 4 I clearly stated that my
> understanding was based on the explanation given in Nick's book and the
> contents of msi log files. If anyone wants to refute these facts then please
> do, these are verifiable facts not my opinions. Please stick to the facts and
> don't create some bogus argument that misrepresents and distorts my
> position. FWIW what Rob said exactly is " Also, I don't think #4 is correct.".
> That is not a strong assertion of fact like "#4 is not correct". Maybe you and
> Rob can remember every nuance of every software project you've ever
> worked on, and good for you if you can, but most of us mere mortals can't.
> So when someone starts a purported correction/refutation with " Also, I
> don't think" it signals that they are reporting something with less than 100%
> certainty. To which a response describing my findings is entirely appropriate.
> Furthermore I qualified my response to make it clear I'm referring to my
> scenario.

I'm commenting about your continued attempt to tell us how Windows Installer 
works. My point is that your evaluation of Windows Installer is incorrect. Many 
of us manage to use Component and Feature conditions successfully but you were 
not. Your expectations are flawed or incomplete. Can you be certain that your 
experiments were valid to begin with? They would not be if you were not doing 
things properly according to Windows Installer.

I'm convinced that the "simple" Windows Installer solution didn't work for you 
because you implemented it incorrectly. Instead of trying to get help on that 
you decided to try to bypass Windows Installer and force it to do something 
bad. Then you continued to get lots of errors. When we tell you that you should 
do try the "simple" Windows Installer solution you responded with "WiX doesn't 
work like that" style comments and flat out refused to listen to us. I'm not 
putting words in your mouth. I'm simply commenting on your behavior (I had to 
go look at the archives to see all of your messages).

I repeatedly tried to educate you on WiX and its relationship to Windows 
Installer and you essentially said "well, that's stupid, I still want to blame 
WiX for my woes, don't tell me who I should blame". This type of behavior makes 
most people on this mailing list silent very quickly. As I said before, it is 
very clear, based on your messages, that your experience with Windows Installer 
and with WiX is very low. Instead of telling us we are wrong you should stand 
back and try to figure out if perhaps you are doing something wrong that 
resulted in the behavior you are seeing. As I said earlier, Windows Installer 
requires a "my way or the highway" style of development. You need to do things 
the Windows Installer way. I would be perfectly willing to help you learn what 
the Windows Installer way is but don't tell me that Windows Installer doesn't 
work the way it should and don't tell me that it's WiX's fault when it isn't.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5

[Castro, Edwin G. (Hillsboro)]

> > Maybe it just requires looking at the problem from a different point of
> view. Trying to be very procedural tends to be very frustrating in a
> declarative system. You end up fighting the design constantly. I'm still not
> terribly clear >on your requirements but what you've described thus far
> seems like it should be pretty easy to do with the Windows Installer, with the
> right approach.
> 
> Rob, there are multiple sequences involved. With coordination between
> sequences and dependencies between nodes within the same sequence.
> One cannot help dealing with this procedurally. Nick's book makes it pretty
> clear that these sequences require close attention.
> 
> > Also, I don't think #4 is correct. Costing will be applied to Components
> which then roll up into Feature costing. As you turn Features on and off, the
> costing will be adjusted.
> 
> If features were specified at installer invocation time or in a dialog early 
> in the
> UI sequence you would be correct. But they are not. As I explained they are
> being determined in a dialog that runs after CostFinalize.
> 

It's a cliché but... I can imagine Rob saying/thinking "Do you know who I am!?" 
Of course, Rob would never actually say or think anything like that. ;-)

I generally take what Rob says as gospel. He did work with the Windows 
Installer team as an intern and has been authoring Windows Installer packages 
for a very, very long time. Essentially since the beginning of Windows 
Installer packages. You should consider twice before you tell Rob how Windows 
Installer works. And considering that Rob started WiX as a tool to help author 
Windows Installer packages I am very comfortable with his understanding of how 
WiX relates to Windows Installer and how to use WiX to author Windows Installer 
packages.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5

[Castro, Edwin G. (Hillsboro)]

I have plenty of experience with declarative configuration/installation as I've
> spent years working with application servers not to mention .NET with its
> bevvy of config files for everything.
> 

But do you have any experience with Windows Installer? The posts you have made 
to the wix-users mailing list suggests you do not. In my experience, all 
_scripted_ deployment approaches developed for .NET that do not use Windows 
Installer are, in fact, procedural and not declarative. This is just not how 
Windows Installer works.

> > The Windows Installer (as Edwin noted) provides UI design you are critical
> of, not the WiX toolset.
> 
> I'm sorry, but that's just passing the buck. You're essentially blaming user
> difficulties with WiX on what lies underneath. If WiX can't make these
> problems go away or at least make them reasonably manageable then what
> is the point? What is the motivation for me or anybody else to use it if the
> difficulties that need to be dealt with are as bad or worse than the
> alternatives that don't involve WiX?? You do understand that many of us that
> are taking a first time look at WiX are not hobbyists with a lot of time on 
> our
> hands, but professionals facing real world job pressures like deadlines?
>

This is very much not passing the buck! Your lack of understanding of Windows 
Installer is severely impacting your point of view. I would urge you to read 
through the Windows Installer SDK documentation and attempt to author an MSI 
package using the tools available in the Windows Installer SDK. Perhaps you 
should take the time to fully understand the tool you are using for authoring 
MSI packages (WiX) before you start making comments about how useful it is or 
is not. Finally, you are perfectly welcome to not use WiX to author your MSI 
package. If you do decide to use a different tool and that tool produces a MSI 
package, then I would be interested in finding out how that tool gets Windows 
Installer to do what you want to do. A Windows Installer solution will be 
implemented similarly (generally speaking) regardless the tool used to produce 
the MSI package.

You really have a problem with how Windows Installer works (not WiX). Honestly, 
you should consider switching to something that does not produce Windows 
Installer packages (.msi). NSIS is but one option. If you have a requirement 
that says you *must* produce a Windows Installer package (.msi) then I'm afraid 
you are going to need to learn Windows Installer whether you like it or not.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5

[Castro, Edwin G. (Hillsboro)]

Found this 
http://www.indigorose.com/webhelp/sufwi/HowTo/Control_Feature_Installation_Using_a_CheckBox.htm

You would need to translate it to WiX. I can imagine that a similar technique 
could be used to control feature installation using radio buttons.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: Thursday, July 28, 2011 5:10 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5
> 
> > > By now it should be clear what I'm trying to do. A feature dialog is
> > > being executed *after* CostFinalize and therefore *before*
> > > ExecuteAction. This dialog determines the set of features to be
> > > installed. But the actual installation ignores this information. I
> > > know why, because it needs to be available *before* CostFinalize
> > > (see description). But in order to make it available *before* the
> > > dialog chain would need to be moved up in the sequence, something
> > > that can't happen because of the DM dependency (and possibly
> > > others). I think this
> > pretty clearly sums it up.
> 
> Here's something to think about. The feature selection dialog executes after
> CostFinalize and yet we can configure Directory paths based on user input
> that occurs after CostFinalize. I have to wonder what you are trying to do
> (other than run your UI dialogs too early) that might cause problems. I have
> to assume that you tried it the normal way first and it didn't work as you
> expected because what you expected did not match the way Windows
> Installer works.
> 
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> P Please consider the environment before printing this e-mail
> 
> 
> --
> Got Input?   Slashdot Needs You.
> Take our quick survey online.  Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5

[Castro, Edwin G. (Hillsboro)]

> > By now it should be clear what I'm trying to do. A feature dialog is
> > being executed *after* CostFinalize and therefore *before*
> > ExecuteAction. This dialog determines the set of features to be
> > installed. But the actual installation ignores this information. I
> > know why, because it needs to be available *before* CostFinalize (see
> > description). But in order to make it available *before* the dialog
> > chain would need to be moved up in the sequence, something that can't
> > happen because of the DM dependency (and possibly others). I think this
> pretty clearly sums it up.

Here's something to think about. The feature selection dialog executes after 
CostFinalize and yet we can configure Directory paths based on user input that 
occurs after CostFinalize. I have to wonder what you are trying to do (other 
than run your UI dialogs too early) that might cause problems. I have to assume 
that you tried it the normal way first and it didn't work as you expected 
because what you expected did not match the way Windows Installer works.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5

[Castro, Edwin G. (Hillsboro)]

> -Original Message-
> From: Peter Stein [mailto:pst...@instec-corp.com]
> Sent: Thursday, July 28, 2011 4:14 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5
> 
> Not sure why this is so difficult to understand. The installer has components
> that are safe to install in some environments/contexts but not in others. Yes,
> the installer could be decomposed into multiple installers each of which only
> installs a single feature but that's just plain goofy as the users have the
> wherewithal to know which feature is appropriate for their install. As a 
> safety
> precaution we simply don't want unneeded executables installed when they
> don't need to be because the individuals using the software aren't
> necessarily the same ones who installed it. You're misinterpreting something
> fairly straightforward because you are looking at it through the filter of 
> WiX.
> 

There is no WiX filter here. I don't think we were discussing having multiple 
packages at all... We were talking about feature/component composition within a 
single package. This is strictly a Windows Installer concept that WiX (not the 
same thing) allows you to define using a XML syntax. WiX doesn't set the rules 
here. Windows Installer sets the rules. Now, if you are trying to say that I 
have a Windows Installer filter on then, yes, you are correct and I would argue 
that's appropriate since you are trying to author a Windows Installer package!

To see what the Windows Installer SDK (not WiX) has to say about 
feature/component composition see 
http://msdn.microsoft.com/en-us/library/aa370561.aspx

> And no, I'm not using a directory path too early. NO, NO, NO!
> In fact the problem is the exact opposite I can't use it early enough. I 
> clearly
> said "after CostFinalize" because only then is the DM initialized. I want to
> move the whole dialog chain towards the front of the InstallUISequence as
> far as it can go, but there are dependencies on the standard UI actions.
> 

You would not be getting DM uninitialized errors if you were not trying to use 
the directory paths before they are available. Again, this is how Windows 
Installer works. WiX does not have anything to do with this.

> By now it should be clear what I'm trying to do. A feature dialog is being
> executed *after* CostFinalize and therefore *before* ExecuteAction. This
> dialog determines the set of features to be installed. But the actual
> installation ignores this information. I know why, because it needs to be
> available *before* CostFinalize (see description). But in order to make it
> available *before* the dialog chain would need to be moved up in the
> sequence, something that can't happen because of the DM dependency
> (and possibly others). I think this pretty clearly sums it up.
> 

Sounds like you are trying to setup an execution sequence that doesn't work. 
See http://msdn.microsoft.com/en-us/library/aa372039.aspx for the Windows 
Installer SDK's (not WiX) suggestion for a base InstallUISequence.  The table 
in that page tells me that you are trying to author something that won't work.

> I'm not trying to sabotage anything, just trying to use a tool to do something
> *very* reasonable. WiX doesn't seem to have the correct coupling between
> the UI and control logic. Or the user documentation that explains how to
> achieve that. Or both. Even a new CS grad knows that you don't start
> processing inputs before the connected UI has even served them up!
>

Actually, that previous paragraph is the exact definition of sabotage. Windows 
Installer (not WiX) says that directory paths are not available until after 
CostFinalize (http://msdn.microsoft.com/en-us/library/aa368048.aspx). Windows 
Installer (not WiX) suggests that all of your UI dialogs execute *after* 
CostFinalize. You (not WiX) are trying to change the InstallUISequence to 
something that makes more sense to you but does not take into consideration how 
the Windows Installer engine works (again, not WiX).

Your definition of reasonable doesn't matter if it contradicts the framework 
you are trying to use, for better or for worse. Windows Installer (not WiX) 
works a particular way and I have found that it works really well if you don't 
do anything to upset it. I would say that you are doing a lot to upset it and 
Windows Installer (not WiX) is complaining heavily.

WiX (Windows Installer XML) is a XML syntax for defining Windows Installer 
packages that are consumed by the Windows Installer engine. WiX does not have 
the ability to change Windows Installer no more than InstallShield can. There 
are some setup authoring tools that do not use Windows Installer at all! NSIS 
is an example that comes to mind immediately. If you are going to use WiX as 
your setup authoring tool then you must follow the rules set by Windows 
Installer.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503

Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5

[Castro, Edwin G. (Hillsboro)]

> Yes it does because there are installation scenarios where having the
> superset installed is potentially dangerous.

So, a user could still select the superset (exclusively) and still end up in a 
"potentially dangerous" scenario... I don't think mutually exclusive options 
help you here. Detecting the potentially dangerous scenario before the feature 
selection dialog and hiding the superset feature might help. My point is if 
somebody has to make the choice to select the superset, then does it matter if 
they also select the subset? They have already selected the superset which 
includes the subset... why restrict them from selecting the subset in addition 
to the superset? In all scenarios they can choose only the subset (or none) 
which is safer, presumably.

> " How exactly do you depend on Directory Manager?"
>
> I don't know, but I do know that if I ignore it I'll be spending time on 2732
> errors. Obviously the dependency has something to do with one of the
> dialogs, most likely the "choose installation directory" dialog.

This means you are trying to use the path of a Directory in your package too 
early... (as you identified, before CostFinalize). This is the type of 
dependency I'm talking about. Clearly you are trying to accomplish something at 
the wrong point in time. But we don't have enough context to help you figure 
out what is the appropriate point in time to do it.

> I am not "using it" at all, I'm getting blindsided by it. Until I encountered 
> the
> first 2732 error I didn't even know that a Directory Manager was in play. 
> Like I
> said "realm of the practical" . I don't have months to spend on contortions
> that might get this to work.

"Realm of practical" to me translates into "do things the Windows Installer 
way". Note that I didn't say "WiX way" and there's a very good reason for that.

You *will* spend months trying to accomplish something that actively tries to 
sabotage how Windows Installer works, but that's your choice.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Peter Stein [mailto:pst...@instec-corp.com]
> Sent: Thursday, July 28, 2011 2:37 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5
>
> " Why must you model the features with an exclusive mode."
> " I mean, does it really hurt anything (or confuse anybody) if both features
> are selected?"
>
> Yes it does because there are installation scenarios where having the
> superset installed is potentially dangerous.
>
> " How exactly do you depend on Directory Manager?"
>
> I don't know, but I do know that if I ignore it I'll be spending time on 2732
> errors. Obviously the dependency has something to do with one of the
> dialogs, most likely the "choose installation directory" dialog.
>
> " Perhaps that dependency can be managed differently than how you are
> currently using it."
>
> I am not "using it" at all, I'm getting blindsided by it. Until I encountered 
> the
> first 2732 error I didn't even know that a Directory Manager was in play. 
> Like I
> said "realm of the practical" . I don't have months to spend on contortions
> that might get this to work.
>
>
>
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: Thursday, July 28, 2011 4:07 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5
>
> Why must you model the features with an exclusive mode. That's part of
> your problem. Let go of that requirement and let Windows Installer do most
> of the heavy lifting for you. You said there's a subset/superset relationship
> that can be directly modeled using Feature composition. Use that and make
> your life easier.
>
> I mean, does it really hurt anything (or confuse anybody) if both features are
> selected? Hmm... If having both features selected (in the feature selection
> dialog) doesn't confuse anybody (use good feature title/description) then
> you can avoid feature composition and simply use Rob's recommendation:
>
> FeatureA {
> ComponentA
> ComponentB
> }
> FeatureB {
> ComponentA
> ComponentB
> ComponentC
> ComponentD
> }
>
> How exactly do you depend on Directory Manager? Perhaps that
> dependency can be managed diff

Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5

[Castro, Edwin G. (Hillsboro)]

Why must you model the features with an exclusive mode. That's part of your 
problem. Let go of that requirement and let Windows Installer do most of the 
heavy lifting for you. You said there's a subset/superset relationship that can 
be directly modeled using Feature composition. Use that and make your life 
easier.

I mean, does it really hurt anything (or confuse anybody) if both features are 
selected? Hmm... If having both features selected (in the feature selection 
dialog) doesn't confuse anybody (use good feature title/description) then you 
can avoid feature composition and simply use Rob's recommendation:

FeatureA {
ComponentA
ComponentB
}
FeatureB {
ComponentA
ComponentB
ComponentC
ComponentD
}

How exactly do you depend on Directory Manager? Perhaps that dependency can be 
managed differently than how you are currently using it. The Feature table 
already has a column (Directory_) for configuring a directory in the feature 
selection dialog. See the ConfigurableDirectory attribute of the Feature 
element. I think one of the WixUI dialog sets includes a feature selection 
dialog that lets you configure directories...

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Peter Stein [mailto:pst...@instec-corp.com]
> Sent: Thursday, July 28, 2011 1:02 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5
>
> I don't understand all of your explanation starting with "The key here...".
>
> I get what you are saying about the nesting of the features. I was already
> aware of that as I have the book by Nick Ramirez.
>
> However that does not solve the problem. The user still needs to select
> either FeatureA or FeatureB. That takes place via a dialog. Whether that
> dialog is standard or custom doesn't matter, it is part of a chain of dialogs.
> That chain has one or more dialogs which require the Directory Manager. The
> Directory Manager is not initialized until after CostFinalize in the
> InstallUISequence. That forces the dialog display to occur between
> CostFinalize and ExecuteAction. *BUT* selected features must already be
> identified before CostFinalize. And that cannot happen with my dialogs
> because they haven't run yet! Remember, my dialog chain has a dependency
> on DM (and it very well could have other dependencies that won't be
> exposed until an attempt to re-sequence InstallUISequence).
>
> So I don't understand what you mean by "you don't need a separate dialog
> to select the features thus getting feature selection to occur at the correct
> time". A basic design requirement for this installer is to be user friendly 
> and
> consistent with other installers that acquire configuration info via dialogs. 
> So I
> can't get rid of the feature dialog.
>
> Here are the pertinent facts as I see them and how they apply to this
> problem. This is based on the information available to me and I could very
> well be wrong on any of these (working with WiX isn't exactly a confidence
> boosting exercise). If you see one that is wrong and/or presents an
> opportunity for solving the problem please identify it and the possible
> solution approach. Please confine possible solutions to the realm of the
> practical. I've spent far too much time on this already and can't afford to 
> take
> a year long sabbatical to redesign WiX. Thanks.
>
> 1.  I cannot avoid having a feature dialog. The installer must ask the user 
> what
> features are wanted.
> 2. That dialog must be part of the dialog chain. Dialogs must be contiguous
> with no standard UI actions between.
> 3. The dialog chain has one or more dependencies on earlier standard UI
> actions in the InstallUISequence.
> 4. Feature selection must have been made and be available at the time of
> CostFinalize.
>
>
>
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: Thursday, July 28, 2011 2:02 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5
>
> Suppose you have the following components:
> * ComponentA
> * ComponentB
> * ComponentC
> * ComponentD
>
> Suppose that we want FeatureA (subset) to install only ComponentA and
> ComponentB.
> Suppose that we want FeatureB (superset) to install everything in FeatureA
> *and* ComponentC and ComponentD.
>
> FeatureB {
> ComponentC
> ComponentD
> FeatureA {
> Componen

Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5

[Castro, Edwin G. (Hillsboro)]

Suppose you have the following components:
* ComponentA
* ComponentB
* ComponentC
* ComponentD

Suppose that we want FeatureA (subset) to install only ComponentA and 
ComponentB.
Suppose that we want FeatureB (superset) to install everything in FeatureA 
*and* ComponentC and ComponentD.

FeatureB {
ComponentC
ComponentD
FeatureA {
ComponentA
ComponentB
}
}

The key here is to set FeatureA to follow the parent feature (FeatureB). Now in 
the standard feature selection dialog a user can select only FeatureA _or_ they 
can select FeatureB which automatically selects FeatureA. With this approach 
you don't need a separate dialog to select the features thus getting feature 
selection to occur at the correct time.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Thursday, July 28, 2011 11:40 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5
> 
> Is it possible to organize your Components so that one Feature has most
> Components and the other Feature has less Components? A Component can
> be installed by two Features.  Maybe I'm misunderstanding.
> 
> BTW, deleting files that the Windows Installer thinks should be installed is a
> *very bad* design. You'll end up in an immediate "repair" state that has real
> potential of creating problems for you all over the place later.
> 
> ...or maybe I just don't really understand the scenario.
> 
> On Thu, Jul 28, 2011 at 7:44 AM, Peter Stein 
> wrote:
> 
> > I'm not attempting to upgrade anything. I'm trying to use this
> > mechanism to solve a problem with feature set installation (which I
> > described in another email).
> >
> > Basically my installer users can choose between 2 features in a
> > dialog. The problem is that the dialog choice is not available at the
> > time of CostFinalize and it doesn't seem possible to re-sequence the
> > UI standard actions. So simply modifying ADDLOCAL does not work.
> >
> > The relationship between these 2 features is that one is a subset of
> > the other. So two possible strategies may work: 1. Install the subset
> > and possibly add the other files, OR 2. Install the superset and subtract 
> > (i.e.
> > remove files). When I discovered the post that contained "RemoveFiles"
> > I was hopeful that usage of  "Remove" elements might lend itself
> > towards a solution based on the 2nd strategy. But based on your email
> > I appear to be barking up the wrong tree.
> >
> > It looks like it will be necessary to resort to a very ugly kludge,
> > namely including a helper exe in the installer that will remove the
> unwanted files.
> >
> > -Original Message-
> > From: Wilson, Phil [mailto:phil.wil...@invensys.com]
> > Sent: Wednesday, July 27, 2011 7:10 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5
> >
> > There's a lot of other stuff that needs doing for upgrades to work,
> > and you haven't said if you actually have it, such as upgrade
> > specifications in your WiX.
> >
> > I'd look at all your FindRelatedProducts actions in your install to
> > see if they report anything about finding older versions of your product.
> >
> > It's also not obvious that this is a solution to your problem,
> > whatever it is. During an upgrade the state of files being installed
> > or removed is about whether they have the same component guids or not.
> > In the scenario where RemoveExistingProducts after InstallFinalize
> > works, look at it something like this as a general flow guide:
> >
> > Every file in your original install has a guid associated with it.
> >
> > All the files in your upgrade where you want to replace the old file
> > with your new file need the same component guid.
> >
> > The upgrade install runs. Every file gets replaced, based on file
> > version rules where applicable.  Where the component guids are
> > identical the ref count on that guid increments from 1 to 2.
> >
> > At the end the RemoveExistingProducts runs. It will look at each
> > file's guid and decrement the ref count. If it goes from 2 to 1 the
> > file will not be removed (it's in use by the product you just
> > installed). If the ref count on a guid goes down to zero then nothing is 
> > using
> it. So it gets removed.
> >
> > If you don't want filexyz.exe in the product then just don't put it in
> > your upgrade. Once you get the upgrade really working with
> > RemoveExistingProducts, if it's not being removed then something else
> > is going on (clobbered ref counts, marked permanent etc).
> >
> > Phil Wilson
> >
> >
> > -Original Message-
> > From: Peter Stein [mailto:pst...@instec-corp.com]
> > Sent: Wednesday, July 27, 2011

[WiX-users] DTF Equivalent of /l*v

[Castro, Edwin G. (Hillsboro)]

I'm building a bootstrapper using DTF. I'd like to set the messageFilter to 
Installer.SetExternalUI() to be equivalent to the msiexec /l*v logging option 
but I can't quite figure out which combination of InstallLogModes values to 
use. At one point, I had nearly all values but I didn't see messages in my 
external UI handler for some of the messages I see in a msiexec /l*v log.

Here's an example:

InstallLogModes messageFilter =
InstallLogModes.Error |
InstallLogModes.Info |
InstallLogModes.Warning |
InstallLogModes.Verbose |
InstallLogModes.ActionStart |
InstallLogModes.ActionData |
InstallLogModes.CommonData |
InstallLogModes.PropertyDump |
InstallLogModes.FilesInUse |
InstallLogModes.RMFilesInUse |
InstallLogModes.OutOfDiskSpace |
InstallLogModes.ExtraDebug |
InstallLogModes.User |
InstallLogModes.Progress |
InstallLogModes.Initialize |
InstallLogModes.ResolveSource |
InstallLogModes.ShowDialog |
InstallLogModes.Terminate |
//InstallLogModes.LogOnlyOnError |
//InstallLogModes.None |
InstallLogModes.FatalExit;

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
P Please consider the environment before printing this e-mail

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Off Topic - MSI Setup Jobs EMail List?

[Castro, Edwin G. (Hillsboro)]

> Should we create a "wix-jobs" list?

+1

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Can an x86 msi create a registry key under HKEY_CLASSES_ROOT\Wow6432Node on x64 systems?

[Castro, Edwin G. (Hillsboro)]

You already have enough information. You need to check the what kind of package 
it is (check the Summary Information Stream). It is easy for anybody with 
administrative privileges to create HKLM:\SOFTWARE\Wow6432Node, even on an 
32-bit system.

That said, I think you are looking in the wrong place. HKEY_CLASSES_ROOT maps 
to HKEY_LOCAL_MACHINE\SOFTWARE\Classes. So to find your 32-bit registry entries 
for HKEY_CLASSES_ROOT you should be looking at 
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Wang, Miaohsi [mailto:miaohsi.w...@invensys.com]
> Sent: Thursday, June 30, 2011 2:18 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Can an x86 msi create a registry key under
> HKEY_CLASSES_ROOT\Wow6432Node on x64 systems?
> 
> Hi Edwin,
> 
> 1. This is an x86 installer because it works on both x86 and x64 machines.
> 2. I was viewing the Registry on a x64 machine using Regedit.exe, and inside
> the Registry I could see HKLM\SOFTWARE\Wow6432Node. Is this enough to
> say that I was viewing the Registry using a 64-bit process?
> 
> Given the above information, could you please let me know where in the msi
> to start troubleshooting the problem?
> 
> Thanks a lot,
> Miaohsi
> 
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: Thursday, June 30, 2011 12:30 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Can an x86 msi create a registry key under
> HKEY_CLASSES_ROOT\Wow6432Node on x64 systems?
> 
> Are you certain you are creating an x86 msi package?
> 
> Are you using a 32-bit process to view the contents of the registry? If yes,
> then the location looks exactly as it should.
> 
> If you are certain that you are using a 64-bit process to view the contents of
> the registry then I would revisit the bitness of the msi package itself.
> 
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> P Please consider the environment before printing this e-mail
> 
> > -Original Message-
> > From: Wang, Miaohsi [mailto:miaohsi.w...@invensys.com]
> > Sent: Thursday, June 30, 2011 11:08 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Can an x86 msi create a registry key under
> > HKEY_CLASSES_ROOT\Wow6432Node on x64 systems?
> >
> > Hi David,
> >
> > Thank you for the information. Below is my component definition:
> >
> > 
> >> Action="createAndRemoveOnUninstall" />
> >> Root="HKLM" Action="createAndRemoveOnUninstall" /> 
> >
> > As you can see Registry1 is targeted for HKCR and Registry2 for HKLM.
> > As a result of the installation, "RTServerRM_6.0" is created right
> > under HKCR and the same key is also created right under
> > HKLM\Software\Classes, not under
> HKLM\Software\Classes\Wow6432Node as desired.
> >
> > Your help will be greatly appreciated.
> >
> > Thanks,
> > Miaohsi
> >
> > -Original Message-
> > From: David Watson [mailto:dwat...@sdl.com]
> > Sent: Thursday, June 30, 2011 10:01 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Can an x86 msi create a registry key under
> > HKEY_CLASSES_ROOT\Wow6432Node on x64 systems?
> >
> > 32 bit (x86) installers can indeed write to wow6432nodes and do so by
> > by default.
> >
> > Specify the key you wish to write to and omit Wow6432Node as they will
> > be redirected there automatically.
> > http://wix.sourceforge.net/manual-wix3/write_a_registry_entry.htm
> >
> > Its also worth noting that Microsoft say it is bad form to actually
> > write to HKCR directly (its behaviour depends on the environment) so
> > for per machine installs you should install to HKLM\Software\Classes
> > and HKCU\Software\Classes for per user installs.
> >
> > http://msdn.microsoft.com/en-us/library/ms724475(VS.85).aspx
> >
> >
> >
> > -Original Message-
> > From: Wang, Miaohsi [mailto:miaohsi.w...@invensys.com]
> > Sent: 30 June 2011 16:35
> > To: General discussion for Windows Installer XML toolset.
> > Subject: [WiX-users] Can an x86 msi create a registry key under
> > HKEY_CLASSES_ROOT\Wow6432Node on x64 systems?
> >
> > 

Re: [WiX-users] Can an x86 msi create a registry key under HKEY_CLASSES_ROOT\Wow6432Node on x64 systems?

[Castro, Edwin G. (Hillsboro)]

Are you certain you are creating an x86 msi package?

Are you using a 32-bit process to view the contents of the registry? If yes, 
then the location looks exactly as it should.

If you are certain that you are using a 64-bit process to view the contents of 
the registry then I would revisit the bitness of the msi package itself.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Wang, Miaohsi [mailto:miaohsi.w...@invensys.com]
> Sent: Thursday, June 30, 2011 11:08 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Can an x86 msi create a registry key under
> HKEY_CLASSES_ROOT\Wow6432Node on x64 systems?
> 
> Hi David,
> 
> Thank you for the information. Below is my component definition:
> 
> 
>Action="createAndRemoveOnUninstall" />
>Root="HKLM" Action="createAndRemoveOnUninstall" /> 
> 
> As you can see Registry1 is targeted for HKCR and Registry2 for HKLM. As a
> result of the installation, "RTServerRM_6.0" is created right under HKCR and
> the same key is also created right under HKLM\Software\Classes, not under
> HKLM\Software\Classes\Wow6432Node as desired.
> 
> Your help will be greatly appreciated.
> 
> Thanks,
> Miaohsi
> 
> -Original Message-
> From: David Watson [mailto:dwat...@sdl.com]
> Sent: Thursday, June 30, 2011 10:01 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Can an x86 msi create a registry key under
> HKEY_CLASSES_ROOT\Wow6432Node on x64 systems?
> 
> 32 bit (x86) installers can indeed write to wow6432nodes and do so by by
> default.
> 
> Specify the key you wish to write to and omit Wow6432Node as they will be
> redirected there automatically.
> http://wix.sourceforge.net/manual-wix3/write_a_registry_entry.htm
> 
> Its also worth noting that Microsoft say it is bad form to actually write to
> HKCR directly (its behaviour depends on the environment) so for per
> machine installs you should install to HKLM\Software\Classes and
> HKCU\Software\Classes for per user installs.
> 
> http://msdn.microsoft.com/en-us/library/ms724475(VS.85).aspx
> 
> 
> 
> -Original Message-
> From: Wang, Miaohsi [mailto:miaohsi.w...@invensys.com]
> Sent: 30 June 2011 16:35
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Can an x86 msi create a registry key under
> HKEY_CLASSES_ROOT\Wow6432Node on x64 systems?
> 
> Dear All,
> 
> I have an x86 installer which needs to create a registry key under
> HKEY_CLASSES_ROOT\Wow6432Node on 64-bit machines. I created a
> component to do the task. The component installs fine but does not create
> the key on x64 systems. Is there a way to accomplish this with WiX? Your help
> will be greatly appreciated.
> 
> Thanks a lot,
> 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 go to
> http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&pr
> ev_id=77.
> 
> 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).
> 
> -
> -
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> ___
> 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

Re: [WiX-users] How do you share dll's between executabled files

[Castro, Edwin G. (Hillsboro)]

I agree this is very much a .NET issue rather than WiX.

Check out "How the Runtime Locates Assemblies", 
http://msdn.microsoft.com/library/yx7xezcf

Pay particular attention to the probing section, "Step 4: Locating the Assembly 
through Codebases or Probing", http://msdn.microsoft.com/en-us/library/15hyw9x3

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Robert Hermann [mailto:rob.herm...@nicewareintl.com]
> Sent: Wednesday, June 29, 2011 2:18 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] How do you share dll's between executabled files
> 
> As an update to my post below ...
> 
> I enabled Assembly Binding Logging and according to the log file, windows
> was not even checking the system path (%Path%) .. it  just made some
> checks in the current directory using probing search technique and then
> seeing how it did not find anything, it threw the error.
> 
> At this point, I don't think its so much of a Wix issue,  rather an .NET 
> issue  ..
> unless somebody knows different.
> 
> 
> 
> -Original Message-
> From: Robert Hermann [mailto:rob.herm...@nicewareintl.com]
> Sent: Wednesday, June 29, 2011 1:02 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] How do you share dll's between executabled files
> 
> Ok, I've got the common file folder setup.
> 
> 
> 
>   
> 
> 
>   
> 
> 
>Permanent="yes" Part="last" Action="set" System="yes" />
> 
>   Needed
> files...
> 
> 
> After the install, I echo %Path% and the does show the addition of the NW
> Shared directory.  The expected Dlls are in that directory.
> 
> 
> My problem is when I launch the admin tool from its directory, an exception
> is thrown stating it can't find a Dll that I know is in the path .. more 
> specifically
> the NW Shared directory. The dll name is in the format
> companyname.product family.application name.
> Maybe the problem is obvious and I am just not seeing it ...
> 
> 
> Rob
> 
> 
> 
> 
> **
> **
> The information in this e-mail and any attachments is confidential and may be
> subject to legal professional privilege. It is intended solely for the 
> attention
> and use of the named addressee(s). If you are not the intended recipient or
> person responsible for delivering this information to the intended recipient,
> please notify the sender immediately. Unless you are the intended recipient
> or his/her representative you are not authorized to, and must not, read,
> copy, distribute, use or retain this message or any part of it
> 
> -Original Message-
> From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
> Sent: Tuesday, June 28, 2011 4:01 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] How do you share dll's between executabled files
> 
> Oh, and there is a known property called CommonFilesFolder as documented
> here.
> 
> http://msdn.microsoft.com/en-us/library/aa367994%28VS.85%29.aspx
> 
> So, makes it real easy to use.
> 
> -Original Message-
> From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
> Sent: Tuesday, June 28, 2011 1:46 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] How do you share dll's between executabled files
> 
> We place some of our shared files in C:\Program Files\Common Files\ company name>
> 
> -Original Message-
> From: Robert Hermann [mailto:rob.herm...@nicewareintl.com]
> Sent: Tuesday, June 28, 2011 1:14 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] How do you share dll's between executabled files
> 
> I've got a wix installer that installs a backend service and a  front end to
> control the backend service.
> 
> The Admin front end is being placed in one directory and the service is being
> placed in another directory.  They have a few dlls that I would like to share
> between them.
> 
> My plan is to install the dlls to one directory and  then have those dll be 
> seen
> by the service and frontend.
> 
> How would you do this ?
> 
> Thanks !
> 
> Rob
> 
> 
> **
> **
> **
> The information in this e-mail and any attachments is confidential and may be
> subject to legal professional privilege. It is intended solely for the 
> attention
> and use of the named addressee(s). If you are not the intended recipient or
> person responsible for delivering this information to the intended recipient,
> please notify the sender immediately. Unless you are the intended recipient
> or his/her representative you are not authorized to, and must no

Re: [WiX-users] How to: dynamically decide registry path to write to based on OS architecture

[Castro, Edwin G. (Hillsboro)]

Create a x86 msi package and use the following authoring


  

http://www.example.com";
Action="append"
KeyPath="yes"
Type="string"/> 


A x86 msi package will automatically get redirected to use 32-bit registry 
locations.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: Sameer Arora [mailto:arora...@gmail.com]
> Sent: Tuesday, June 28, 2011 10:23 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] How to: dynamically decide registry path to write to
> based on OS architecture
> 
> Hi,
> 
> I need a way  decide the registry path to write to based on the OS
> architecture the installer is installing on.
> 
> E.g:
> If OS is x64 bit
> create a registry key under HKLM\SOFTWARE\WoW6432Node\MyCompany
> otherwise write to
> create a registry key under HKLM\SOFTWARE\MyCompany
> 
> To achieve this, I nest a component in the a Directory element (does not
> allow the component outside of Directory element):
> 
>   
>   Root="HKLM"
>  Action="createAndRemoveOnUninstall"
> * Key= >at this point, how can get a path based on
> OS arch: HKLM\SOFTWARE\MyCompany for x86 OR
> HKLM\SOFTWARE\Wow6432Node\MyCompany for x64  <*
>   >
>   
> Name="MyURI"
>  Value="http://www.example.com";
>   Action="append"
>   KeyPath="yes"
>   Type="string"/>
> 
> 
>   
> 
> 
> 
> I considered using condition element like
> VersionNT64 but wouldn't that require me to
> create 2 RegistryKey elements - one each for the case where VersionNT64 is
> defined and undefined. I'd like to avoid to deal with two RegistryKey entries
> and have if/else clauses all over the place.
> 
> 
> Appreciate any and all suggestions.
> 
> Thanks,
> Sameer
> --
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix project error in TFS build

[Castro, Edwin G. (Hillsboro)]

Hmm... I already have a project reference in my SetupProject to a 
CSharpProject. Visual Studio already shows the dependency checked and doesn't 
let me change it. The solution builds fine in Visual Studio but not on the 
command line (msbuild).

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: John Bergman [mailto:john.berg...@xpedienttechnologies.com]
> Sent: Thursday, June 23, 2011 12:05 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix project error in TFS build
> 
> On the connect web site, this is a known issue.
> 
> You can use the solutions configuration manager to set project dependencies
> from inside visual studio.
> 
> -----Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: Thursday, June 23, 2011 1:35 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix project error in TFS build
> 
> I'm noticing something similar in some my builds. What do you mean by
> "manually set the dependency"?
> 
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> P Please consider the environment before printing this e-mail
> 
> 
> > -Original Message-
> > From: John Bergman [mailto:john.berg...@xpedienttechnologies.com]
> > Sent: Thursday, June 23, 2011 11:06 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Wix project error in TFS build
> >
> > If you are using the MSBUILD capabilities on your build servers,
> > update the command line in the build to provide a verbose output, you
> > should be able to see what the problem in the log.
> >
> > We noticed that in 2010 that sometimes there are dependency issues,
> > and if that is the case (ie, the missing dll is built after your wix
> > project), you need to update the configuration in the VS2010 project
> > to manually set the dependency.  I think we ended up with 2 manual
> > dependencies in our projects to finally make the problem go away.
> >
> > -Original Message-
> > From: ansariwn [mailto:w.ans...@gmail.com]
> > Sent: Thursday, June 23, 2011 11:29 AM
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] Wix project error in TFS build
> >
> > Hi,
> >
> > I am building a solution that contains a Wix v3.6 project on Team
> > Foundation Server (TFS 2010). The solution also contains some other
> > class library projects. The TFS build is unsuccessful with the following 
> > error:
> > light.exe : error LGHT0103: The system cannot find the file
> 'Path\assembly.dll'
> > with type ''.
> >
> > I have checked that the file (assembly.dll) in question, it does
> > exists at the given path. The file in question is actually the output
> > of another project in the solution. Apart from this file there are
> > other files that are successfully found by WIX project build in the same 
> > path
> location.
> >
> > Can somebody tell me why is this happening?
> >
> >
> > --
> > View this message in context: http://windows-installer-xml-wix-
> > toolset.687559.n2.nabble.com/Wix-project-error-in-TFS-build-
> > tp6508973p6508973.html
> > Sent from the wix-users mailing list archive at Nabble.com.
> >
> > --
> >  Simplify data backup and recovery for your virtual
> > environment with vRanger.
> > Installation's a snap, and flexible recovery options mean your data is
> > safe, secure and there when you need it. Data protection magic?
> > Nope - It's vRanger. Get your free trial download today.
> > http://p.sf.net/sfu/quest-sfdev2dev
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> > --
> >  Simplify data backup and recovery for your virtual
> > environment with vRanger.
> > Installation's a snap, and flexible recovery options mean your data is
> > safe, secure and there when you need it. Data protection magic?
> > Nope - It's vRanger. Get your free trial download today.
> > http://p.sf.net/sfu/quest-sfdev2dev
> 

Re: [WiX-users] Wix project error in TFS build

[Castro, Edwin G. (Hillsboro)]

I'm noticing something similar in some my builds. What do you mean by "manually 
set the dependency"?

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: John Bergman [mailto:john.berg...@xpedienttechnologies.com]
> Sent: Thursday, June 23, 2011 11:06 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix project error in TFS build
> 
> If you are using the MSBUILD capabilities on your build servers, update the
> command line in the build to provide a verbose output, you should be able to
> see what the problem in the log.
> 
> We noticed that in 2010 that sometimes there are dependency issues, and if
> that is the case (ie, the missing dll is built after your wix project), you 
> need to
> update the configuration in the VS2010 project to manually set the
> dependency.  I think we ended up with 2 manual dependencies in our
> projects to finally make the problem go away.
> 
> -Original Message-
> From: ansariwn [mailto:w.ans...@gmail.com]
> Sent: Thursday, June 23, 2011 11:29 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Wix project error in TFS build
> 
> Hi,
> 
> I am building a solution that contains a Wix v3.6 project on Team Foundation
> Server (TFS 2010). The solution also contains some other class library
> projects. The TFS build is unsuccessful with the following error:
> light.exe : error LGHT0103: The system cannot find the file 
> 'Path\assembly.dll'
> with type ''.
> 
> I have checked that the file (assembly.dll) in question, it does exists at the
> given path. The file in question is actually the output of another project in 
> the
> solution. Apart from this file there are other files that are successfully 
> found
> by WIX project build in the same path location.
> 
> Can somebody tell me why is this happening?
> 
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/Wix-project-error-in-TFS-build-
> tp6508973p6508973.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> --
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users