Re: [WiX-users] disassemble a bundle

2013-08-20 Thread Blair Murri
Once you have the bug tracker up on sourceforge, you need to login using a 
sourceforge account.
 
> From: jo...@msli.com
> To: wix-users@lists.sourceforge.net
> Date: Tue, 20 Aug 2013 17:24:59 -0700
> Subject: Re: [WiX-users] disassemble a bundle
> 
> How do I file a bug?
> 
> I get "Oops, looks like something went wrong." no matter how I try to
> reach your bug tracking system.
> 
> >From http://wixtoolset.org
>  I click 'Bugs', which points to  http://wixtoolset.org/bugs
> 
> >From http://wix.sourceforge.net/ On the right under Support -> Bug
> Database also points to http://wixtoolset.org/bugs
> 
> I also tried to reach: http://sourceforge.net/p/wix/bugs/
> 
> >From https://sourceforge.net/projects/wix/
> I clicked on Tickets -> Bugs
> 
> What is the correct way?
> 
> On Mon, 2013-08-19 at 22:36 -0700, Blair Murri wrote:
> > I think we should make that error message more clear. Please file a bug.
> >  
> > > From: jo...@msli.com
> > > To: wix-users@lists.sourceforge.net
> > > Date: Mon, 19 Aug 2013 14:00:08 -0700
> > > Subject: Re: [WiX-users] disassemble a bundle
> > > 
> > > I see I had to make a directory and extract into it
> > > dark.exe -x foo MyProgram-3.1.0-3776-Installer.exe
> > > 
> > > On Mon, 2013-08-19 at 13:52 -0700, jo...@msli.com wrote:
> > > > I ask because dark didn't work for me.
> > > > 
> > > > $ dark  MyProgram-3.1.0-3776-Installer.exe
> > > > Windows Installer Xml Decompiler version 3.7.1224.0
> > > > Copyright (C) Outercurve Foundation. All rights reserved.
> > > > 
> > > > MyProgram-3.1.0-3776-Installer.exe
> > > > dark.exe : error DARK0001 : Value cannot be null.
> > > > Parameter name: path1
> > > > 
> > > > Exception Type: System.ArgumentNullException
> > > > 
> > > > Stack Trace:
> > > >at System.IO.Path.Combine(String path1, String path2)
> > > >at Microsoft.Tools.WindowsInstallerXml.Unbinder.UnbindBundle(String
> > > > bundleFile, String exportBasePath)
> > > >at Microsoft.Tools.WindowsInstallerXml.Unbinder.Unbind(String file,
> > > > OutputType outputType, String exportBasePath)
> > > >at Microsoft.Tools.WindowsInstallerXml.Tools.Dark.Run(String[] args)
> > > > 
> > > > 
> > > > On Mon, 2013-08-19 at 11:55 -0700, Rob Mensching wrote:
> > > > > Just like everything else: dark.exe.
> > > > > 
> > > > > 
> > > > > On Mon, Aug 19, 2013 at 11:44 AM, jo...@msli.com  
> > > > > wrote:
> > > > > 
> > > > > > Is there a way to disassemble a bundle?
> > > > > >
> > > > > >
> > > > > >
> > > > > > NOTICE: This email may contain confidential information.  Please see
> > > > > > http://www.meyersound.com/confidential/ for our complete policy.
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Introducing Performance Central, a new site from SourceForge and
> > > > > > AppDynamics. Performance Central is your source for news, insights,
> > > > > > analysis and resources for efficient Application Performance 
> > > > > > Management.
> > > > > > Visit us today!
> > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> > > > > > ___
> > > > > > WiX-users mailing list
> > > > > > WiX-users@lists.sourceforge.net
> > > > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > > > >
> > > > > >
> > > > > --
> > > > > Introducing Performance Central, a new site from SourceForge and 
> > > > > AppDynamics. Performance Central is your source for news, insights, 
> > > > > analysis and resources for efficient Application Performance 
> > > > > Management. 
> > > > > Visit us today!
> > > > > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> > > > > ___
> > > > > WiX-users mailing list
> > > > > WiX-users@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > > 
> > > > 
> > > > 
> > > > NOTICE: This email may contain confidential information.  Please see 
> > > > http://www.meyersound.com/confidential/ for our complete policy.
> > > > 
> > > > --
> > > > Introducing Performance Central, a new site from SourceForge and 
> > > > AppDynamics. Performance Central is your source for news, insights, 
> > > > analysis and resources for efficient Application Performance 
> > > > Management. 
> > > > Visit us today!
> > > > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> > > > ___
> > > > WiX-users mailing list
> > > > WiX-users@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > 
> > > 
> > > 
> > > --
> > > Introducing Performance Central, a new site from SourceForge and 
> > > AppDynam

Re: [WiX-users] disassemble a bundle

2013-08-20 Thread jo...@msli.com
How do I file a bug?

I get "Oops, looks like something went wrong." no matter how I try to
reach your bug tracking system.

>From http://wixtoolset.org
 I click 'Bugs', which points to  http://wixtoolset.org/bugs

>From http://wix.sourceforge.net/ On the right under Support -> Bug
Database also points to http://wixtoolset.org/bugs

I also tried to reach: http://sourceforge.net/p/wix/bugs/

>From https://sourceforge.net/projects/wix/
I clicked on Tickets -> Bugs

What is the correct way?

On Mon, 2013-08-19 at 22:36 -0700, Blair Murri wrote:
> I think we should make that error message more clear. Please file a bug.
>  
> > From: jo...@msli.com
> > To: wix-users@lists.sourceforge.net
> > Date: Mon, 19 Aug 2013 14:00:08 -0700
> > Subject: Re: [WiX-users] disassemble a bundle
> > 
> > I see I had to make a directory and extract into it
> > dark.exe -x foo MyProgram-3.1.0-3776-Installer.exe
> > 
> > On Mon, 2013-08-19 at 13:52 -0700, jo...@msli.com wrote:
> > > I ask because dark didn't work for me.
> > > 
> > > $ dark  MyProgram-3.1.0-3776-Installer.exe
> > > Windows Installer Xml Decompiler version 3.7.1224.0
> > > Copyright (C) Outercurve Foundation. All rights reserved.
> > > 
> > > MyProgram-3.1.0-3776-Installer.exe
> > > dark.exe : error DARK0001 : Value cannot be null.
> > > Parameter name: path1
> > > 
> > > Exception Type: System.ArgumentNullException
> > > 
> > > Stack Trace:
> > >at System.IO.Path.Combine(String path1, String path2)
> > >at Microsoft.Tools.WindowsInstallerXml.Unbinder.UnbindBundle(String
> > > bundleFile, String exportBasePath)
> > >at Microsoft.Tools.WindowsInstallerXml.Unbinder.Unbind(String file,
> > > OutputType outputType, String exportBasePath)
> > >at Microsoft.Tools.WindowsInstallerXml.Tools.Dark.Run(String[] args)
> > > 
> > > 
> > > On Mon, 2013-08-19 at 11:55 -0700, Rob Mensching wrote:
> > > > Just like everything else: dark.exe.
> > > > 
> > > > 
> > > > On Mon, Aug 19, 2013 at 11:44 AM, jo...@msli.com  wrote:
> > > > 
> > > > > Is there a way to disassemble a bundle?
> > > > >
> > > > >
> > > > >
> > > > > NOTICE: This email may contain confidential information.  Please see
> > > > > http://www.meyersound.com/confidential/ for our complete policy.
> > > > >
> > > > >
> > > > > --
> > > > > Introducing Performance Central, a new site from SourceForge and
> > > > > AppDynamics. Performance Central is your source for news, insights,
> > > > > analysis and resources for efficient Application Performance 
> > > > > Management.
> > > > > Visit us today!
> > > > > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> > > > > ___
> > > > > WiX-users mailing list
> > > > > WiX-users@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > > >
> > > > >
> > > > --
> > > > Introducing Performance Central, a new site from SourceForge and 
> > > > AppDynamics. Performance Central is your source for news, insights, 
> > > > analysis and resources for efficient Application Performance 
> > > > Management. 
> > > > Visit us today!
> > > > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> > > > ___
> > > > WiX-users mailing list
> > > > WiX-users@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > 
> > > 
> > > 
> > > NOTICE: This email may contain confidential information.  Please see 
> > > http://www.meyersound.com/confidential/ for our complete policy.
> > > 
> > > --
> > > Introducing Performance Central, a new site from SourceForge and 
> > > AppDynamics. Performance Central is your source for news, insights, 
> > > analysis and resources for efficient Application Performance Management. 
> > > Visit us today!
> > > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > 
> > 
> > 
> > --
> > Introducing Performance Central, a new site from SourceForge and 
> > AppDynamics. Performance Central is your source for news, insights, 
> > analysis and resources for efficient Application Performance Management. 
> > Visit us today!
> > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> ---

Re: [WiX-users] Component/@Guid error

2013-08-20 Thread Michael Turner
I have encountered this also.  This a defect in light.exe 3.0.5419, which I
confirmed by downloading the WiX 3.0.5419 source code and searching for the
error message.  (I did this a few months ago, so I can't remember the exact
location off the top of my head.)

This is what the linker does in 3.0.5419:  If you try to auto-generate a
Component GUID for any component whose key path is in the registry, it reads
through the entire Registry table (i.e., the in-memory representation
thereof), and if it finds *ANY* entries that use Property substitution, it
throws this error.  This is defective logic:  it should only be examining
the entry that is the key path of the component in question, rather than the
entire table.

If you have the option, I would recommend using WiX 3.5 or later.  As far as
I can tell, the component GUID auto-generation was still in its infancy in
3.0 and didn't really get finished or stable until 3.5.

Regards,
Mike



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

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


Re: [WiX-users] Basic MSI without UI

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

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

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

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

Hello,

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

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

Thank you,
Andrei

Marlos Gottschild  wrote:

>Hi,
>You can create a bootstrapper using Burn and set the execution to /quiet.
>
>BR,
>Marlos
>
>
>2013/8/20 Andrei Trif 
>
>> Hello,
>>
>> I just started with WIX and I have a question, is there any way I can 
>> hide the little box where Windows Installer says what's happening 
>> during the install of a simple basic msi without a UI?
>>
>> I tried to suppress the entire UI sequence but the little box is 
>> still displayed.
>> Then I tried to set the UILEVEL property to 2 but little box is still 
>> displayed. In the log file I can see that the property is actually 
>> set to 3 just before the INSTALL.
>> Then I tried to set the LIMITUI property to 2 but the little box is 
>> still there.
>>
>> Please give some advice.
>>
>> Thank you,
>>
>> Andrei
>>
>> -
>> - Introducing Performance Central, a new site from 
>> SourceForge and AppDynamics. Performance Central is your source for 
>> news, insights, analysis and resources for efficient Application 
>> Performance Management.
>> Visit us today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.
>> clktrk ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>---
>--- Introducing Performance Central, a new site from SourceForge 
>and AppDynamics. Performance Central is your source for news, insights, 
>analysis and resources for efficient Application Performance Management.
>Visit us today!
>http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.cl
>ktrk ___
>WiX-users mailing list
>WiX-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/wix-users
--
Introducing Performance Central, a new site from SourceForge and AppDynamics. 
Performance Central is your source for news, insights, analysis and resources 
for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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


Re: [WiX-users] Does not appear in the Programs and Features

2013-08-20 Thread Phil Wilson
Assuming you are relatively sure that the app did install (for example
because it was a fresh install on a clean system and you can see that files
were actually installed) make sure you didn't flip something that made your
product a system component, ARPSYSTEMCOMPONENT set to 1 will hide the
entry.


On Tue, Aug 20, 2013 at 11:00 AM, Marlos Gottschild <
marlos.gottsch...@gmail.com> wrote:

> Hi,
> 1) With your app not* *installed, do you have an entry here with same GUID
> as your app?
>
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UpgradeCodes
>
> 2) After having your app installed, can you find your app here (maybe
> different GUID - from your previous 'guid=*' packages)?
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
>
>
> BR,
> Marlos
>
>
> 2013/8/20 yugolancer 
>
> > It was working since yesterday and suddenly when I tested today the newly
> > installed app does not appear in the above mentioned list. I don't know
> > what
> > I've changed except that I set Product ID replacing the asterisk with a
> > hardcoded GUID.
> >
> > Please advice. Thank you
> >
> >
> >
> > --
> > View this message in context:
> >
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Does-not-appear-in-the-Programs-and-Features-tp7588257.html
> > Sent from the wix-users mailing list archive at Nabble.com.
> >
> >
> >
> --
> > Introducing Performance Central, a new site from SourceForge and
> > AppDynamics. Performance Central is your source for news, insights,
> > analysis and resources for efficient Application Performance Management.
> > Visit us today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



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


Re: [WiX-users] Merge module not working

2013-08-20 Thread Phil Wilson
I'm not sure why there is any controversy.

The VC redist installs the policy modules anyway. A mixed situation where
some use the redist, some use the code merge module, and  some use
code+policy is too unpredictable, and this is one of the things that
happens.

Anyone that wants a private copy of the C++ Dlls can install them in the
application local folder - that's the way to avoid the impact that some
appear worried about:

http://msdn.microsoft.com/en-us/library/ms235299(v=vs.100).aspx

and keep in mind that any time MS issues a support or security fix to any
of the runtimes then the system-wide ones will get updated anyway,
including policy redirection, and any private runtime copies would need
product patches to avoid the possibility of their use of the
compromised runtimes bring exploited.




On Tue, Aug 20, 2013 at 11:40 AM, Blair Murri  wrote:

> Orca. Check the file table. All the binaries will (every time I've looked)
> have the same version.
>
> > From: laasu...@hotmail.com
> > To: wix-users@lists.sourceforge.net
> > Date: Tue, 20 Aug 2013 09:07:53 +0200
> > Subject: Re: [WiX-users] Merge module not working
> >
> > I am happy to include the policy merge module (for now).
> >
> > I appreciate that using the policy module can be a debatable topic.
> Maybe that is why I suggested changing the line in the howto, because it
> suggestes it is straightforward. Maybe rather very breifly explain the pros
> and cons of using policy. That might have saved me some time. Just my
> opinion.
> >
> > The build binary uses verson 8.0.50727.762 of the standard libs. I did
> not understand howto determine msm version? Where do I view msm metadata?
> Tryed explorer and visual studio but neither gave me any info.
> >
> > regards, Lars
> >
> > > From: os...@live.com
> > > To: wix-users@lists.sourceforge.net
> > > Date: Mon, 19 Aug 2013 23:37:57 -0700
> > > Subject: Re: [WiX-users] Merge module not working
> > >
> > > There is a fair bit of debate about the propriety of including the
> policy MSMs. Some argue that they should be included (MS does ship them as
> MSMs, after all) so that everyone will benefit from whatever the
> latest-and-greatest the user happens to install (i.e. increase the coverage
> of MSFT security fixes). Others counter that including the policy MSM can
> cause other installed software to fail because it changes the runtime that
> those other already installed applications to load, and they may be
> depending on some undocumented or unanticipated "feature" that was changed
> in some subsequent fix.
> > >
> > > In other words, adding the policy MSM can cause other people's code to
> break (just because the user installed yours). You can usually get yours to
> work without the policy MSM by making your code build against the updated
> libs that the MSM you are distributing were built with.
> > >
> > > That was the root of my question. What revision of the libs are you
> building against (you can see this in the manifest embedded in your
> binaries) vs what are you shipping in the MSM (you can see this in the
> metadata in the MSM)?
> > >
> > > > From: laasu...@hotmail.com
> > > > To: wix-users@lists.sourceforge.net
> > > > Date: Tue, 20 Aug 2013 08:16:47 +0200
> > > > Subject: Re: [WiX-users] Merge module not working
> > > >
> > > > Thank you for your reply.
> > > >
> > > > Adding the policy merge module solved the issue.
> > > >
> > > > I would consider updating the
> http://wix.sourceforge.net/manual-wix3/install_vcredist.htm page, either
> update this line "There is generally no need to include the policy MSMs as
> part of the installation." or describe the purpose of the policy msm very
> briefly.
> > > >
> > > > Lars
> > > >
> > > > > Date: Mon, 19 Aug 2013 14:46:11 -0700
> > > > > From: phildgwil...@gmail.com
> > > > > To: wix-users@lists.sourceforge.net
> > > > > Subject: Re: [WiX-users] Merge module not working
> > > > >
> > > > > A couple of other things to look at, assuming you've looked at
> Blair's
> > > > > comment:
> > > > >
> > > > > One issue with these SxS Dlls is that the policy merge module
> makes a
> > > > > difference. IIRC, the VC redist exe will install the Dlls and the
> policy
> > > > > file that redirects requests to the appropriate Dll. So I'd add
> the policy
> > > > > merge module.
> > > > >
> > > > > The other issue is that the VC redist installs everything. For
> example, if
> > > > > your code has a dependency on the MFC or ATL Dlls then the CRT by
> itself is
> > > > > not enough.
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Aug 19, 2013 at 9:08 AM, Blair Murri 
> wrote:
> > > > >
> > > > > > Did the merge module come from the same service pack level of
> Visual
> > > > > > Studio as was used to build the application?
> > > > > >
> > > > > > > From: laasu...@hotmail.com
> > > > > > > To: wix-users@lists.sourceforge.net
> > > > > > > Date: Mon, 19 Aug 2013 11:34:36 +0200
> > > > > > > Subject: [WiX-users] Merge module not working
> > > > > > >
> > > > > > > U

Re: [WiX-users] Basic MSI without UI

2013-08-20 Thread Andrei Trif
Hello,

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

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

Thank you,
Andrei

Marlos Gottschild  wrote:

>Hi,
>You can create a bootstrapper using Burn and set the execution to /quiet.
>
>BR,
>Marlos
>
>
>2013/8/20 Andrei Trif 
>
>> Hello,
>>
>> I just started with WIX and I have a question, is there any way I can hide
>> the little box where Windows Installer says what's happening during the
>> install of a simple basic msi without a UI?
>>
>> I tried to suppress the entire UI sequence but the little box is still
>> displayed.
>> Then I tried to set the UILEVEL property to 2 but little box is still
>> displayed. In the log file I can see that the property is actually set to 3
>> just before the INSTALL.
>> Then I tried to set the LIMITUI property to 2 but the little box is still
>> there.
>>
>> Please give some advice.
>>
>> Thank you,
>>
>> Andrei
>>
>> --
>> Introducing Performance Central, a new site from SourceForge and
>> AppDynamics. Performance Central is your source for news, insights,
>> analysis and resources for efficient Application Performance Management.
>> Visit us today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>--
>Introducing Performance Central, a new site from SourceForge and 
>AppDynamics. Performance Central is your source for news, insights, 
>analysis and resources for efficient Application Performance Management. 
>Visit us today!
>http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>___
>WiX-users mailing list
>WiX-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/wix-users
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] RE. Multilanguage bundle

2013-08-20 Thread Phill Hogland
I thought I had the 3.7.1224 with the
WiXExtendedBootstraperApplication.RtfLicense stuff working in the test
package that I uploaded to another thread.  Folks in that thread said that
it did not work for them, so I went back to the same project again and when
I compile it under Wix 3.7.1224 with the WixBalExtendedExt.dll added to the
3.7 bin folder, I also cannot get it to auto detect the language.  I
reworked the code to conform to the Bundle5 and Bundle11 examples on the
http://wixextba.codeplex.com/ site, but I still cannot get it to work.

For my project I converted it to Wix 3.8.722 with seven languages and so far
it auto detects a supported language.

For Wix 3.7.1224 with the WixBalExtendedExt.dll, I can see using ProcessMon
(and in looking at the ba1 folder while the setup is running) that it
created both the 1031 and 1033 subfolders and included the appropriate wxl
and RTF files, but it then selects the 1033 files on a system where both
System and User defaults are reported by Wix to be set to 1031. 

So I understand the frustration but can't advise on a solution.  If you want
to use the Extended BA then I suggest building the samples that came with it
and using ProcessMon to watch those samples (which is what I will do when I
get a free moment).

Phill




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

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


Re: [WiX-users] torch transforms

2013-08-20 Thread Blair Murri
Your already building an MSI. I'm saying you still build that same just-one 
MSI, but in a slightly more indirect way. If you want to create MSTs using 
wixouts instead of wixpdbs you need a wixout from your base also, not its 
wixpdb. I was simply describing how to get a wixout from your base.
 
Yes, you can get those MSTs from torch. You don't need to build actual MSIs 
from all of your cultures, only from your base. I'm trying to tell you an 
alternate way to build your base MSI so that you will have files that torch can 
use together.
 
> From: edoming...@goalsystems.com
> To: wix-users@lists.sourceforge.net
> Date: Tue, 20 Aug 2013 10:58:13 +0200
> Subject: Re: [WiX-users] torch transforms
> 
> Thansk for your reply, but I don't like to build MSIs but MSTs. I only 
> needing en-US MSI (neutral) and MSTs from other cultures. It's for building a 
> Multilanguage MSI (all in one)
> Can't get I those MSTs with torch then?
> 
> 
> Enrique Domínguez Pinos
> 
> -Mensaje original-
> De: Blair Murri [mailto:os...@live.com] 
> Enviado el: lunes, 19 de agosto de 2013 18:12
> Para: General discussion for Windows Installer XML toolset.
> Asunto: Re: [WiX-users] torch transforms
> 
> Torch requires that its inputs all be in the same format. Create all of your 
> MSIs in WIXOUT, then run your base through light again to generate that MSI. 
> Pass only WIXOUTs to torch.
>  
> > From: edoming...@goalsystems.com
> > To: wix-users@lists.sourceforge.net
> > Date: Mon, 19 Aug 2013 12:14:21 +0200
> > Subject: [WiX-users] torch transforms
> > 
> > Hi all,
> > I'm building a multilanguage msi; for doing that I'm generating all msi 
> > cultures I need and then getting msts using torch. My msi it's big and 
> > making all cultures it's slow so I thinking build first base msi ('neutral' 
> > lang as en-US) and doing all others as wixout like this (showing spanish)
> >  "C:\Program Files (x86)\WiX Toolset v3.6\bin"\Light.exe 
> > -nologo -out ..\x86\Release\es-ES\AcmeApp_Setup.wixout -xo -cultures:es-ES 
> > -ext "C:\Program Files (x86)\WiX Toolset v3.6\bin"\WixUIExtension.dll -ext 
> > "C:\Program Files (x86)\WiX Toolset v3.6\bin"\WixNetFxExtension.dll 
> > -sice:ICE30 -sice:ICE61 -sice:ICE09 -reusecab -cc .\CABsCache 
> > "obj\x86\Release\*.wixobj"  
> > C:\Proyectos\App\WiX_Installer\\SetupLibrary\bin\x86\Release\SetupLibrary.wixlib
> >  C:\Proyectos\App\WiX_Installer\\SetupUI\bin\x86\Release\SetupUI.wixlib
> >  "C:\Program Files (x86)\WiX Toolset v3.6\bin"\torch -nologo 
> > -xi -val g ..\x86\Release\en-US\AcmeApp_Setup.wixpdb 
> > ..\x86\Release\es-ES\AcmeApp_Setup.wixout -out 
> > transforms\AcmeApp_Setup_es-ES.wixout
> >  "C:\Program Files (x86)\WiX Toolset v3.6\bin"\torch 
> > -nologo 
> > C:\Proyectos\App\WiX_Installer\\AcmeApp_Setup\transforms\AcmeApp_Setup
> > _es-ES.wixout -out 
> > C:\Proyectos\App\WiX_Installer\\AcmeApp_Setup\transforms\AcmeApp_Setup
> > _es-ES.mst
> > torch.exe(0,0): error TRCH0001: The given path's format is not supported.
> >  Exception Type: System.NotSupportedException
> >  Stack Trace:
> > at 
> > System.Security.Util.StringExpressionSet.CanonicalizePath(String path, 
> > Boolean needFullPath)
> > at 
> > System.Security.Util.StringExpressionSet.CreateListFromExpressions(String[] 
> > str, Boolean needFullPath)
> > at 
> > System.Security.Permissions.FileIOPermission.AddPathList(FileIOPermissionAccess
> >  access, AccessControlActions control, String[] pathListOrig, Boolean 
> > checkForDuplicates, Boolean needFullPath, Boolean copyPathList)
> > at 
> > System.Security.Permissions.FileIOPermission..ctor(FileIOPermissionAccess 
> > access, String[] pathList, Boolean checkForDuplicates, Boolean needFullPath)
> > at System.IO.FileInfo.Init(String fileName, Boolean 
> > checkHost)
> > at System.IO.FileInfo..ctor(String fileName)
> > at 
> > Microsoft.Tools.WindowsInstallerXml.BinderFileManager.CompareFiles(String 
> > targetFile, String updatedFile)
> > at 
> > Microsoft.Tools.WindowsInstallerXml.Binder.BindTransform(Output transform, 
> > String transformFile)
> > at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output 
> > output, String file)
> > at 
> > Microsoft.Tools.WindowsInstallerXml.Tools.Torch.Run(String[] args)
> >  Binder temporary directory located at 
> > 'C:\Users\edominguez\AppData\Local\Temp\p2vvirxq'.
> >  Unbinder temporary directory located at 
> > 'C:\Users\edominguez\AppData\Local\Temp\p2vvirxq'.
> >  Torch temporary directory located at 
> > 'C:\Users\edominguez\AppData\Local\Temp\ll1p1c42'.
> > Last torch line should give me transforms in mst format, no matter how I 
> > change paths. Maybe it could be accomplished in less commands?
> > 
> > Thanks!!
> > 

Re: [WiX-users] Condition on components validation

2013-08-20 Thread Blair Murri
You discovered the certain circumstances (if the condition is false the 
component is removed during the repair).
 
There are two other things you can do: either read in the registry value and 
rewrite it as part of the repair, or move the component to a different feature 
and effectively disable repair of that new feature.
 
The latter is doable but harder to get right (you will have to isolate and test 
your feature handling custom action in every possible scenario), I recommend 
the former (read it in appsearch and just rewrite the registry key in the 
component as-is).
 
> From: natalie.c...@measuresoft.com
> To: wix-users@lists.sourceforge.net
> Date: Tue, 20 Aug 2013 09:08:02 +0100
> Subject: Re: [WiX-users] Condition on components validation
> 
> Hi John,
> 
> Ah that makes sense, I didn't know that. The component is a registry value
> and gets set on a key dialog, on a new install the key dialog will always
> get shown as there is no unlock key in the registry and that is what is
> needed to unlock the software. However on a repair I only show the dialog if
> the unlock key is not in the registry, i.e. if it got corrupted/deleted. 
> 
> I wanted to place a condition on the component as on a repair if the key
> dialog is not shown the registry value is not being set and I get an error
> when trying to write it.
> 
> What certain circumstances are there?
> 
> Thanks for your help
> Natalie 
> 
> -Original Message-
> From: John Cooper [mailto:jocoo...@jackhenry.com] 
> Sent: 19 August 2013 17:01
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Condition on components validation
> 
> Well, on a "Repair", a previously installed component is going to be
> reinstalled.  By default, component conditions are considered only once.
> You'd need to make the Component Transitive.  But then you're going to run
> into the situation where the component may uninstall under certain
> circumstances during "Repair."
> 
> Why are you trying to block reinstall of that Component on "Repair"?
> 
> --
> John Merryweather Cooper
> Build & Install Engineer -- ESA
> Jack Henry & Associates, Inc.(r)
> Shawnee Mission, KS  66227
> Office:  913-341-3434 x791011
> jocoo...@jackhenry.com
> www.jackhenry.com
> 
> 
> 
> -Original Message-
> From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
> Sent: Monday, August 19, 2013 10:34 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Condition on components validation
> 
> I have a conditional component and the conditional statement is created via
> a custom actin that is run in the Install Execute Sequence before the
> CostFinalize action. However the component is always getting installed
> regardless of the condition.
> 
>  
> 
> My Condition: PROMPTLOCKMODE = "0"
> 
>  
> 
> I have checked my log and it shows the validation property being set
> properly to 1 which then my component should not be getting installed but it
> is and this is the component in the log.
> 
>  
> 
> LockEntries; Installed: Local;   Request: Local;   Action: Local
> 
>  
> 
> This is on a repair. Anyone know what I am doing wrong?
> 
>  
> 
> Thanks
> 
> Natalie
> 
> 
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead. 
> Download for free and get started troubleshooting in minutes. 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> NOTICE: This electronic mail message and any files transmitted with it are
> intended exclusively for the individual or entity to which it is addressed.
> The message, together with any attachment, may contain confidential and/or
> privileged information.
> Any unauthorized review, use, printing, saving, copying, disclosure or
> distribution is strictly prohibited. If you have received this message in
> error, please immediately advise the sender by reply email and delete all
> copies.
> 
> 
> 
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights, analysis
> and resources for efficient Application Performance Management. 
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> --
> Introducing Performance Central, a new site from SourceForge and 
> AppDynam

Re: [WiX-users] Basic MSI without UI

2013-08-20 Thread Marlos Gottschild
Hi,
You can create a bootstrapper using Burn and set the execution to /quiet.

BR,
Marlos


2013/8/20 Andrei Trif 

> Hello,
>
> I just started with WIX and I have a question, is there any way I can hide
> the little box where Windows Installer says what's happening during the
> install of a simple basic msi without a UI?
>
> I tried to suppress the entire UI sequence but the little box is still
> displayed.
> Then I tried to set the UILEVEL property to 2 but little box is still
> displayed. In the log file I can see that the property is actually set to 3
> just before the INSTALL.
> Then I tried to set the LIMITUI property to 2 but the little box is still
> there.
>
> Please give some advice.
>
> Thank you,
>
> Andrei
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] upgrade & patching

2013-08-20 Thread Blair Murri
No. What does the log say?
 
> From: chaita...@pointcross.com
> To: WiX-users@lists.sourceforge.net
> Date: Tue, 20 Aug 2013 07:33:01 +
> Subject: [WiX-users] upgrade & patching
> 
> Hi,
> 
> Is there any File limitations in Minor upgrade??
> When use 500 files by using minor upgrade it is not updating.
> What might be the Cause??
> 
> --
> Introducing Performance Central, a new site from SourceForge and 
> AppDynamics. Performance Central is your source for news, insights, 
> analysis and resources for efficient Application Performance Management. 
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Basic MSI without UI

2013-08-20 Thread John Cooper
Use the /qn switch on msiexec.exe to completely suppress UI.  Also, be 
careful--UILevel like most installer properties is case sensitive.  The actual 
property is UILevel.  Since it is not upper case, it is not a public property 
can can't be passed on the command line.

--
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: Andrei Trif [mailto:trif.and...@mail.com] 
Sent: Tuesday, August 20, 2013 1:25 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Basic MSI without UI

Hello, 

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

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

Please give some advice.

Thank you,

Andrei
--
Introducing Performance Central, a new site from SourceForge and AppDynamics. 
Performance Central is your source for news, insights, analysis and resources 
for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.


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


Re: [WiX-users] Merge module not working

2013-08-20 Thread Blair Murri
Orca. Check the file table. All the binaries will (every time I've looked) have 
the same version.
 
> From: laasu...@hotmail.com
> To: wix-users@lists.sourceforge.net
> Date: Tue, 20 Aug 2013 09:07:53 +0200
> Subject: Re: [WiX-users] Merge module not working
> 
> I am happy to include the policy merge module (for now).
>  
> I appreciate that using the policy module can be a debatable topic. Maybe 
> that is why I suggested changing the line in the howto, because it suggestes 
> it is straightforward. Maybe rather very breifly explain the pros and cons of 
> using policy. That might have saved me some time. Just my opinion.
>  
> The build binary uses verson 8.0.50727.762 of the standard libs. I did not 
> understand howto determine msm version? Where do I view msm metadata? Tryed 
> explorer and visual studio but neither gave me any info.
>  
> regards, Lars
>  
> > From: os...@live.com
> > To: wix-users@lists.sourceforge.net
> > Date: Mon, 19 Aug 2013 23:37:57 -0700
> > Subject: Re: [WiX-users] Merge module not working
> > 
> > There is a fair bit of debate about the propriety of including the policy 
> > MSMs. Some argue that they should be included (MS does ship them as MSMs, 
> > after all) so that everyone will benefit from whatever the 
> > latest-and-greatest the user happens to install (i.e. increase the coverage 
> > of MSFT security fixes). Others counter that including the policy MSM can 
> > cause other installed software to fail because it changes the runtime that 
> > those other already installed applications to load, and they may be 
> > depending on some undocumented or unanticipated "feature" that was changed 
> > in some subsequent fix.
> >  
> > In other words, adding the policy MSM can cause other people's code to 
> > break (just because the user installed yours). You can usually get yours to 
> > work without the policy MSM by making your code build against the updated 
> > libs that the MSM you are distributing were built with.
> >  
> > That was the root of my question. What revision of the libs are you 
> > building against (you can see this in the manifest embedded in your 
> > binaries) vs what are you shipping in the MSM (you can see this in the 
> > metadata in the MSM)?
> >  
> > > From: laasu...@hotmail.com
> > > To: wix-users@lists.sourceforge.net
> > > Date: Tue, 20 Aug 2013 08:16:47 +0200
> > > Subject: Re: [WiX-users] Merge module not working
> > > 
> > > Thank you for your reply.
> > >  
> > > Adding the policy merge module solved the issue.
> > >  
> > > I would consider updating the 
> > > http://wix.sourceforge.net/manual-wix3/install_vcredist.htm page, either 
> > > update this line "There is generally no need to include the policy MSMs 
> > > as part of the installation." or describe the purpose of the policy msm 
> > > very briefly.
> > >  
> > > Lars
> > >  
> > > > Date: Mon, 19 Aug 2013 14:46:11 -0700
> > > > From: phildgwil...@gmail.com
> > > > To: wix-users@lists.sourceforge.net
> > > > Subject: Re: [WiX-users] Merge module not working
> > > > 
> > > > A couple of other things to look at, assuming you've looked at Blair's
> > > > comment:
> > > > 
> > > > One issue with these SxS Dlls is that the policy merge module makes a
> > > > difference. IIRC, the VC redist exe will install the Dlls and the policy
> > > > file that redirects requests to the appropriate Dll. So I'd add the 
> > > > policy
> > > > merge module.
> > > > 
> > > > The other issue is that the VC redist installs everything. For example, 
> > > > if
> > > > your code has a dependency on the MFC or ATL Dlls then the CRT by 
> > > > itself is
> > > > not enough.
> > > > 
> > > > 
> > > > 
> > > > On Mon, Aug 19, 2013 at 9:08 AM, Blair Murri  wrote:
> > > > 
> > > > > Did the merge module come from the same service pack level of Visual
> > > > > Studio as was used to build the application?
> > > > >
> > > > > > From: laasu...@hotmail.com
> > > > > > To: wix-users@lists.sourceforge.net
> > > > > > Date: Mon, 19 Aug 2013 11:34:36 +0200
> > > > > > Subject: [WiX-users] Merge module not working
> > > > > >
> > > > > > Using Wix 3.7
> > > > > >
> > > > > > I added Microsoft_VC80_CRT_x86.msm merge module to my wix setup
> > > > > according to 
> > > > > http://wix.sourceforge.net/manual-wix3/install_vcredist.htm
> > > > > >
> > > > > > I tested the new msi file on a clean WinXP SP3 machine. Installed 
> > > > > > the
> > > > > product and when I started the application I get "The application 
> > > > > failed to
> > > > > initalize properly (oxc0150002). Click on Ok to terminate the 
> > > > > application".
> > > > > > I downloaded and installed  "Microsoft Visual C++ 2005 
> > > > > > Redistributable
> > > > > Package (x86)" on the test computer and the application then works.
> > > > > > So I try to diff the usage of merge module and redistribuable.
> > > > > > - Both approaches creates the folder
> > > > > "C:\WINDOWS\WinSys\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700"
> > >

Re: [WiX-users] Wix Burn: Bundle condition does not work if using MBA

2013-08-20 Thread Nan Zang
I would like to try the option of change the prereq-BA to a different native BA 
which do the precheck. I don't have much knowledge about how BA. Do I need to 
modify wix source code to achieve this? Could you give me some more details on 
how to do it? 

1. Which interface my prereq BA needs to implement.
2. How to configure the bundle.wxs to use my customized prereq BA.

Is there any example I can take a look at?  

Thanks for the great help,

Nan

-Original Message-
From: Blair Murri [mailto:os...@live.com] 
Sent: Tuesday, August 20, 2013 12:05 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix Burn: Bundle condition does not work if using MBA

The error message is from Windows (ERROR_OLD_WIN_VERSION).
 
The only other possibility would be to change the prereq-BA to a different 
native BA that would determine the applicability of your installation attempt 
and present the appropriate error message before the prerequisites are 
installed. Or alter the current stdba (which is the current mbapreq using a 
different codepath) to add that feature. I would suggest if you go that route 
that you also update WixBalExtension and add a bal:PrereqCondition mirroring 
the current bal:Condition.
 
> From: naz...@microsoft.com
> To: wix-users@lists.sourceforge.net
> Date: Tue, 20 Aug 2013 06:33:18 +
> Subject: Re: [WiX-users] Wix Burn: Bundle condition does not work if 
> using MBA
> 
> I tried it, however it doesn't work fully for my case. Besides the OS 
> version, I also need to check the architecture of the OS. I want to block 64 
> bit package to be installed on a 32 bit OS.  If I set the condition, the 
> installation will be blocked, however, I didn't see I can customize the 
> error, I always get "The specified program requires a newer version of 
> Windows." 
> 
> For the bundle\@condition, is that possible I can customize the error 
> message? Or, any other way to do it?
> 
> Thanks,
> Nan
> 
> -Original Message-
> From: Blair Murri [mailto:os...@live.com]
> Sent: Monday, August 19, 2013 10:46 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix Burn: Bundle condition does not work if 
> using MBA
> 
> Bundle\@Condition attribute.
>  
> The limited conditions it can evaluate include OS.
>  
> > From: naz...@microsoft.com
> > To: wix-users@lists.sourceforge.net
> > Date: Tue, 20 Aug 2013 05:12:55 +
> > Subject: Re: [WiX-users] Wix Burn: Bundle condition does not work if 
> > using MBA
> > 
> > Hi,
> > 
> > I met with the same problem with the MBA precheck. Definitely, I can have 
> > the code in my MBA to check the pre conditions, however, I think the 
> > following scenario is totally broken.  Eg. We want to block installation of 
> > our product on the OS vista or before. 
> > 
> > A user uses a vista machine without .net 4.  User downloads the package and 
> > clicks install. To load MBA, the setup will guide user to install .Net 4 
> > and after installing .net 4, the setup will tell the user, sorry, wrong OS. 
> >  I think this is a horrible user experience, and I really want to do better 
> > here. Is there any possible way to handle the above situation? Any precheck 
> > I can do except having it in my MBA.
> > 
> > Many Thanks,
> > Nan
> > 
> > 
> > 
> > -Original Message-
> > From: Phill Hogland [mailto:phogl...@rimage.com]
> > Sent: Friday, August 2, 2013 6:13 AM
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] Wix Burn: Bundle condition does not work if 
> > using MBA
> > 
> > The WixBA at src\Setup\WixBA is the C# managed BA that is used by the 
> > installer that installs the toolset.  The Bundle does not have a 
> > bal:Condition in it and as far as I can tell there is nothing directly 
> > related to Bal:Condition in WixBA.  However I think what folks have 
> > suggested is that one could look at how the processing of bal:Condition is 
> > implemented in the C++ WixStdBA at src\ext\BalExtensions\wixstdba and using 
> > that functionality as a pattern implement something like that in the 
> > managed BA that you are writing.  I think one would want to look at 
> > EvaluateConditions in WixStandardBootstrapperApplication.cpp for a starter.
> > 
> > 
> > 
> > --
> > View this message in context: 
> > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-Bu
> > rn 
> > -Bundle-condition-does-not-work-if-using-MBA-tp7581757p758.html
> > Sent from the wix-users mailing list archive at Nabble.com.
> > 
> > 
> > --
> >  Get your SQL database under version control now!
> > Version control is standard for application code, but databases havent 
> > caught up. So what steps can you take to put your SQL databases under 
> > version control? Why should you start doing it? Read more to find out.
> > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg
> > .c lktrk ___

Re: [WiX-users] Basic MSI without UI

2013-08-20 Thread Steven Ogilvie
Did you try running the MSI via the command line MSIEXEC /qn?



Windows (r) Installer. V 5.0.7601.17514



msiexec /Option  [Optional Parameter]



Install Options



  Installs or configures a product

   /a 

  Administrative install - Installs a product on 
the network

   /j  [/t ] [/g ]

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



  Uninstalls the product

Display Options

   /quiet

  Quiet mode, no user interaction

   /passive

  Unattended mode - progress bar only

   /q[n|b|r|f]

  Sets user interface level

  n - No UI

  b - Basic UI

  r - Reduced UI

  f - Full UI (default)

   /help

  Help information

Restart Options

   /norestart

  Do not restart after the installation is complete

   /promptrestart

  Prompts the user for restart if necessary

   /forcerestart

  Always restart the computer after installation

Logging Options

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

  i - Status messages

  w - Nonfatal warnings

  e - All error messages

  a - Start up of actions

  r - Action-specific records

  u - User requests

  c - Initial UI parameters

  m - Out-of-memory or fatal exit information

  o - Out-of-disk-space messages

  p - Terminal properties

  v - Verbose output

  x - Extra debugging information

  + - Append to existing log file

  ! - Flush each line to the log

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

   /log 

  Equivalent of /l* 

Update Options

   /update [;Update2.msp]

  Applies update(s)

   /uninstall [;Update2.msp] /package 

  Remove update(s) for a product

Repair Options

   /f[p|e|c|m|s|o|d|a|u|v] 

  Repairs a product

  p - only if file is missing

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

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

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

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

  a - forces all files to be reinstalled

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

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

  s - all existing shortcuts (default)

  v - runs from source and recaches local package

Setting Public Properties

   [PROPERTY=PropertyValue]



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



Hello,



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



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

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

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



Please give some advice.



Thank you,



Andrei

--

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

Visit us today!

http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk

___

WiX-users mailing list

WiX-users@lists.sourceforge.net

[WiX-users] Basic MSI without UI

2013-08-20 Thread Andrei Trif
Hello, 

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

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

Please give some advice.

Thank you,

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


Re: [WiX-users] Does not appear in the Programs and Features

2013-08-20 Thread Marlos Gottschild
Hi,
1) With your app not* *installed, do you have an entry here with same GUID
as your app?
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UpgradeCodes

2) After having your app installed, can you find your app here (maybe
different GUID - from your previous 'guid=*' packages)?
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall


BR,
Marlos


2013/8/20 yugolancer 

> It was working since yesterday and suddenly when I tested today the newly
> installed app does not appear in the above mentioned list. I don't know
> what
> I've changed except that I set Product ID replacing the asterisk with a
> hardcoded GUID.
>
> Please advice. Thank you
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Does-not-appear-in-the-Programs-and-Features-tp7588257.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] bundle error if I build though automated system

2013-08-20 Thread John Cooper
TFS Power Tools:

Tfpt.exe treeclean . /recursive /noprompt OR
Tfpt.exe scorch . /recursive /noprompt

For non-TFS version control, other tools can be used depending on your source 
control.

--
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: jo...@msli.com [mailto:jo...@msli.com] 
Sent: Tuesday, August 20, 2013 12:28 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] bundle error if I build though automated system

It is a bundle signing problem so the email thread title is wrong, but I didn't 
know that at the time.  Should start a new thread?

The documentation?  I don't see the word insignia mentioned in, "WIX
3.6: A Developer's Guild to Windows Installer XML".  Maybe there should be a 
errata?  Wix documentation needs a searchable work flow oriented index of 
how-to's in addition to a man page on each tool.  

Since code signing is a necessary evil in Windows8, wix needs a tool called 
"scorch.exe" that knows how to handle any files it can generate, so this isn't 
so convoluted.

Looks like you mean:
  http://wix.sourceforge.net/manual-wix3/insignia.htm
this procedure:
1. Detach engine from bundle
COMMAND: insignia.exe -ib MyBundle.exe -o engine.exe 2. Sign engine
COMMAND: signtool.exe sign /v /f my.pfx /p cert_passwd /t ${CERT_TIME_URL} /du 
mydomain.com /d MyProgram engine.exe 3. Re-attach the burn engine from a bundle 
insignia -ab engine.exe MyBundle.exe -o MyBundle.exe 4. Sign bundle
COMMAND: signtool.exe sign /v /f my.pfx /p cert_passwd /t ${CERT_TIME_URL} /du 
mydomain.com /d MyProgram MyBundle.exe


On Tue, 2013-08-20 at 08:17 -0700, Rob Mensching wrote: 
> Did you sign the bundle according to the documentation on the Insignia page?
> 
> 
> On Mon, Aug 19, 2013 at 4:57 PM, jo...@msli.com  wrote:
> 
> > I sign the bundle I get this error.
> > An unsigned bundle seems to work.
> >
> > On Mon, 2013-08-19 at 15:36 -0700, jo...@msli.com wrote:
> > > Looks like my log file was stripped out
> > >
> > > [0EA8:0208][2013-08-19T14:44:54]i001: Burn v3.7.1224.0, Windows 
> > > v6.1
> > (Build 7601: Service Pack 1), path:
> > C:\Users\build\Desktop\MyProgram-3.1.0-3776-Installer.exe, cmdline:
> > '-burn.unelevated BurnPipe.{A7261C75-BACC-4401-B5F3-42EEC22098B5}
> > {F94F9B48-9AB8-4C18-969A-9AAF3E9BB205} 3852'
> > > [0EA8:0208][2013-08-19T14:44:54]i000: Setting string variable
> > 'WixBundleLog' to value
> > 'C:\Users\build\AppData\Local\Temp\My_Company_MyProgram_3.1.0_Bundle_20130819144454.log'
> > > [0EA8:0208][2013-08-19T14:44:54]i000: Setting string variable
> > 'WixBundleOriginalSource' to value
> > 'C:\Users\build\Desktop\MyProgram-3.1.0-3776-Installer.exe'
> > > [0EA8:0208][2013-08-19T14:44:55]i052: Condition '( (VersionNT >= 
> > > v5.1)
> > AND (ServicePackLevel >= 3)) OR ( (VersionNT >= v5.2) AND 
> > (ServicePackLevel
> > >= 2)) OR (VersionNT >= v6.0)' evaluates to true.
> > > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> > 'WixBundleName' to value 'Meyer Sound MyProgram 3.1.0 Bundle'
> > > [0EA8:0208][2013-08-19T14:44:55]i100: Detect begin, 4 packages
> > > [0EA8:0208][2013-08-19T14:44:55]i000: Setting numeric variable
> > 'BonjourDLL' to value 1
> > > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> > 'BounjourVersion' to value '2.0.2.0'
> > > [0EA8:0208][2013-08-19T14:44:55]i000: Setting numeric variable
> > 'ProxyInstalled' to value 1
> > > [0EA8:0208][2013-08-19T14:44:55]i000: Setting numeric variable
> > 'WinPcapInstalled' to value 1
> > > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> > 'WinPcapVersionMajor' to value '4'
> > > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> > 'WinPcapVersionMinor' to value '1'
> > > [0EA8:0208][2013-08-19T14:44:55]i103: Detected related package:
> > {03D789F3-42D5-4FEC-BCDA-0F5BAC51B535}, scope: PerMachine, version:
> > 1.0.3.0, language: 0 operation: Downgrade
> > > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package: WinPcap, state:
> > Absent, cached: None
> > > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package: 
> > > BonjourPSSetup,
> > state: Absent, cached: None
> > > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package: MyProxy, state:
> > Obsolete, cached: None
> > > [0EA8:0208][2013-08-19T14:44:55]i104: Detected package: MyProxy,
> > feature: DefaultFeature, state: Absent
> > > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package:
> > MyProgramInstaller, state: Absent, cached: None
> > > [0EA8:0208][2013-08-19T14:44:55]i104: Detected package:
> > MyProgramInstaller, feature: Complete, state: Absent
> > > [0EA8:0208][2013-08-19T14:44:55]i199: Detect complete, result: 0x0
> > > [0EA8:0208][2013-08-19T14:44:59]i200: Plan begin, 4 packages, action:
> > Install
> > > [0EA8:0208][2013-08-19T14:44:59]i052: Condition 'NOT 
> > > WinPcapInstalled OR
> > ( 4 > WinPcapVers

Re: [WiX-users] bundle error if I build though automated system

2013-08-20 Thread jo...@msli.com
It is a bundle signing problem so the email thread title is wrong, but I
didn't know that at the time.  Should start a new thread?

The documentation?  I don't see the word insignia mentioned in, "WIX
3.6: A Developer's Guild to Windows Installer XML".  Maybe there should
be a errata?  Wix documentation needs a searchable work flow oriented
index of how-to's in addition to a man page on each tool.  

Since code signing is a necessary evil in Windows8, wix needs a tool
called "scorch.exe" that knows how to handle any files it can generate,
so this isn't so convoluted.

Looks like you mean:
  http://wix.sourceforge.net/manual-wix3/insignia.htm
this procedure:
1. Detach engine from bundle
COMMAND: insignia.exe -ib MyBundle.exe -o engine.exe
2. Sign engine
COMMAND: signtool.exe sign /v /f my.pfx /p cert_passwd /t ${CERT_TIME_URL} /du 
mydomain.com /d MyProgram engine.exe
3. Re-attach the burn engine from a bundle
insignia -ab engine.exe MyBundle.exe -o MyBundle.exe
4. Sign bundle
COMMAND: signtool.exe sign /v /f my.pfx /p cert_passwd /t ${CERT_TIME_URL} /du 
mydomain.com /d MyProgram MyBundle.exe


On Tue, 2013-08-20 at 08:17 -0700, Rob Mensching wrote: 
> Did you sign the bundle according to the documentation on the Insignia page?
> 
> 
> On Mon, Aug 19, 2013 at 4:57 PM, jo...@msli.com  wrote:
> 
> > I sign the bundle I get this error.
> > An unsigned bundle seems to work.
> >
> > On Mon, 2013-08-19 at 15:36 -0700, jo...@msli.com wrote:
> > > Looks like my log file was stripped out
> > >
> > > [0EA8:0208][2013-08-19T14:44:54]i001: Burn v3.7.1224.0, Windows v6.1
> > (Build 7601: Service Pack 1), path:
> > C:\Users\build\Desktop\MyProgram-3.1.0-3776-Installer.exe, cmdline:
> > '-burn.unelevated BurnPipe.{A7261C75-BACC-4401-B5F3-42EEC22098B5}
> > {F94F9B48-9AB8-4C18-969A-9AAF3E9BB205} 3852'
> > > [0EA8:0208][2013-08-19T14:44:54]i000: Setting string variable
> > 'WixBundleLog' to value
> > 'C:\Users\build\AppData\Local\Temp\My_Company_MyProgram_3.1.0_Bundle_20130819144454.log'
> > > [0EA8:0208][2013-08-19T14:44:54]i000: Setting string variable
> > 'WixBundleOriginalSource' to value
> > 'C:\Users\build\Desktop\MyProgram-3.1.0-3776-Installer.exe'
> > > [0EA8:0208][2013-08-19T14:44:55]i052: Condition '( (VersionNT >= v5.1)
> > AND (ServicePackLevel >= 3)) OR ( (VersionNT >= v5.2) AND (ServicePackLevel
> > >= 2)) OR (VersionNT >= v6.0)' evaluates to true.
> > > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> > 'WixBundleName' to value 'Meyer Sound MyProgram 3.1.0 Bundle'
> > > [0EA8:0208][2013-08-19T14:44:55]i100: Detect begin, 4 packages
> > > [0EA8:0208][2013-08-19T14:44:55]i000: Setting numeric variable
> > 'BonjourDLL' to value 1
> > > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> > 'BounjourVersion' to value '2.0.2.0'
> > > [0EA8:0208][2013-08-19T14:44:55]i000: Setting numeric variable
> > 'ProxyInstalled' to value 1
> > > [0EA8:0208][2013-08-19T14:44:55]i000: Setting numeric variable
> > 'WinPcapInstalled' to value 1
> > > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> > 'WinPcapVersionMajor' to value '4'
> > > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> > 'WinPcapVersionMinor' to value '1'
> > > [0EA8:0208][2013-08-19T14:44:55]i103: Detected related package:
> > {03D789F3-42D5-4FEC-BCDA-0F5BAC51B535}, scope: PerMachine, version:
> > 1.0.3.0, language: 0 operation: Downgrade
> > > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package: WinPcap, state:
> > Absent, cached: None
> > > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package: BonjourPSSetup,
> > state: Absent, cached: None
> > > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package: MyProxy, state:
> > Obsolete, cached: None
> > > [0EA8:0208][2013-08-19T14:44:55]i104: Detected package: MyProxy,
> > feature: DefaultFeature, state: Absent
> > > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package:
> > MyProgramInstaller, state: Absent, cached: None
> > > [0EA8:0208][2013-08-19T14:44:55]i104: Detected package:
> > MyProgramInstaller, feature: Complete, state: Absent
> > > [0EA8:0208][2013-08-19T14:44:55]i199: Detect complete, result: 0x0
> > > [0EA8:0208][2013-08-19T14:44:59]i200: Plan begin, 4 packages, action:
> > Install
> > > [0EA8:0208][2013-08-19T14:44:59]i052: Condition 'NOT WinPcapInstalled OR
> > ( 4 > WinPcapVersionMajor AND 1 > WinPcapVersionMinor)' evaluates to false.
> > > [0EA8:0208][2013-08-19T14:44:59]w321: Skipping dependency registration
> > on package with no dependency providers: WinPcap
> > > [0EA8:0208][2013-08-19T14:44:59]i052: Condition 'NOT BonjourDLL OR
> > v2.0.2.0 > BonjourVersion' evaluates to false.
> > > [0EA8:0208][2013-08-19T14:44:59]w321: Skipping dependency registration
> > on package with no dependency providers: BonjourPSSetup
> > > [0EA8:0208][2013-08-19T14:44:59]i204: Plan 1 msi features for package:
> > MyProgramInstaller
> > > [0EA8:0208][2013-08-19T14:44:59]i203: Planned feature: Complete, state:
> > Absent, default requested: Unknown, ba 

[WiX-users] Does not appear in the Programs and Features

2013-08-20 Thread yugolancer
It was working since yesterday and suddenly when I tested today the newly
installed app does not appear in the above mentioned list. I don't know what
I've changed except that I set Product ID replacing the asterisk with a
hardcoded GUID.

Please advice. Thank you



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Does-not-appear-in-the-Programs-and-Features-tp7588257.html
Sent from the wix-users mailing list archive at Nabble.com.

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


Re: [WiX-users] Radio Button passing parameter to Custom Action

2013-08-20 Thread JoeMarks
Managed to get it right, got it from  this stackoverflow post

  

Changed the "Next Button" to 



And then I can get the value of the property on my Custom Action:



Hope this will be helpful to someone.



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Radio-Button-passing-parameter-to-Custom-Action-tp7588250p7588256.html
Sent from the wix-users mailing list archive at Nabble.com.

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


Re: [WiX-users] bundle error if I build though automated system

2013-08-20 Thread Rob Mensching
Did you sign the bundle according to the documentation on the Insignia page?


On Mon, Aug 19, 2013 at 4:57 PM, jo...@msli.com  wrote:

> I sign the bundle I get this error.
> An unsigned bundle seems to work.
>
> On Mon, 2013-08-19 at 15:36 -0700, jo...@msli.com wrote:
> > Looks like my log file was stripped out
> >
> > [0EA8:0208][2013-08-19T14:44:54]i001: Burn v3.7.1224.0, Windows v6.1
> (Build 7601: Service Pack 1), path:
> C:\Users\build\Desktop\MyProgram-3.1.0-3776-Installer.exe, cmdline:
> '-burn.unelevated BurnPipe.{A7261C75-BACC-4401-B5F3-42EEC22098B5}
> {F94F9B48-9AB8-4C18-969A-9AAF3E9BB205} 3852'
> > [0EA8:0208][2013-08-19T14:44:54]i000: Setting string variable
> 'WixBundleLog' to value
> 'C:\Users\build\AppData\Local\Temp\My_Company_MyProgram_3.1.0_Bundle_20130819144454.log'
> > [0EA8:0208][2013-08-19T14:44:54]i000: Setting string variable
> 'WixBundleOriginalSource' to value
> 'C:\Users\build\Desktop\MyProgram-3.1.0-3776-Installer.exe'
> > [0EA8:0208][2013-08-19T14:44:55]i052: Condition '( (VersionNT >= v5.1)
> AND (ServicePackLevel >= 3)) OR ( (VersionNT >= v5.2) AND (ServicePackLevel
> >= 2)) OR (VersionNT >= v6.0)' evaluates to true.
> > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> 'WixBundleName' to value 'Meyer Sound MyProgram 3.1.0 Bundle'
> > [0EA8:0208][2013-08-19T14:44:55]i100: Detect begin, 4 packages
> > [0EA8:0208][2013-08-19T14:44:55]i000: Setting numeric variable
> 'BonjourDLL' to value 1
> > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> 'BounjourVersion' to value '2.0.2.0'
> > [0EA8:0208][2013-08-19T14:44:55]i000: Setting numeric variable
> 'ProxyInstalled' to value 1
> > [0EA8:0208][2013-08-19T14:44:55]i000: Setting numeric variable
> 'WinPcapInstalled' to value 1
> > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> 'WinPcapVersionMajor' to value '4'
> > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> 'WinPcapVersionMinor' to value '1'
> > [0EA8:0208][2013-08-19T14:44:55]i103: Detected related package:
> {03D789F3-42D5-4FEC-BCDA-0F5BAC51B535}, scope: PerMachine, version:
> 1.0.3.0, language: 0 operation: Downgrade
> > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package: WinPcap, state:
> Absent, cached: None
> > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package: BonjourPSSetup,
> state: Absent, cached: None
> > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package: MyProxy, state:
> Obsolete, cached: None
> > [0EA8:0208][2013-08-19T14:44:55]i104: Detected package: MyProxy,
> feature: DefaultFeature, state: Absent
> > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package:
> MyProgramInstaller, state: Absent, cached: None
> > [0EA8:0208][2013-08-19T14:44:55]i104: Detected package:
> MyProgramInstaller, feature: Complete, state: Absent
> > [0EA8:0208][2013-08-19T14:44:55]i199: Detect complete, result: 0x0
> > [0EA8:0208][2013-08-19T14:44:59]i200: Plan begin, 4 packages, action:
> Install
> > [0EA8:0208][2013-08-19T14:44:59]i052: Condition 'NOT WinPcapInstalled OR
> ( 4 > WinPcapVersionMajor AND 1 > WinPcapVersionMinor)' evaluates to false.
> > [0EA8:0208][2013-08-19T14:44:59]w321: Skipping dependency registration
> on package with no dependency providers: WinPcap
> > [0EA8:0208][2013-08-19T14:44:59]i052: Condition 'NOT BonjourDLL OR
> v2.0.2.0 > BonjourVersion' evaluates to false.
> > [0EA8:0208][2013-08-19T14:44:59]w321: Skipping dependency registration
> on package with no dependency providers: BonjourPSSetup
> > [0EA8:0208][2013-08-19T14:44:59]i204: Plan 1 msi features for package:
> MyProgramInstaller
> > [0EA8:0208][2013-08-19T14:44:59]i203: Planned feature: Complete, state:
> Absent, default requested: Unknown, ba requested: Unknown, execute action:
> None, rollback action: None
> > [0EA8:0208][2013-08-19T14:44:59]i000: Setting string variable
> 'WixBundleRollbackLog_MyProgramInstaller' to value
> 'C:\Users\build\AppData\Local\Temp\My_Company_MyProgram_3.1.0_Bundle_20130819144454_0_MyProgramInstaller_rollback.log'
> > [0EA8:0208][2013-08-19T14:44:59]i000: Setting string variable
> 'WixBundleLog_MyProgramInstaller' to value
> 'C:\Users\build\AppData\Local\Temp\My_Company_MyProgram_3.1.0_Bundle_20130819144454_0_MyProgramInstaller.log'
> > [0EA8:0208][2013-08-19T14:44:59]i201: Planned package: WinPcap, state:
> Absent, default requested: Absent, ba requested: Absent, execute: None,
> rollback: None, cache: No, uncache: No, dependency: None
> > [0EA8:0208][2013-08-19T14:44:59]i201: Planned package: BonjourPSSetup,
> state: Absent, default requested: Absent, ba requested: Absent, execute:
> None, rollback: None, cache: No, uncache: No, dependency: None
> > [0EA8:0208][2013-08-19T14:44:59]i201: Planned package: MyProxy, state:
> Obsolete, default requested: None, ba requested: None, execute: None,
> rollback: None, cache: No, uncache: No, dependency: None
> > [0EA8:0208][2013-08-19T14:44:59]i201: Planned package:
> MyProgramInstaller, state: Absent, default requested: Present, ba
> requested: Present, ex

Re: [WiX-users] RE. Multilanguage bundle

2013-08-20 Thread Branko Horvat
Phil, thx for your guidance so far.

In WiX3.7 I manage to build setup.exe and run it with or without -lang 1031.
So I can see English and German draft version. Now I wanted to get to auto
detection on running setup.exe. So I downloaded the WixBalExtensionExt.dll.
I used that in candle.exe (WixBalExtensionExt) and light.exe. In my .wxs I
only changed the ...Standard... to ...Extension... I left .RtfLicense. I
build it no problem. So as my native language is de - austrian german), I
should see German version, but it is the same. I get it only with adding
-lang 1031.
I also downloaded your two .exe files seen in the previous post and it does
run german version already from the start. What am I doing wrong. I am not
using .HyperlinkLicense only .RtfLicense as before.

BR

... 
  



  
  





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

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


[WiX-users] Radio Button passing parameter to Custom Action

2013-08-20 Thread JoeMarks
Hello everyone!

In my current project, I must have the user selecting on of many radio
buttons, and execute a custom action according to the chosen value.

My current Dialog (the part that matters) is as follows:



And in my Product.wxs i have:



So as you can see, in my "Next" Button I want to run the "SetLanguage"
custom action (which I already managed to do), but I want to pass the
selection (language) as a parameter. It can be as string, int, doesn't
really matter, as long as I can get the value.

Already tried google, but I found very different results, none of them
providing me valuable content.

Thanks in advance,
Joe



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Radio-Button-passing-parameter-to-Custom-Action-tp7588250.html
Sent from the wix-users mailing list archive at Nabble.com.

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


Re: [WiX-users] torch transforms

2013-08-20 Thread Enrique Domínguez
Thansk for your reply, but I don't like to build MSIs but MSTs. I only needing 
en-US MSI (neutral) and MSTs from other cultures. It's for building a 
Multilanguage MSI (all in one)
Can't get I those MSTs with torch then?


Enrique Domínguez Pinos

-Mensaje original-
De: Blair Murri [mailto:os...@live.com] 
Enviado el: lunes, 19 de agosto de 2013 18:12
Para: General discussion for Windows Installer XML toolset.
Asunto: Re: [WiX-users] torch transforms

Torch requires that its inputs all be in the same format. Create all of your 
MSIs in WIXOUT, then run your base through light again to generate that MSI. 
Pass only WIXOUTs to torch.
 
> From: edoming...@goalsystems.com
> To: wix-users@lists.sourceforge.net
> Date: Mon, 19 Aug 2013 12:14:21 +0200
> Subject: [WiX-users] torch transforms
> 
> Hi all,
> I'm building a multilanguage msi; for doing that I'm generating all msi 
> cultures I need and then getting msts using torch. My msi it's big and making 
> all cultures it's slow so I thinking build first base msi ('neutral' lang as 
> en-US) and doing all others as wixout like this (showing spanish)
>  "C:\Program Files (x86)\WiX Toolset v3.6\bin"\Light.exe -nologo 
> -out ..\x86\Release\es-ES\AcmeApp_Setup.wixout -xo -cultures:es-ES -ext 
> "C:\Program Files (x86)\WiX Toolset v3.6\bin"\WixUIExtension.dll -ext 
> "C:\Program Files (x86)\WiX Toolset v3.6\bin"\WixNetFxExtension.dll 
> -sice:ICE30 -sice:ICE61 -sice:ICE09 -reusecab -cc .\CABsCache 
> "obj\x86\Release\*.wixobj"  
> C:\Proyectos\App\WiX_Installer\\SetupLibrary\bin\x86\Release\SetupLibrary.wixlib
>  C:\Proyectos\App\WiX_Installer\\SetupUI\bin\x86\Release\SetupUI.wixlib
>  "C:\Program Files (x86)\WiX Toolset v3.6\bin"\torch -nologo -xi 
> -val g ..\x86\Release\en-US\AcmeApp_Setup.wixpdb 
> ..\x86\Release\es-ES\AcmeApp_Setup.wixout -out 
> transforms\AcmeApp_Setup_es-ES.wixout
>  "C:\Program Files (x86)\WiX Toolset v3.6\bin"\torch 
> -nologo 
> C:\Proyectos\App\WiX_Installer\\AcmeApp_Setup\transforms\AcmeApp_Setup
> _es-ES.wixout -out 
> C:\Proyectos\App\WiX_Installer\\AcmeApp_Setup\transforms\AcmeApp_Setup
> _es-ES.mst
> torch.exe(0,0): error TRCH0001: The given path's format is not supported.
>  Exception Type: System.NotSupportedException
>  Stack Trace:
> at 
> System.Security.Util.StringExpressionSet.CanonicalizePath(String path, 
> Boolean needFullPath)
> at 
> System.Security.Util.StringExpressionSet.CreateListFromExpressions(String[] 
> str, Boolean needFullPath)
> at 
> System.Security.Permissions.FileIOPermission.AddPathList(FileIOPermissionAccess
>  access, AccessControlActions control, String[] pathListOrig, Boolean 
> checkForDuplicates, Boolean needFullPath, Boolean copyPathList)
> at 
> System.Security.Permissions.FileIOPermission..ctor(FileIOPermissionAccess 
> access, String[] pathList, Boolean checkForDuplicates, Boolean needFullPath)
> at System.IO.FileInfo.Init(String fileName, Boolean checkHost)
> at System.IO.FileInfo..ctor(String fileName)
> at 
> Microsoft.Tools.WindowsInstallerXml.BinderFileManager.CompareFiles(String 
> targetFile, String updatedFile)
> at 
> Microsoft.Tools.WindowsInstallerXml.Binder.BindTransform(Output transform, 
> String transformFile)
> at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output 
> output, String file)
> at 
> Microsoft.Tools.WindowsInstallerXml.Tools.Torch.Run(String[] args)
>  Binder temporary directory located at 
> 'C:\Users\edominguez\AppData\Local\Temp\p2vvirxq'.
>  Unbinder temporary directory located at 
> 'C:\Users\edominguez\AppData\Local\Temp\p2vvirxq'.
>  Torch temporary directory located at 
> 'C:\Users\edominguez\AppData\Local\Temp\ll1p1c42'.
> Last torch line should give me transforms in mst format, no matter how I 
> change paths. Maybe it could be accomplished in less commands?
> 
> Thanks!!
> --
>  Get 100% visibility into Java/.NET code with AppDynamics 
> Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead. 
> Download for free and get started troubleshooting in minutes. 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.c
> lktrk ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Introducing Performance Central, a new site from SourceForge and AppDynamics. 
Performance Central is your source for news, insights, analysis and resources 
for efficient Application Performance Management. 
Visit us today!
http

Re: [WiX-users] CAQuietExec: Error 0x80070002: CAQuietExec Failed

2013-08-20 Thread Neil Sleightholm
You can't run "echo" with invoking the command processor. Try "cmd /c echo 
blah...".

Neil

-Original Message-
From: Dusan Plavak [mailto:dusan.pla...@avitech-ag.com] 
Sent: 20 August 2013 08:49
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] CAQuietExec: Error 0x80070002: CAQuietExec Failed

Hi there,

I have a problem like a lot of people before me, but don`t know why their 
solutions aren`t working to me...

I found this topic:
http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg55613.html

I have CA like in his solution but still not working...

I have custom actions:

 







   







 

.

.

.

 



NOT REMOVE ~= "ALL"

NOT REMOVE ~= "ALL"

   

NOT REMOVE ~= "ALL"

NOT REMOVE ~= "ALL"

   

NOT REMOVE ~= "ALL"

NOT REMOVE ~= "ALL"



 

 

 

And finally log:

 

Action 9:36:18: InstallFinalize. 

Action start 9:36:18: InstallFinalize.

MSI (s) (14:A8) [09:36:18:867]: Running Script:
C:\Windows\Installer\MSI2390.tmp

MSI (s) (14:A8) [09:36:18:867]: PROPERTY CHANGE: Adding UpdateStarted property. 
Its value is '1'.

MSI (s) (14:A8) [09:36:18:868]: Machine policy value 'DisableRollback' is 0

MSI (s) (14:A8) [09:36:18:870]: Note: 1: 1402 2:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollb
ack\Scripts 3: 2 

MSI (s) (14:A8) [09:36:18:872]: Executing op:
Header(Signature=1397708873,Version=500,Timestamp=1125403786,LangId=1033,Pla
tform=0,ScriptType=1,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttrib
utes=0)

MSI (s) (14:A8) [09:36:18:873]: Executing op:
ProductInfo(ProductKey={FEC5421C-0A65-4AB2-AA14-6E3FC7E5FB94},ProductName=eM
AP.wiz@rd,PackageName=eMap.msi,Language=1033,Version=16908288,Assignment=0,O
bsoleteArg=0,,,PackageCode={D2F28507-5D55-4FEB-A1C0-0579B460A153},,,Instance
Type=0,LUASetting=0,RemoteURTInstalls=0,ProductDeploymentFlags=3)

MSI (s) (14:A8) [09:36:18:875]: SHELL32::SHGetFolderPath returned:
C:\Users\dusan.plavak\AppData\Roaming

MSI (s) (14:A8) [09:36:18:875]: Executing op:
DialogInfo(Type=0,Argument=1033)

MSI (s) (14:A8) [09:36:18:876]: Executing op:
DialogInfo(Type=1,Argument=eMAP.wiz@rd)

MSI (s) (14:A8) [09:36:18:876]: Executing op:
RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Rolling back 
action:,RollbackTemplate=[1],CleanupAction=RollbackCleanup,CleanupDescriptio
n=Removing backup files,CleanupTemplate=File: [1])

MSI (s) (14:A8) [09:36:18:876]: Executing op: SetBaseline(Baseline=0,)

MSI (s) (14:A8) [09:36:18:876]: Executing op: SetBaseline(Baseline=1,)

MSI (s) (14:A8) [09:36:18:876]: Executing op:
ActionStart(Name=ca_configuration_locationUCF_CMD,,)

Action 9:36:18: ca_configuration_locationUCF_CMD. 

MSI (s) (14:A8) [09:36:18:877]: Executing op:
CustomActionSchedule(Action=ca_configuration_locationUCF_CMD,ActionType=3073
,Source=BinaryData,Target=CAQuietExec,CustomActionData="echo"
eMAP_CONFIG_DIR = C:\Program Files (x86)\Avitech\eMAP.wiz@rd\ > C:\Program 
Files (x86)\Avitech\eMAP.wiz@rd\configuration_location.ucf)

MSI (s) (14:18) [09:36:18:879]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSI23FF.tmp, Entrypoint: CAQuietExec

MSI (s) (14:C4) [09:36:18:881]: Generating random cookie.

MSI (s) (14:C4) [09:36:18:916]: Created Custom Action Server with PID 1492 
(0x5D4).

MSI (s) (14:4C) [09:36:18:957]: Running as a service.

MSI (s) (14:4C) [09:36:18:959]: Hello, I'm your 32bit Impersonated custom 
action server.

CAQuietExec:  Error 0x80070002: Command failed to execute.

CAQuietExec:  Error 0x80070002: CAQuietExec Failed

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

Action ended 9:36:19: InstallFinalize. Return value 3.

 

 

 

Thanks so much for any help

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

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


Re: [WiX-users] Condition on components validation

2013-08-20 Thread Natalie Carr
John,

Just looked at that transitive attribute and it seems it will not help me as
it will uninstall my component if my condition changes to false.

Thanks
Natalie

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com] 
Sent: 19 August 2013 17:01
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Condition on components validation

Well, on a "Repair", a previously installed component is going to be
reinstalled.  By default, component conditions are considered only once.
You'd need to make the Component Transitive.  But then you're going to run
into the situation where the component may uninstall under certain
circumstances during "Repair."

Why are you trying to block reinstall of that Component on "Repair"?

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



-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: Monday, August 19, 2013 10:34 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Condition on components validation

I have a conditional component and the conditional statement is created via
a custom actin that is run in the Install Execute Sequence before the
CostFinalize action. However the component is always getting installed
regardless of the condition.

 

My Condition: PROMPTLOCKMODE = "0"

 

I have checked my log and it shows the validation property being set
properly to 1 which then my component should not be getting installed but it
is and this is the component in the log.

 

LockEntries; Installed: Local;   Request: Local;   Action: Local

 

This is on a repair. Anyone know what I am doing wrong?

 

Thanks

Natalie


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are
intended exclusively for the individual or entity to which it is addressed.
The message, together with any attachment, may contain confidential and/or
privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution is strictly prohibited. If you have received this message in
error, please immediately advise the sender by reply email and delete all
copies.



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


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


Re: [WiX-users] Condition on components validation

2013-08-20 Thread Natalie Carr
Hi John,

Ah that makes sense, I didn't know that. The component is a registry value
and gets set on a key dialog, on a new install the key dialog will always
get shown as there is no unlock key in the registry and that is what is
needed to unlock the software. However on a repair I only show the dialog if
the unlock key is not in the registry, i.e. if it got corrupted/deleted. 

I wanted to place a condition on the component as on a repair if the key
dialog is not shown the registry value is not being set and I get an error
when trying to write it.

What certain circumstances are there?

Thanks for your help
Natalie 

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com] 
Sent: 19 August 2013 17:01
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Condition on components validation

Well, on a "Repair", a previously installed component is going to be
reinstalled.  By default, component conditions are considered only once.
You'd need to make the Component Transitive.  But then you're going to run
into the situation where the component may uninstall under certain
circumstances during "Repair."

Why are you trying to block reinstall of that Component on "Repair"?

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



-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: Monday, August 19, 2013 10:34 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Condition on components validation

I have a conditional component and the conditional statement is created via
a custom actin that is run in the Install Execute Sequence before the
CostFinalize action. However the component is always getting installed
regardless of the condition.

 

My Condition: PROMPTLOCKMODE = "0"

 

I have checked my log and it shows the validation property being set
properly to 1 which then my component should not be getting installed but it
is and this is the component in the log.

 

LockEntries; Installed: Local;   Request: Local;   Action: Local

 

This is on a repair. Anyone know what I am doing wrong?

 

Thanks

Natalie


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are
intended exclusively for the individual or entity to which it is addressed.
The message, together with any attachment, may contain confidential and/or
privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution is strictly prohibited. If you have received this message in
error, please immediately advise the sender by reply email and delete all
copies.



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


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


[WiX-users] CAQuietExec: Error 0x80070002: CAQuietExec Failed

2013-08-20 Thread Dusan Plavak
Hi there,

I have a problem like a lot of people before me, but don`t know why their
solutions aren`t working to me...

I found this topic:
http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg55613.html

I have CA like in his solution but still not working...

I have custom actions:

 







   







 

.

.

.

 



NOT REMOVE ~= "ALL"

NOT REMOVE ~= "ALL"

   

NOT REMOVE ~= "ALL"

NOT REMOVE ~= "ALL"

   

NOT REMOVE ~= "ALL"

NOT REMOVE ~= "ALL"



 

 

 

And finally log:

 

Action 9:36:18: InstallFinalize. 

Action start 9:36:18: InstallFinalize.

MSI (s) (14:A8) [09:36:18:867]: Running Script:
C:\Windows\Installer\MSI2390.tmp

MSI (s) (14:A8) [09:36:18:867]: PROPERTY CHANGE: Adding UpdateStarted
property. Its value is '1'.

MSI (s) (14:A8) [09:36:18:868]: Machine policy value 'DisableRollback' is 0

MSI (s) (14:A8) [09:36:18:870]: Note: 1: 1402 2:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollb
ack\Scripts 3: 2 

MSI (s) (14:A8) [09:36:18:872]: Executing op:
Header(Signature=1397708873,Version=500,Timestamp=1125403786,LangId=1033,Pla
tform=0,ScriptType=1,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttrib
utes=0)

MSI (s) (14:A8) [09:36:18:873]: Executing op:
ProductInfo(ProductKey={FEC5421C-0A65-4AB2-AA14-6E3FC7E5FB94},ProductName=eM
AP.wiz@rd,PackageName=eMap.msi,Language=1033,Version=16908288,Assignment=0,O
bsoleteArg=0,,,PackageCode={D2F28507-5D55-4FEB-A1C0-0579B460A153},,,Instance
Type=0,LUASetting=0,RemoteURTInstalls=0,ProductDeploymentFlags=3)

MSI (s) (14:A8) [09:36:18:875]: SHELL32::SHGetFolderPath returned:
C:\Users\dusan.plavak\AppData\Roaming

MSI (s) (14:A8) [09:36:18:875]: Executing op:
DialogInfo(Type=0,Argument=1033)

MSI (s) (14:A8) [09:36:18:876]: Executing op:
DialogInfo(Type=1,Argument=eMAP.wiz@rd)

MSI (s) (14:A8) [09:36:18:876]: Executing op:
RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Rolling back
action:,RollbackTemplate=[1],CleanupAction=RollbackCleanup,CleanupDescriptio
n=Removing backup files,CleanupTemplate=File: [1])

MSI (s) (14:A8) [09:36:18:876]: Executing op: SetBaseline(Baseline=0,)

MSI (s) (14:A8) [09:36:18:876]: Executing op: SetBaseline(Baseline=1,)

MSI (s) (14:A8) [09:36:18:876]: Executing op:
ActionStart(Name=ca_configuration_locationUCF_CMD,,)

Action 9:36:18: ca_configuration_locationUCF_CMD. 

MSI (s) (14:A8) [09:36:18:877]: Executing op:
CustomActionSchedule(Action=ca_configuration_locationUCF_CMD,ActionType=3073
,Source=BinaryData,Target=CAQuietExec,CustomActionData="echo"
eMAP_CONFIG_DIR = C:\Program Files (x86)\Avitech\eMAP.wiz@rd\ > C:\Program
Files (x86)\Avitech\eMAP.wiz@rd\configuration_location.ucf)

MSI (s) (14:18) [09:36:18:879]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSI23FF.tmp, Entrypoint: CAQuietExec

MSI (s) (14:C4) [09:36:18:881]: Generating random cookie.

MSI (s) (14:C4) [09:36:18:916]: Created Custom Action Server with PID 1492
(0x5D4).

MSI (s) (14:4C) [09:36:18:957]: Running as a service.

MSI (s) (14:4C) [09:36:18:959]: Hello, I'm your 32bit Impersonated custom
action server.

CAQuietExec:  Error 0x80070002: Command failed to execute.

CAQuietExec:  Error 0x80070002: CAQuietExec Failed

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

Action ended 9:36:19: InstallFinalize. Return value 3.

 

 

 

Thanks so much for any help

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


[WiX-users] upgrade & patching

2013-08-20 Thread Chaitanya Sanapala [PC-BLR-DEV]
Hi,

Is there any File limitations in Minor upgrade??
When use 500 files by using minor upgrade it is not updating.
What might be the Cause??

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


Re: [WiX-users] Merge module not working

2013-08-20 Thread Lars Lars
I am happy to include the policy merge module (for now).
 
I appreciate that using the policy module can be a debatable topic. Maybe that 
is why I suggested changing the line in the howto, because it suggestes it is 
straightforward. Maybe rather very breifly explain the pros and cons of using 
policy. That might have saved me some time. Just my opinion.
 
The build binary uses verson 8.0.50727.762 of the standard libs. I did not 
understand howto determine msm version? Where do I view msm metadata? Tryed 
explorer and visual studio but neither gave me any info.
 
regards, Lars
 
> From: os...@live.com
> To: wix-users@lists.sourceforge.net
> Date: Mon, 19 Aug 2013 23:37:57 -0700
> Subject: Re: [WiX-users] Merge module not working
> 
> There is a fair bit of debate about the propriety of including the policy 
> MSMs. Some argue that they should be included (MS does ship them as MSMs, 
> after all) so that everyone will benefit from whatever the 
> latest-and-greatest the user happens to install (i.e. increase the coverage 
> of MSFT security fixes). Others counter that including the policy MSM can 
> cause other installed software to fail because it changes the runtime that 
> those other already installed applications to load, and they may be depending 
> on some undocumented or unanticipated "feature" that was changed in some 
> subsequent fix.
>  
> In other words, adding the policy MSM can cause other people's code to break 
> (just because the user installed yours). You can usually get yours to work 
> without the policy MSM by making your code build against the updated libs 
> that the MSM you are distributing were built with.
>  
> That was the root of my question. What revision of the libs are you building 
> against (you can see this in the manifest embedded in your binaries) vs what 
> are you shipping in the MSM (you can see this in the metadata in the MSM)?
>  
> > From: laasu...@hotmail.com
> > To: wix-users@lists.sourceforge.net
> > Date: Tue, 20 Aug 2013 08:16:47 +0200
> > Subject: Re: [WiX-users] Merge module not working
> > 
> > Thank you for your reply.
> >  
> > Adding the policy merge module solved the issue.
> >  
> > I would consider updating the 
> > http://wix.sourceforge.net/manual-wix3/install_vcredist.htm page, either 
> > update this line "There is generally no need to include the policy MSMs as 
> > part of the installation." or describe the purpose of the policy msm very 
> > briefly.
> >  
> > Lars
> >  
> > > Date: Mon, 19 Aug 2013 14:46:11 -0700
> > > From: phildgwil...@gmail.com
> > > To: wix-users@lists.sourceforge.net
> > > Subject: Re: [WiX-users] Merge module not working
> > > 
> > > A couple of other things to look at, assuming you've looked at Blair's
> > > comment:
> > > 
> > > One issue with these SxS Dlls is that the policy merge module makes a
> > > difference. IIRC, the VC redist exe will install the Dlls and the policy
> > > file that redirects requests to the appropriate Dll. So I'd add the policy
> > > merge module.
> > > 
> > > The other issue is that the VC redist installs everything. For example, if
> > > your code has a dependency on the MFC or ATL Dlls then the CRT by itself 
> > > is
> > > not enough.
> > > 
> > > 
> > > 
> > > On Mon, Aug 19, 2013 at 9:08 AM, Blair Murri  wrote:
> > > 
> > > > Did the merge module come from the same service pack level of Visual
> > > > Studio as was used to build the application?
> > > >
> > > > > From: laasu...@hotmail.com
> > > > > To: wix-users@lists.sourceforge.net
> > > > > Date: Mon, 19 Aug 2013 11:34:36 +0200
> > > > > Subject: [WiX-users] Merge module not working
> > > > >
> > > > > Using Wix 3.7
> > > > >
> > > > > I added Microsoft_VC80_CRT_x86.msm merge module to my wix setup
> > > > according to http://wix.sourceforge.net/manual-wix3/install_vcredist.htm
> > > > >
> > > > > I tested the new msi file on a clean WinXP SP3 machine. Installed the
> > > > product and when I started the application I get "The application 
> > > > failed to
> > > > initalize properly (oxc0150002). Click on Ok to terminate the 
> > > > application".
> > > > > I downloaded and installed  "Microsoft Visual C++ 2005 Redistributable
> > > > Package (x86)" on the test computer and the application then works.
> > > > > So I try to diff the usage of merge module and redistribuable.
> > > > > - Both approaches creates the folder
> > > > "C:\WINDOWS\WinSys\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700"
> > > > > - Both approaches add the same three files to the folder (msvcm80.dll,
> > > > msvcp80.dll, msvcr80.dll)
> > > > > - Diff'ed the files added by merge module and redistribuable and they
> > > > are binary equal.
> > > > >
> > > > > So why doesn't merge module work?
> > > > >
> > > > > I have added the wix configuration below.
> > > > > 
> > > > > http://schemas.microsoft.com/wix/2006/wi";>
> > > > >   > > > >   Language="1033"
> > > > >   Manufacturer="MyCompany"
> > > > >   Name="MyName"
> > > > >   UpgradeCode

Re: [WiX-users] Wix Burn: Bundle condition does not work if using MBA

2013-08-20 Thread Blair Murri
The error message is from Windows (ERROR_OLD_WIN_VERSION).
 
The only other possibility would be to change the prereq-BA to a different 
native BA that would determine the applicability of your installation attempt 
and present the appropriate error message before the prerequisites are 
installed. Or alter the current stdba (which is the current mbapreq using a 
different codepath) to add that feature. I would suggest if you go that route 
that you also update WixBalExtension and add a bal:PrereqCondition mirroring 
the current bal:Condition.
 
> From: naz...@microsoft.com
> To: wix-users@lists.sourceforge.net
> Date: Tue, 20 Aug 2013 06:33:18 +
> Subject: Re: [WiX-users] Wix Burn: Bundle condition does not work if using MBA
> 
> I tried it, however it doesn't work fully for my case. Besides the OS 
> version, I also need to check the architecture of the OS. I want to block 64 
> bit package to be installed on a 32 bit OS.  If I set the condition, the 
> installation will be blocked, however, I didn't see I can customize the 
> error, I always get "The specified program requires a newer version of 
> Windows." 
> 
> For the bundle\@condition, is that possible I can customize the error 
> message? Or, any other way to do it?
> 
> Thanks, 
> Nan  
> 
> -Original Message-
> From: Blair Murri [mailto:os...@live.com] 
> Sent: Monday, August 19, 2013 10:46 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix Burn: Bundle condition does not work if using MBA
> 
> Bundle\@Condition attribute.
>  
> The limited conditions it can evaluate include OS.
>  
> > From: naz...@microsoft.com
> > To: wix-users@lists.sourceforge.net
> > Date: Tue, 20 Aug 2013 05:12:55 +
> > Subject: Re: [WiX-users] Wix Burn: Bundle condition does not work if 
> > using MBA
> > 
> > Hi,
> > 
> > I met with the same problem with the MBA precheck. Definitely, I can have 
> > the code in my MBA to check the pre conditions, however, I think the 
> > following scenario is totally broken.  Eg. We want to block installation of 
> > our product on the OS vista or before. 
> > 
> > A user uses a vista machine without .net 4.  User downloads the package and 
> > clicks install. To load MBA, the setup will guide user to install .Net 4 
> > and after installing .net 4, the setup will tell the user, sorry, wrong OS. 
> >  I think this is a horrible user experience, and I really want to do better 
> > here. Is there any possible way to handle the above situation? Any precheck 
> > I can do except having it in my MBA.
> > 
> > Many Thanks,
> > Nan
> > 
> > 
> > 
> > -Original Message-
> > From: Phill Hogland [mailto:phogl...@rimage.com]
> > Sent: Friday, August 2, 2013 6:13 AM
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] Wix Burn: Bundle condition does not work if 
> > using MBA
> > 
> > The WixBA at src\Setup\WixBA is the C# managed BA that is used by the 
> > installer that installs the toolset.  The Bundle does not have a 
> > bal:Condition in it and as far as I can tell there is nothing directly 
> > related to Bal:Condition in WixBA.  However I think what folks have 
> > suggested is that one could look at how the processing of bal:Condition is 
> > implemented in the C++ WixStdBA at src\ext\BalExtensions\wixstdba and using 
> > that functionality as a pattern implement something like that in the 
> > managed BA that you are writing.  I think one would want to look at 
> > EvaluateConditions in WixStandardBootstrapperApplication.cpp for a starter.
> > 
> > 
> > 
> > --
> > View this message in context: 
> > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-Burn
> > -Bundle-condition-does-not-work-if-using-MBA-tp7581757p758.html
> > Sent from the wix-users mailing list archive at Nabble.com.
> > 
> > --
> >  Get your SQL database under version control now!
> > Version control is standard for application code, but databases havent 
> > caught up. So what steps can you take to put your SQL databases under 
> > version control? Why should you start doing it? Read more to find out.
> > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.c
> > lktrk ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> > 
> > 
> > 
> > 
> > --
> >  Introducing Performance Central, a new site from SourceForge 
> > and AppDynamics. Performance Central is your source for news, 
> > insights, analysis and resources for efficient Application Performance 
> > Management.
> > Visit us today!
> > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.c
> > lktrk ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https