Re: [WiX-users] Check that at least one Feature is selected

2014-09-16 Thread Noel Farrugia
So there isn't a simpler solution?
 
All I want to do is have access to a "variable", in this case myFeature from 
another file.
 
> Date: Mon, 15 Sep 2014 09:21:00 -0400
> From: yellowjacketl...@gmail.com
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Check that at least one Feature is selected
> 
> I solved this same issue with a custom action on the next button of the
> feature selection dialog.  I tried solving it within Wix/Windows Installer
> but was unable to.
> 
> The pseudo-code is something like this...
> 
>Value="CAMustSelectOne" Order="1">1
>Value="VerifyReadyDlg" Order="2">
> 
> Custom Action looked something like this (error handling and exception
> management removed for brevity):
> 
> // these are all hidden or "container only" features,
> // if they are selected for install, they are not considered a "real"
> feature
> private static readonly string[] IgnoredFeatures = { "Server", "Logs",
> "Data", "WebSites", "WindowsServices", "Tools" };
> 
> [CustomAction]
> public static ActionResult MustSelectOne(Session session)
> {
> ActionResult installResult = ActionResult.Success;
> 
> // assume we success until told otherwise
> session["ATLEASTONESELECTED"] = "1";
> 
> if (NoFeaturesSelected(session))
> {
> session["ATLEASTONESELECTED"] = "0";
> MessageBox.Show(new Form() { TopMost = true }, "One or more
> features must be selected");
> }
> 
> return installResult;
> }
> 
> private static bool NoFeaturesSelected(Session session)
> {
> return session.Features.Where(feature =>
> !IgnoredFeatures.Contains(feature.Name)).All(feature =>
> feature.RequestState != InstallState.Local);
> }
> 
> 
> On Mon, Sep 15, 2014 at 8:55 AM, Noel Farrugia 
> wrote:
> 
> > I need to "access" MyFeature in the UserInterface code to make a condition
> > such that if no feature is selected for installation the "Next" button can
> > be disabled.
> >
> > Thanks and Regards,
> > Noel
> >
> > > From: jocoo...@jackhenry.com
> > > To: wix-users@lists.sourceforge.net
> > > Date: Mon, 15 Sep 2014 12:24:04 +
> > > Subject: Re: [WiX-users] Check that at least one Feature is selected
> > >
> > > Currently, there is limited scoping of properties in Wix 3.x.  The only
> > problem you may sometimes run into is when a property crosses the UI to
> > Execute boundary--to do that, you'll need a public secure property.
> > >
> > > So, how exactly do you want to "access" MyFeature?
> > >
> > > --
> > > John Merryweather Cooper
> > > Senior Software Engineer | Enterprise Service Applications | Continuing
> > Development
> > > Jack Henry & Associates, Inc.® | Lenexa, KS  66214 | Ext:  431050 |
> > jocoo...@jackhenry.com
> > >
> > >
> > >
> > > -Original Message-
> > > From: Noel Farrugia [mailto:noel.farru...@outlook.com]
> > > Sent: Monday, September 15, 2014 7:17 AM
> > > To: wix-users@lists.sourceforge.net
> > > Subject: [WiX-users] Check that at least one Feature is selected
> > >
> > > Hi all,
> > >
> > > I have a setup with feature selection enabled like this one now, in a
> > file called "MyInstaller.wxs",
> > >
> > >  > >
> > >
> > >  Title="MyTitle"
> > >
> > >
> > >  Description="Desc"
> > >
> > >
> > >  Level="1" AllowAdvertise="no" Absent="allow"
> > TypicalDefault="install">
> > >
> > >
> > >
> > >   
> > >   .
> > >   .
> > >   .
> > > 
> > >
> > > The code that handles the User interface is in another file called
> > UserInterface.wxi.
> > > I know that to check if a certain feature is selected I need to do
> > <[CDATA[&MyFeature=3]]> in the "Publish" line example:
> > >
> > >  > Value="InstallWelcomeDlg">$(var.allowFeatureChoice) = 1
> > >
> > > now my question is how can I access the "MyFeature" which is located in
> > "MyInstaller.wxs" in the "UserInterface.wxi"file ?
> > >
> > > Thanks a lot for your help :)
> > >
> > > Noel
> > >
> > >
> > --
> > > Want excitement?
> > > Manually upgrade your production database.
> > > When you want reliability, choose Perforce Perforce version control.
> > Predictably reliable.
> > >
> > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&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 copie

Re: [WiX-users] Bundle that upgrades two different bundles (different upgrade codes)

2014-09-16 Thread Stabiplan Development
To answer my own question: this appears to work.

The DetectRelatedBundle event gives only product codes. Is there a way to find 
the advertises name (from ARP) that belongs to a bundle product code?

Met vriendelijke groet, 

Rob van Rosmalen B ICT  software engineer 
stabiplan +31 172 65 02 65  www.stabiplan.nl www.stabiplan.nl/disclaimer 
-Original Message-
From: Stabiplan Development [mailto:d...@stabiplan.nl] 
Sent: vrijdag 12 september 2014 08:04
To: 'General discussion about the WiX toolset.'
Subject: Re: [WiX-users] Bundle that upgrades two different bundles (different 
upgrade codes)

Hi Rob,

Does this also work if only that related bundle is installed? This will be the 
case: either one or both bundles can be installed.

Met vriendelijke groet, 

Rob van Rosmalen B ICT  software engineer stabiplan +31 172 65 02 65  
www.stabiplan.nl www.stabiplan.nl/disclaimer -Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: donderdag 11 september 2014 17:49
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Bundle that upgrades two different bundles (different 
upgrade codes)

Use same UpgradeCode as one bundle and add a RelatedBundle to upgrade the 
other. Make sure new version is higher than both.

_
 Short replies here. Complete answers over there: http://www.firegiant.com/



-Original Message-
From: Stabiplan Development [mailto:d...@stabiplan.nl]
Sent: Thursday, September 11, 2014 1:38 AM
To: 'wix-users@lists.sourceforge.net'
Subject: [WiX-users] Bundle that upgrades two different bundles (different 
upgrade codes)

Hello,

We have two bundles that represent two localizations of our software product. 
Those will be merged in one localization starting from a specific version. So 
we need a good way to upgrade the two different older bundles to one single new 
bundle. The new bundle should be able to upgrade both previous bundles.

For MSIs this is quite easy to achieve but how can we best do this for bundles 
(since there is only one upgrade code in the bundle element and the 
relatedbundle option seems not usable).

With kind regards,

Rob van Rosmalen B ICT software engineer stabiplan +31 172 65 02 65 
www.stabiplan.nl 
DISCLAIMER

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce Perforce version control. 
Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce Perforce version control. 
Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Intermittent errors setting Windows 8 properties on shortcuts

2014-09-16 Thread John Hall
Hi,

In my installer I have a number of shortcuts installed on the Start Menu that I 
don't want to appear on the Windows 8 start screen. I therefore set both the 
System.AppUserModel.StartPinOption and 
System.AppUserModel.ExcludeFromShowInNewInstall properties for each of these 
shortcuts. My code looks like this:

  

  

  


  


  

Every now and then an installation on Windows 7 will display a dialog saying:

Warning 1946.Property '{9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3}, 12' for shortcut 
'XJTAG Help' could not be set.

The warning ultimately seems benign, but it is not a good user experience. It 
warning is not consistent or reproducible. Any ideas?

Thanks,
John
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] WIX : Upgrade Issue

2014-09-16 Thread Arvind Janghel
Hi,

 

I have implemented major upgrade support in my application installer . As
part of upgrade, there are C# custom actions to backup and restore config
files, and also update the database.

I have scheduled the RemoveExistingProducts after "installinitialize".

 

However the restore configuration fails, with a FileNotFoundException and
the log file suggests that one of the configuration files is not found. The
Restore configuration is scheduled after installfiles and before
installfinalize, hence I wonder as to why the exception occura. 

 

Also I tried changing the custom action, and also removing failing custom
actions, but seems that the upgrade is using "Cached" version of the
installer, since the log file contains log information of removed custom
action

 

Any pointers what could be reason behind failing custom action and why the
cached installer is getting triggered?

 

Thanks,

Arvind

 

 




===
DISCLAIMER:
The information contained in this message (including any attachments) is 
confidential and may be privileged. If you have received it by mistake please 
notify the sender by return e-mail and permanently delete this message and any 
attachments from your system. Any dissemination, use, review, distribution, 
printing or copying of this message in whole or in part is strictly prohibited. 
Please note that e-mails are susceptible to change. CitiusTech shall not be 
liable for the improper or incomplete transmission of the information contained 
in this communication nor for any delay in its receipt or damage to your 
system. CitiusTech does not guarantee that the integrity of this communication 
has been maintained or that this communication is free of viruses, 
interceptions or interferences. 

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WIX : Upgrade Issue

2014-09-16 Thread John Cooper
If no modifications to the config files have been made since they have been 
installed, they will be deleted with your upgrade scheduling before the upgrade 
install.

You can:  1) tweak the timestamp on the config file(s) so they are preserved; 
or 2) have a custom action read the file data to be preserved early in the 
upgrade process and then use that data, stored in properties, to reconstruct 
the config files during the install of the upgraded product.

--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing 
Development
Jack Henry & Associates, Inc.® | Lenexa, KS  66214 | Ext:  431050 
|jocoo...@jackhenry.com



-Original Message-
From: Arvind Janghel [mailto:arvind.jang...@citiustech.com] 
Sent: Tuesday, September 16, 2014 6:07 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WIX : Upgrade Issue

Hi,

 

I have implemented major upgrade support in my application installer . As part 
of upgrade, there are C# custom actions to backup and restore config files, and 
also update the database.

I have scheduled the RemoveExistingProducts after "installinitialize".

 

However the restore configuration fails, with a FileNotFoundException and the 
log file suggests that one of the configuration files is not found. The Restore 
configuration is scheduled after installfiles and before installfinalize, hence 
I wonder as to why the exception occura. 

 

Also I tried changing the custom action, and also removing failing custom 
actions, but seems that the upgrade is using "Cached" version of the installer, 
since the log file contains log information of removed custom action

 

Any pointers what could be reason behind failing custom action and why the 
cached installer is getting triggered?

 

Thanks,

Arvind

 

 




===
DISCLAIMER:
The information contained in this message (including any attachments) is 
confidential and may be privileged. If you have received it by mistake please 
notify the sender by return e-mail and permanently delete this message and any 
attachments from your system. Any dissemination, use, review, distribution, 
printing or copying of this message in whole or in part is strictly prohibited. 
Please note that e-mails are susceptible to change. CitiusTech shall not be 
liable for the improper or incomplete transmission of the information contained 
in this communication nor for any delay in its receipt or damage to your 
system. CitiusTech does not guarantee that the integrity of this communication 
has been maintained or that this communication is free of viruses, 
interceptions or interferences. 

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&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.


--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WIX : Upgrade Issue

2014-09-16 Thread ArvindJanghel
Hi John,

Thanks for the reply.The upgrade used to work well previously..Also i am
sure, that the changes that was done later on, does not break the upgrade.

I already have your suggested approach #2 implemented when the major upgrade
was implemented. 
I have a custom action which takes a backup of config files before the
'RemoveExistingProducts'.

There is another custom action 'RestoreConfiguration' for performing the
restore, after the config files are  installed and before InstallFinalize. I
am getting the FileNotFoundException during this custom action only...

As posted earlier, I feel while upgrade, a cached version of installer is
being used, since some of the changes i made to debug the issue( for e.g.
added extra logging in C# custom action or removing the custom actions
altogether) is not getting reflected. I confirmed this, looking at the
installer log.

Any thoughts?

Thanks,
Arvind

P.S :  I am planning to test the upgrade on a clean machine.



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

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Intermittent errors setting Windows 8 properties on shortcuts

2014-09-16 Thread Rob Mensching
Know Windows Installer issue. Use the GUID of the property instead of the name.

_
 Short replies here. Complete answers over there: http://www.firegiant.com/


-Original Message-
From: John Hall [mailto:john.h...@cambridgetechgroup.com] 
Sent: Tuesday, September 16, 2014 3:11 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Intermittent errors setting Windows 8 properties on 
shortcuts

Hi,

In my installer I have a number of shortcuts installed on the Start Menu that I 
don't want to appear on the Windows 8 start screen. I therefore set both the 
System.AppUserModel.StartPinOption and 
System.AppUserModel.ExcludeFromShowInNewInstall properties for each of these 
shortcuts. My code looks like this:

  

  

  


  


  

Every now and then an installation on Windows 7 will display a dialog saying:

Warning 1946.Property '{9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3}, 12' for shortcut 
'XJTAG Help' could not be set.

The warning ultimately seems benign, but it is not a good user experience. It 
warning is not consistent or reproducible. Any ideas?

Thanks,
John 

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] LGHT0284: Support for more than 260 characthers in Path?

2014-09-16 Thread Rob Mensching
PS: I just remembered, you can change the name of those files in your .wixpproj 
by setting Properties like BindContentsFile, BindOutputsFile, etc.

_
 Short replies here. Complete answers over there: http://www.firegiant.com/


-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com] 
Sent: Monday, September 15, 2014 12:42 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] LGHT0284: Support for more than 260 characthers in 
Path?

We could make those binder data file paths shorter in WiX v4.0.

_
 Short replies here. Complete answers over there: http://www.firegiant.com/
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Intermittent errors setting Windows 8 properties on shortcuts

2014-09-16 Thread John Hall
Rob,

I am using the GUID - it appears in the error message. I've got a define called 
var.Prop_System_AppUserModel_NoPin that I use.

Regards,
John

-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com] 
Sent: 16 September 2014 16:59
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Intermittent errors setting Windows 8 properties on 
shortcuts

Know Windows Installer issue. Use the GUID of the property instead of the name.

_
 Short replies here. Complete answers over there: http://www.firegiant.com/


-Original Message-
From: John Hall [mailto:john.h...@cambridgetechgroup.com] 
Sent: Tuesday, September 16, 2014 3:11 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Intermittent errors setting Windows 8 properties on 
shortcuts

Hi,

In my installer I have a number of shortcuts installed on the Start Menu that I 
don't want to appear on the Windows 8 start screen. I therefore set both the 
System.AppUserModel.StartPinOption and 
System.AppUserModel.ExcludeFromShowInNewInstall properties for each of these 
shortcuts. My code looks like this:

  

  

  


  


  

Every now and then an installation on Windows 7 will display a dialog saying:

Warning 1946.Property '{9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3}, 12' for shortcut 
'XJTAG Help' could not be set.

The warning ultimately seems benign, but it is not a good user experience. It 
warning is not consistent or reproducible. Any ideas?

Thanks,
John 

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] LGHT0284: Support for more than 260 characthers in Path?

2014-09-16 Thread Asbjørn Mikkelsen
Hm, I added those in the same propertygroup as where OutputPath and
IntermediateOutputPath is set, but nothing happens, it generates stil the
same names
Where are those properties listed?, like what is avalable?

In this doc:
http://wixtoolset.org/documentation/manual/v3/overview/light.html
I cant even find the parameter that is fed to light for these files even?,
like these parameters:

 -contentsfile obj\.wixproj.BindContentsFileListnb-NO.txt
 -outputsfile obj\.wixproj.BindOutputsFileListnb-NO.txt
 -builtoutputsfile
obj\.wixproj.BindBuiltOutputsFileListnb-NO.txt

and in the msbuild log, that is the only place I see those names listed..



On Tue, Sep 16, 2014 at 6:00 PM, Rob Mensching  wrote:

> PS: I just remembered, you can change the name of those files in your
> .wixpproj by setting Properties like BindContentsFile, BindOutputsFile, etc.
>
> _
>  Short replies here. Complete answers over there:
> http://www.firegiant.com/
>
>
> -Original Message-
> From: Rob Mensching [mailto:r...@firegiant.com]
> Sent: Monday, September 15, 2014 12:42 PM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] LGHT0284: Support for more than 260 characthers
> in Path?
>
> We could make those binder data file paths shorter in WiX v4.0.
>
> _
>  Short replies here. Complete answers over there:
> http://www.firegiant.com/
>
> --
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
mvh
Asbjørn
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] LGHT0284: Support for more than 260 characthers in Path?

2014-09-16 Thread Asbjørn Mikkelsen
In the wix2010.targets I found CleanFile defined, so I could remap one
file, but further on I found this:


  




  




  



  


So those seems to be built on the fly, instead of getting assigned to an
property as is done with CleanFile..

Same with the Light task inside there:


BindContentsFile="$(IntermediateOutputPath)$(BindContentsFilePrefix)%(CultureGroup.Identity)$(BindContentsFileExtension)"

BindOutputsFile="$(IntermediateOutputPath)$(BindOutputsFilePrefix)%(CultureGroup.Identity)$(BindOutputsFileExtension)"

BindBuiltOutputsFile="$(IntermediateOutputPath)$(BindBuiltOutputsFilePrefix)%(CultureGroup.Identity)$(BindBuiltOutputsFileExtension)"






On Tue, Sep 16, 2014 at 6:41 PM, Asbjørn Mikkelsen 
wrote:

> Hm, I added those in the same propertygroup as where OutputPath and
> IntermediateOutputPath is set, but nothing happens, it generates stil the
> same names
> Where are those properties listed?, like what is avalable?
>
> In this doc:
> http://wixtoolset.org/documentation/manual/v3/overview/light.html
> I cant even find the parameter that is fed to light for these files even?,
> like these parameters:
>
>  -contentsfile obj\.wixproj.BindContentsFileListnb-NO.txt
>  -outputsfile obj\.wixproj.BindOutputsFileListnb-NO.txt
>  -builtoutputsfile
> obj\.wixproj.BindBuiltOutputsFileListnb-NO.txt
>
> and in the msbuild log, that is the only place I see those names listed..
>
>
>
> On Tue, Sep 16, 2014 at 6:00 PM, Rob Mensching  wrote:
>
>> PS: I just remembered, you can change the name of those files in your
>> .wixpproj by setting Properties like BindContentsFile, BindOutputsFile, etc.
>>
>> _
>>  Short replies here. Complete answers over there:
>> http://www.firegiant.com/
>>
>>
>> -Original Message-
>> From: Rob Mensching [mailto:r...@firegiant.com]
>> Sent: Monday, September 15, 2014 12:42 PM
>> To: General discussion about the WiX toolset.
>> Subject: Re: [WiX-users] LGHT0284: Support for more than 260 characthers
>> in Path?
>>
>> We could make those binder data file paths shorter in WiX v4.0.
>>
>> _
>>  Short replies here. Complete answers over there:
>> http://www.firegiant.com/
>>
>> --
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce.
>> Perforce version control. Predictably reliable.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
>
>
> --
> mvh
> Asbjørn
>



-- 
mvh
Asbjørn
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] LGHT0284: Support for more than 260 characthers in Path?

2014-09-16 Thread Rob Mensching
Ahh, I was probably looking at WiX v4.0 targets.

At least you can control the prefix in WiX v3.x targets.
_
 Short replies here. Complete answers over there: http://www.firegiant.com/


-Original Message-
From: Asbjørn Mikkelsen [mailto:asbj...@neslekkim.net] 
Sent: Tuesday, September 16, 2014 10:20 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] LGHT0284: Support for more than 260 characthers in 
Path?

In the wix2010.targets I found CleanFile defined, so I could remap one file, 
but further on I found this:


  




  




  



  


So those seems to be built on the fly, instead of getting assigned to an 
property as is done with CleanFile..

Same with the Light task inside there:


BindContentsFile="$(IntermediateOutputPath)$(BindContentsFilePrefix)%(CultureGroup.Identity)$(BindContentsFileExtension)"

BindOutputsFile="$(IntermediateOutputPath)$(BindOutputsFilePrefix)%(CultureGroup.Identity)$(BindOutputsFileExtension)"

BindBuiltOutputsFile="$(IntermediateOutputPath)$(BindBuiltOutputsFilePrefix)%(CultureGroup.Identity)$(BindBuiltOutputsFileExtension)"

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WIX : Upgrade Issue

2014-09-16 Thread Phil Wilson
Regarding the "wrong custom action" issue: there have been problems in
that area with managed custom actions where the uninstall part of the
upgrade runs first, loading the assembly for that older custom action.
When the new install runs and the loading code comes to load the new
assembly the runtime will not load the assembly because it's the
"same" as the one that's already loaded. If that's what's happening,
using a strong name (or a new one) on the new version of the assembly
should fix it.
---
Phil Wilson


On Tue, Sep 16, 2014 at 7:44 AM, ArvindJanghel
 wrote:
> Hi John,
>
> Thanks for the reply.The upgrade used to work well previously..Also i am
> sure, that the changes that was done later on, does not break the upgrade.
>
> I already have your suggested approach #2 implemented when the major upgrade
> was implemented.
> I have a custom action which takes a backup of config files before the
> 'RemoveExistingProducts'.
>
> There is another custom action 'RestoreConfiguration' for performing the
> restore, after the config files are  installed and before InstallFinalize. I
> am getting the FileNotFoundException during this custom action only...
>
> As posted earlier, I feel while upgrade, a cached version of installer is
> being used, since some of the changes i made to debug the issue( for e.g.
> added extra logging in C# custom action or removing the custom actions
> altogether) is not getting reflected. I confirmed this, looking at the
> installer log.
>
> Any thoughts?
>
> Thanks,
> Arvind
>
> P.S :  I am planning to test the upgrade on a clean machine.
>
>
>
> --
> View this message in context: 
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WIX-Upgrade-Issue-tp7596837p7596839.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
> --
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] LGHT0284: Support for more than 260 characthers in Path?

2014-09-16 Thread Asbjørn Mikkelsen
ah, that worked fine like this:

c
b1
b2
b3


On Tue, Sep 16, 2014 at 7:45 PM, Rob Mensching  wrote:

> Ahh, I was probably looking at WiX v4.0 targets.
>
> At least you can control the prefix in WiX v3.x targets.
> _
>  Short replies here. Complete answers over there:
> http://www.firegiant.com/
>
>
> -Original Message-
> From: Asbjørn Mikkelsen [mailto:asbj...@neslekkim.net]
> Sent: Tuesday, September 16, 2014 10:20 AM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] LGHT0284: Support for more than 260 characthers
> in Path?
>
> In the wix2010.targets I found CleanFile defined, so I could remap one
> file, but further on I found this:
>
> 
> File="$(IntermediateOutputPath)$(BindOutputsFilePrefix)%(CultureGroup.Identity)$(BindOutputsFileExtension)">
>   
> 
>
> 
> Include="$(IntermediateOutputPath)$(BindContentsFilePrefix)%(CultureGroup.Identity)$(BindContentsFileExtension);$(IntermediateOutputPath)$(BindOutputsFilePrefix)%(CultureGroup.Identity)$(BindOutputsFileExtension);$(IntermediateOutputPath)$(BindBuiltOutputsFilePrefix)%(CultureGroup.Identity)$(BindBuiltOutputsFileExtension)">
>
>   
> 
>
>
> 
> File="$(IntermediateOutputPath)$(BindContentsFilePrefix)%(CultureGroup.Identity)$(BindContentsFileExtension)">
>   
> 
>
> 
> File="$(IntermediateOutputPath)$(BindBuiltOutputsFilePrefix)%(CultureGroup.Identity)$(BindBuiltOutputsFileExtension)">
>   
> 
>
> So those seems to be built on the fly, instead of getting assigned to an
> property as is done with CleanFile..
>
> Same with the Light task inside there:
>
>
>
> BindContentsFile="$(IntermediateOutputPath)$(BindContentsFilePrefix)%(CultureGroup.Identity)$(BindContentsFileExtension)"
>
>
> BindOutputsFile="$(IntermediateOutputPath)$(BindOutputsFilePrefix)%(CultureGroup.Identity)$(BindOutputsFileExtension)"
>
>
> BindBuiltOutputsFile="$(IntermediateOutputPath)$(BindBuiltOutputsFilePrefix)%(CultureGroup.Identity)$(BindBuiltOutputsFileExtension)"
>
>
> --
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
mvh
Asbjørn
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WIX : Upgrade Issue

2014-09-16 Thread Rob Mensching
That should not happen with DTF.

_
 Short replies here. Complete answers over there: http://www.firegiant.com/



-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com] 
Sent: Tuesday, September 16, 2014 10:56 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] WIX : Upgrade Issue

Regarding the "wrong custom action" issue: there have been problems in that 
area with managed custom actions where the uninstall part of the upgrade runs 
first, loading the assembly for that older custom action.
When the new install runs and the loading code comes to load the new assembly 
the runtime will not load the assembly because it's the "same" as the one 
that's already loaded. If that's what's happening, using a strong name (or a 
new one) on the new version of the assembly should fix it.
---
Phil Wilson

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Getting the lenght of string in Edit/MaskedEdit field

2014-09-16 Thread Dave Andersen
It sounds like you will need a custom action. I'm pretty sure there is no
built-in way of getting a variable string length.

-Dave

On Fri, Sep 12, 2014 at 10:58 AM, TimM  wrote:

> I have a MaskedEdit control that can either be blank or filled in. If blank
> then next button will continue, but if any characters are entered then I
> only want it to continue if all the required characters are filled in. So
> is
> there some built in method to validate that all characters have been filled
> in or do I actually have to create a custom action that will validate that
> all the characters have been filled in?
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Getting-the-lenght-of-string-in-Edit-MaskedEdit-field-tp7596787.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WIX : Upgrade Issue

2014-09-16 Thread Phil Wilson
It's also not readily obvious (at least to me) that the upgrade path
is actually being taken. It looks like it might be failing and rolling
back quite early. It's probably worth doing a sanity check that the
upgrade logic is correct and it's going down that path. If it went
into maintenance mode then the older CA would run.
---
Phil Wilson


On Tue, Sep 16, 2014 at 12:27 PM, Rob Mensching  wrote:
> That should not happen with DTF.
>
> _
>  Short replies here. Complete answers over there: http://www.firegiant.com/
>
>
>
> -Original Message-
> From: Phil Wilson [mailto:phildgwil...@gmail.com]
> Sent: Tuesday, September 16, 2014 10:56 AM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] WIX : Upgrade Issue
>
> Regarding the "wrong custom action" issue: there have been problems in that 
> area with managed custom actions where the uninstall part of the upgrade runs 
> first, loading the assembly for that older custom action.
> When the new install runs and the loading code comes to load the new assembly 
> the runtime will not load the assembly because it's the "same" as the one 
> that's already loaded. If that's what's happening, using a strong name (or a 
> new one) on the new version of the assembly should fix it.
> ---
> Phil Wilson
>
> --
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Installing VSTO as pre-requisites from Bundle.wxs Failed

2014-09-16 Thread Liz
The VSTO redist package you downloaded via the fwlink is failing signature
verification because it was updated last week, which most likely no longer
matches with the vstor_redist.exe you used to compile your bootstrapper.

Updating the redist source file to the latest version should resolve this
issue. And you might want to consider using a permanent link going forward.

On Mon, Sep 15, 2014 at 4:08 AM, Chetan Rajakumar <
chetan_rajaku...@infosys.com> wrote:

> Hi,Hi,
> I've created a WIX (v3.7.0.0) installer for our VSTO application on Win 7
> 64 bit machine. Which do custom installation successfully. And I've also
> create Bundle.wxs file for installing the prerequisites for VSTO, like .Net
> Framework 4.0 client profile and VSTO 4.0. runtime.
> When I run our exe file it search for VSTO and start download VSTO from
> http://go.microsoft.com/fwlink/?LinkId=158917. but gives the below error
> [0BE8:06F0][2013-08-06T10:49:18]e000: Error 0x80070490: Failed to find
> expected public key in certificate chain.
> [0BE8:06F0][2013-08-06T10:49:18]e000: Error 0x80070490: Failed to verify
> expected payload against actual certificate chain.
> [0BE8:06F0][2013-08-06T10:49:18]e000: Error 0x80070490: Failed to verify
> signature of payload: VSTORuntime
> [0BE8:06F0][2013-08-06T10:49:18]e310: Failed to verify payload:
> VSTORuntime at path: C:\ProgramData\Package Cache\.unverified\VSTORuntime,
> error: 0x80070490. Deleting file.
> [0BE8:06F0][2013-08-06T10:49:18]e000: Error 0x80070490: Failed to cache
> payload: VSTORuntime
> [15CC:0568][2013-08-06T10:49:18]e314: Failed to cache payload: VSTORuntime
> from working path:
> C:\Users\UA17C9~1.JAI\AppData\Local\Temp\{f3bea074-7c76-4831-b8ed-22021127ba0d}\VSTORuntime,
> error: 0x80070490.
> [15CC:0568][2013-08-06T10:49:18]e349: Application requested retry of
> payload: VSTORuntime, encountered error: 0x80070490. Retrying...
> Installer do above same step for 3 times and then finally show error
> message and stop the installation.
> Don't know why this is happening. And we need to install VSTO 4.0 Runtime
> automatically. When I run "vstor_redist.exe" manually, it runs successfully.
> * Code is as below:
> Bundle.wxs
>  Manufacturer="$(var.Manufacturer)" UpgradeCode="$(var.UpgradeCode)"
>   IconSourceFile="$(var.ResourceFiles)\Icon.ico">
>Id="WixStandardBootstrapperApplication.RtfLicense">
>   LogoFile="$(var.ResourceFiles)\BootStrap Logo.bmp" SuppressOptionsUI="yes"
> LicenseFile="Confidential.rtf" />
>   
>Key="SOFTWARE\Wow6432Node\Microsoft\VSTO Runtime Setup\v4\" Value="Version"
> Variable="VSTORVersionV4"/>
>Key="SOFTWARE\Wow6432Node\Microsoft\VSTO Runtime Setup\v4M\"
> Value="VSTORFeature_CLR40" Variable="VSTORFeature"/>
>Key="SOFTWARE\Wow6432Node\Microsoft\VSTO Runtime Setup\v4R\"
> Value="Version" Variable="VSTORVersionV4R"/>
>Key="SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Client" Value="Install"
> Variable="DotNetInstall"/>
>Key="SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Client" Value="Version"
> Variable="DotNetVersion"/>
>
>   
>   SourceFile="$(var.PreReqPath)\DotNetFX40Client\dotNetFx40_Client_x86_x64.exe"
> PerMachine="yes" Cache="no"
>   Compressed="no"
>   DownloadUrl="
> http://download.microsoft.com/download/7/B/6/7B629E05-399A-4A92-B5BC-484C74B5124B/dotNetFx40_Client_setup.exe
> "
>   Permanent="yes"
>   InstallCommand="/q /norestart"
>   DetectCondition="NOT DotNetInstall"
>   InstallCondition="NOT DotNetInstall
> OR NOT (DotNetVersion >=v4.0.30319)" />
>   SourceFile="$(var.PreReqPath)\VSTOR40\vstor_redist.exe" Permanent="yes"
> Vital="yes" Cache="no" Compressed="no"
>   DownloadUrl="
> http://go.microsoft.com/fwlink/?LinkId=158917";
>   PerMachine="yes"
>   InstallCommand="/q /norestart"
>   DetectCondition="VSTORFeature"
>   InstallCondition="NOT VSTORFeature
> OR NOT (VSTORVersionV4R >=v10.0.40303) OR NOT (VSTORVersionV4
> >=v10.0.21022) "/>
>   Vital="yes" Compressed="yes" Id="WordAddIns" DisplayInternalUI="yes" />
>   
>
>
>
> Any help appreciated.
>
> Thanks & Regards,
> Chetan Rajakumar
>
>  CAUTION - Disclaimer *
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
> solely
> for the use of the addressee(s). If you are not the intended recipient,
> please
> notify the sender by e-mail and delete the original message. Further, you
> are not
> to copy, discl

[WiX-users] WiX 3.8 MakeSfxCA.exe exited with code 3

2014-09-16 Thread Robert Harrison
Wix Users,

My project will not building due to the following error. I have searched to 
find answer but found nothing satisfactory.

What I did find was that code 3 is a "file not found" code. Is that correct?

Anyone seen this before?

T:\Wix\v3.8.1128.0\sdk\Wix.CA.targets(141,5): error MSB3073: The command 
""T:\Wix\v3.8.1128.0..\sdk\MakeSfxCA.exe" 
"h:\planb\buildp1\sccm_main\layout\CustomAction\obj\Release\MyCo.ConfigMgr.CustomAction.CA.dll"
 "T:\Wix\v3.8.1128.0..\sdk\x86\SfxCA.dll" 
"h:\planb\buildp1\sccm_main\layout\CustomAction\obj\Release\MyCo.ConfigMgr.CustomAction.dll"
 
"h:\planb\buildp1\sccm_main\Out\Release\Microsoft.Deployment.WindowsInstaller.dll;h:\planb\buildp1\sccm_main\layout\CustomAction\CustomAction.config""
 exited with code 3. 
[h:\planb\buildp1\sccm_main\layout\CustomAction\ConfigMgr.CustomAction.2010.csproj]

-Robert
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WiX 3.8 MakeSfxCA.exe exited with code 3

2014-09-16 Thread Robert Harrison
After some more digging, I found this post (http://wixtoolset.org/issues/4277/) 
about a bug in Wix 3.8. I'm not allowed to make this change due to our 
distributed build system, but can someone confirm that this workaround is 
correct?

-Robert

-Original Message-
From: Robert Harrison [mailto:robert.harri...@citrix.com] 
Sent: Tuesday, September 16, 2014 4:39 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX 3.8 MakeSfxCA.exe exited with code 3

Wix Users,

My project will not building due to the following error. I have searched to 
find answer but found nothing satisfactory.

What I did find was that code 3 is a "file not found" code. Is that correct?

Anyone seen this before?

T:\Wix\v3.8.1128.0\sdk\Wix.CA.targets(141,5): error MSB3073: The command 
""T:\Wix\v3.8.1128.0..\sdk\MakeSfxCA.exe" 
"h:\planb\buildp1\sccm_main\layout\CustomAction\obj\Release\MyCo.ConfigMgr.CustomAction.CA.dll"
 "T:\Wix\v3.8.1128.0..\sdk\x86\SfxCA.dll" 
"h:\planb\buildp1\sccm_main\layout\CustomAction\obj\Release\MyCo.ConfigMgr.CustomAction.dll"
 
"h:\planb\buildp1\sccm_main\Out\Release\Microsoft.Deployment.WindowsInstaller.dll;h:\planb\buildp1\sccm_main\layout\CustomAction\CustomAction.config""
 exited with code 3. 
[h:\planb\buildp1\sccm_main\layout\CustomAction\ConfigMgr.CustomAction.2010.csproj]

-Robert
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WiX 3.8 MakeSfxCA.exe exited with code 3

2014-09-16 Thread John H Bergman (XPedient)
I've used the workaround with success.

-Original Message-
From: Robert Harrison [mailto:robert.harri...@citrix.com] 
Sent: Tuesday, September 16, 2014 6:55 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] WiX 3.8 MakeSfxCA.exe exited with code 3

After some more digging, I found this post (http://wixtoolset.org/issues/4277/) 
about a bug in Wix 3.8. I'm not allowed to make this change due to our 
distributed build system, but can someone confirm that this workaround is 
correct?

-Robert

-Original Message-
From: Robert Harrison [mailto:robert.harri...@citrix.com] 
Sent: Tuesday, September 16, 2014 4:39 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX 3.8 MakeSfxCA.exe exited with code 3

Wix Users,

My project will not building due to the following error. I have searched to 
find answer but found nothing satisfactory.

What I did find was that code 3 is a "file not found" code. Is that correct?

Anyone seen this before?

T:\Wix\v3.8.1128.0\sdk\Wix.CA.targets(141,5): error MSB3073: The command 
""T:\Wix\v3.8.1128.0..\sdk\MakeSfxCA.exe" 
"h:\planb\buildp1\sccm_main\layout\CustomAction\obj\Release\MyCo.ConfigMgr.CustomAction.CA.dll"
 "T:\Wix\v3.8.1128.0..\sdk\x86\SfxCA.dll" 
"h:\planb\buildp1\sccm_main\layout\CustomAction\obj\Release\MyCo.ConfigMgr.CustomAction.dll"
 
"h:\planb\buildp1\sccm_main\Out\Release\Microsoft.Deployment.WindowsInstaller.dll;h:\planb\buildp1\sccm_main\layout\CustomAction\CustomAction.config""
 exited with code 3. 
[h:\planb\buildp1\sccm_main\layout\CustomAction\ConfigMgr.CustomAction.2010.csproj]

-Robert
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WiX 3.8 MakeSfxCA.exe exited with code 3

2014-09-16 Thread Robert Harrison
Does anyone know why this workaround is only needed on Win 7?

-Original Message-
From: John H Bergman (XPedient) [mailto:john.berg...@xpdnt.com] 
Sent: Tuesday, September 16, 2014 5:31 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] WiX 3.8 MakeSfxCA.exe exited with code 3

I've used the workaround with success.

-Original Message-
From: Robert Harrison [mailto:robert.harri...@citrix.com]
Sent: Tuesday, September 16, 2014 6:55 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] WiX 3.8 MakeSfxCA.exe exited with code 3

After some more digging, I found this post (http://wixtoolset.org/issues/4277/) 
about a bug in Wix 3.8. I'm not allowed to make this change due to our 
distributed build system, but can someone confirm that this workaround is 
correct?

-Robert

-Original Message-
From: Robert Harrison [mailto:robert.harri...@citrix.com]
Sent: Tuesday, September 16, 2014 4:39 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX 3.8 MakeSfxCA.exe exited with code 3

Wix Users,

My project will not building due to the following error. I have searched to 
find answer but found nothing satisfactory.

What I did find was that code 3 is a "file not found" code. Is that correct?

Anyone seen this before?

T:\Wix\v3.8.1128.0\sdk\Wix.CA.targets(141,5): error MSB3073: The command 
""T:\Wix\v3.8.1128.0..\sdk\MakeSfxCA.exe" 
"h:\planb\buildp1\sccm_main\layout\CustomAction\obj\Release\MyCo.ConfigMgr.CustomAction.CA.dll"
 "T:\Wix\v3.8.1128.0..\sdk\x86\SfxCA.dll" 
"h:\planb\buildp1\sccm_main\layout\CustomAction\obj\Release\MyCo.ConfigMgr.CustomAction.dll"
 
"h:\planb\buildp1\sccm_main\Out\Release\Microsoft.Deployment.WindowsInstaller.dll;h:\planb\buildp1\sccm_main\layout\CustomAction\CustomAction.config""
 exited with code 3. 
[h:\planb\buildp1\sccm_main\layout\CustomAction\ConfigMgr.CustomAction.2010.csproj]

-Robert
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce Perforce version control. 
Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WiX 3.8 MakeSfxCA.exe exited with code 3

2014-09-16 Thread Robert Harrison
I probably should add details about my previous question. I'm using WiX 3.8 on 
my local dev machine running Win 8.2 and everything is building fine. Our build 
machines were apparently using Win XP and this bug reared its head today when 
we upgraded our build machines to Win 7. What changed in the OS to make this 
happen specifically on Win7?

-Original Message-
From: Robert Harrison [mailto:robert.harri...@citrix.com] 
Sent: Tuesday, September 16, 2014 5:36 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] WiX 3.8 MakeSfxCA.exe exited with code 3

Does anyone know why this workaround is only needed on Win 7?

-Original Message-
From: John H Bergman (XPedient) [mailto:john.berg...@xpdnt.com]
Sent: Tuesday, September 16, 2014 5:31 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] WiX 3.8 MakeSfxCA.exe exited with code 3

I've used the workaround with success.

-Original Message-
From: Robert Harrison [mailto:robert.harri...@citrix.com]
Sent: Tuesday, September 16, 2014 6:55 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] WiX 3.8 MakeSfxCA.exe exited with code 3

After some more digging, I found this post (http://wixtoolset.org/issues/4277/) 
about a bug in Wix 3.8. I'm not allowed to make this change due to our 
distributed build system, but can someone confirm that this workaround is 
correct?

-Robert

-Original Message-
From: Robert Harrison [mailto:robert.harri...@citrix.com]
Sent: Tuesday, September 16, 2014 4:39 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX 3.8 MakeSfxCA.exe exited with code 3

Wix Users,

My project will not building due to the following error. I have searched to 
find answer but found nothing satisfactory.

What I did find was that code 3 is a "file not found" code. Is that correct?

Anyone seen this before?

T:\Wix\v3.8.1128.0\sdk\Wix.CA.targets(141,5): error MSB3073: The command 
""T:\Wix\v3.8.1128.0..\sdk\MakeSfxCA.exe" 
"h:\planb\buildp1\sccm_main\layout\CustomAction\obj\Release\MyCo.ConfigMgr.CustomAction.CA.dll"
 "T:\Wix\v3.8.1128.0..\sdk\x86\SfxCA.dll" 
"h:\planb\buildp1\sccm_main\layout\CustomAction\obj\Release\MyCo.ConfigMgr.CustomAction.dll"
 
"h:\planb\buildp1\sccm_main\Out\Release\Microsoft.Deployment.WindowsInstaller.dll;h:\planb\buildp1\sccm_main\layout\CustomAction\CustomAction.config""
 exited with code 3. 
[h:\planb\buildp1\sccm_main\layout\CustomAction\ConfigMgr.CustomAction.2010.csproj]

-Robert
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce Perforce version control. 
Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce Perforce version control. 
Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users