[WiX-users] Relative path sometimes used for WiX extension references.

2014-04-11 Thread John Ludlow 
Hi,

When I add a reference to WixUtilExtension in my WiX project, this is what
gets added to the .wixproj:


   
  $(WixExtDir)\WixUtilExtension.dll
  WixUtilExtension
   


When my colleague does this, he sometimes gets the above, but usually gets
this:


  

..\..\..\..\..\..\..\..\..\..\..\..\..\Program Files (x86)\WiX Toolset
v3.8\bin\WixUtilExtension.dll

WixUtilExtension
  


Which causes an error for me. Although we both have WiX 3.8 installed to
the default location (c:\Program Files (x86)\WiX Toolset v3.8) I have all
my source on a different drive, so that's where the relative path starts
from. Since there's no way that a relative path will ever be able to
reference a file on a different drive, it fails on my machine.

My colleague is having to check his project changes carefully to make sure
he doesn't accidentally break it, and we think the tools could help us
more. I'm pretty sure that in his case Votive is thinking "aha, I can draw
a relative path from here to there!" and just using that, while in my case
it's deciding it can't possibly do that so it's falling back on whatever
$(var.WixExtDir) tells it to do.

I found a bug (http://sourceforge.net/p/wix/bugs/2209/) on SourceForge, but
though it says "migrated" I was unable to find a bug on the new bug
tracking system. The closest I could find was this one :
http://wixtoolset.org/issues/2834/ but that's a totally separate issue. I
wonder if 2209 got lost along the way from SF to the new system. Should I
create it in the new system?

In terms of a fix, I feel like it should always use $(WixExtDir) regardless
of whether a relative path *could* be used.

Meanwhile, we have to decide how to handle it on our side until it's fixed.
We have tools that we could use to check this for us, but that's less than
ideal. We could also do what this guy does :
http://wixtoolset.org/issues/2834/ and keep our WiX toolset in source
control but for various reasons we didn't want to do that.

Any ideas?

Thanks
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Environment variable "ProjectPath" is expanded, possible to turn off?

2014-04-11 Thread Phill Hogland 
When:
1) A cmd prompt is opened (in this case using the VS2010 CMD prompt)
2) A batch file which has setlocal also has a "set
projectPath=some_path_to_a_folder" (case of the variable name does not
matter)
3) And at some point in the same batch file or a different batch file (also
using setlocal) but executed in the same CMD window, then light.exe
generates LGHT0281 with the message "error LGHT0281: The -wixprojectfile
option requires a file, but the provided path is a directory: "  It also displays the full path to the
project file, including the project fil name, as passed into MSBuild.  So
the message is confusing.

Even after the variable in the batch script is removed or renamed, LGHT0281
error continues to be reported until the CMD window is closed and the
changed batch file is executed in a new CMD window.

While this behavior is a little different than the original post, the core
issue seems to be that variables in batch scripts, even different batch
scripts run in a particular CMD window, are in the same namespace as
environment variables and MSBuild variable, so it would be wise to prefix
variable names in a unique manner.  



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Environment-variable-ProjectPath-is-expanded-possible-to-turn-off-tp7587463p7594066.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Harvesting Performance Counters with Heat

2014-04-11 Thread David Allen 
Apologies in advance for the noob question - I HAVE tried various options but 
I'm stuck!

I have a C# project (VS 2010) that creates a .NET DLL containing (amongst other 
things) a number of performance counters all in a single category. I'd like to 
harvest them using heat.exe rather than having to transcribe the details from 
the .NET designer to my .wxs file.

I've tried executing heat.exe perf PerformanceCategoryName -o perf.wxs in 
various directories within the projects and every time it comes back with 
"heat.exe : error HEAT5060 : Performance category 'PerformanceCategoryName' not 
found."

I'm clearly missing something but what?

Many thanks in advance
David

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Harvesting Performance Counters with Heat

2014-04-11 Thread Neil Sleightholm 
I think you have to register the performance counters using the .NET tools
and then harvest them.

Neil


>Apologies in advance for the noob question - I HAVE tried various options
>but I'm stuck!
>
>I have a C# project (VS 2010) that creates a .NET DLL containing (amongst
>other things) a number of performance counters all in a single category.
>I'd like to harvest them using heat.exe rather than having to transcribe
>the details from the .NET designer to my .wxs file.
>
>I've tried executing heat.exe perf PerformanceCategoryName -o perf.wxs in
>various directories within the projects and every time it comes back with
>"heat.exe : error HEAT5060 : Performance category
>'PerformanceCategoryName' not found."
>
>I'm clearly missing something but what?
>
>Many thanks in advance
>David
>
>--
>
>Put Bad Developers to Shame
>Dominate Development with Jenkins Continuous Integration
>Continuously Automate Build, Test & Deployment
>Start a new project now. Try Jenkins in the cloud.
>http://p.sf.net/sfu/13600_Cloudbees
>___
>WiX-users mailing list
>WiX-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/wix-users


--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] advertised install and user permissions

2014-04-11 Thread Phill Hogland 
Yes, the MSI package has the following:



When this package is launched as part of the bundle chain the log indicates
that ALLUSERS is 1.

This package has been installing with the feature advertized, but without
complaining about this registry value for some time.  However I recently
refactored some of the wxs files to make then more maintainable, and I moved
this registry key to a different fragment, but also associated with the same
advertised feature.

This old code, which did not result in an error, and the key was written
during the advertised portion of the install:


  

  

  

This is the current code which does result in the error (but only when being
installed as result of advertised feature):
  

  

  

  

I also found that I can add AllowAdvertise="no" to the feature and avoid the
problem, but I appreciate any advice so that I can understand this behavior
and learn the best practices to avoid this problem.



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058p7594070.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Can a Wixlib contain a merge module?

2014-04-11 Thread TimM 
Thanks Rob...

It actually turned out to be the first build I did from TeamCity did not
link in the merge module as it did not have access to it at the time. So the
wixlib that went into the parent just did not have the merge module to
install.

So I re-verified with the latest build and it correctly linked in the merge
module and installed correctly. So everything is working fine now



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Can-a-Wixlib-contain-a-merge-module-tp7594055p7594071.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Testing for Version Numbers??

2014-04-11 Thread Carter Young 
It worked...

Quoting Carter Young :

> I'm aiming for RuntimeVersion <=13.0.8, I'll give this a try tomorrow...
>
> Carter
>
> On Thursday, April 10, 2014 04:49:47 PM Phill Hogland wrote:
>> In the prior post I meant to have the entity display:
>> InstallCondition="RuntimeVersion <=vx.x.x.x"
>>
>>
>>
>> --
>> View this message in context:  
>> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Testing-for-Version-Numbers-tp7594059p7594061.html
>> Sent from the wix-users mailing list archive at Nabble.com.
>>
>> --
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>
> --
> There is one difference between a tax collector and a taxidermist --
> the taxidermist leaves the hide.
>   -- Mortimer Caplan
>
>
> --
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>




--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Best Practice for Updating UI from Custom Action

2014-04-11 Thread Arthur, Christopher 
Hi,

I would like to know, what's the best Way for Updating PeogressBar and 
StatusText From c# Custom Action.

Sincerly
Chris

Wichtiger Hinweis: Diese E-Mail und etwa angehängte Dateien können vertrauliche 
Informationen enthalten und sind ausschließlich für den/die Adressaten 
bestimmt. Sollten Sie irrtümlich diese E-Mail erhalten haben, bitten wir Sie, 
uns darüber zu informieren und die E-Mail aus Ihrem System zu löschen. Das 
unerlaubte Kopieren und die unbefugte Weitergabe dieser Mail und ihrer Inhalte 
sind nicht gestattet.

Important notice: This email and some of the attached files can contain 
confidential information and are intended solely for the addressee. Should you 
have received this email in error, we ask that you inform us about this and 
delete the email from your system. The illegal copying and unauthorised 
re-distribution of this email and its contents are not permitted.
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Adding msi/exe packages outside the burn chain

2014-04-11 Thread gowri.malasani 
Thanks Rob. Is there a work around to achieve this?

-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com] 
Sent: Thursday, April 10, 2014 11:34 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain

No. Burn provides a very strong security statement for the contained packages. 
If you add packages, you'll want to update the bundle to include them in the 
chain or include the additional packages in a related bundle and launch them in 
succession.

___
 FireGiant  |  Dedicated support for the WiX toolset  |  
http://www.firegiant.com/

-Original Message-
From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com]
Sent: Thursday, April 10, 2014 4:04 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Adding msi/exe packages outside the burn chain

Hi, Is there anyway burn can handle installing/uninstalling exe/msi packages 
which are not part of the chain. In other words these msi/exe packages will be 
added later at runtime.

Currently, I have bunch of MSIs I run part of my burn chain, but the 
requirement is that burn should be able to pick additional MSIs added to media 
at later point in time.

Thanks
Gowri
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration Continuously Automate 
Build, Test & Deployment Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration Continuously Automate 
Build, Test & Deployment Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Adding msi/exe packages outside the burn chain

2014-04-11 Thread Rob Mensching 
Is there a way to bypass the security features of the Burn engine designed to 
prevent evil people from slipping malware into your Bundle? I certainly hope 
not. If you find such a bug, please do let us know.

___
 FireGiant  |  Dedicated support for the WiX toolset  |  
http://www.firegiant.com/

-Original Message-
From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com] 
Sent: Friday, April 11, 2014 10:26 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain

Thanks Rob. Is there a work around to achieve this?

-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: Thursday, April 10, 2014 11:34 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain

No. Burn provides a very strong security statement for the contained packages. 
If you add packages, you'll want to update the bundle to include them in the 
chain or include the additional packages in a related bundle and launch them in 
succession.

___
 FireGiant  |  Dedicated support for the WiX toolset  |  
http://www.firegiant.com/

-Original Message-
From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com]
Sent: Thursday, April 10, 2014 4:04 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Adding msi/exe packages outside the burn chain

Hi, Is there anyway burn can handle installing/uninstalling exe/msi packages 
which are not part of the chain. In other words these msi/exe packages will be 
added later at runtime.

Currently, I have bunch of MSIs I run part of my burn chain, but the 
requirement is that burn should be able to pick additional MSIs added to media 
at later point in time.

Thanks
Gowri
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration Continuously Automate 
Build, Test & Deployment Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration Continuously Automate 
Build, Test & Deployment Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration Continuously Automate 
Build, Test & Deployment Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Adding msi/exe packages outside the burn chain

2014-04-11 Thread gowri.malasani 
Got it. Thank you Rob.

-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com] 
Sent: Friday, April 11, 2014 10:38 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain

Is there a way to bypass the security features of the Burn engine designed to 
prevent evil people from slipping malware into your Bundle? I certainly hope 
not. If you find such a bug, please do let us know.

___
 FireGiant  |  Dedicated support for the WiX toolset  |  
http://www.firegiant.com/

-Original Message-
From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com]
Sent: Friday, April 11, 2014 10:26 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain

Thanks Rob. Is there a work around to achieve this?

-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: Thursday, April 10, 2014 11:34 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain

No. Burn provides a very strong security statement for the contained packages. 
If you add packages, you'll want to update the bundle to include them in the 
chain or include the additional packages in a related bundle and launch them in 
succession.

___
 FireGiant  |  Dedicated support for the WiX toolset  |  
http://www.firegiant.com/

-Original Message-
From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com]
Sent: Thursday, April 10, 2014 4:04 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Adding msi/exe packages outside the burn chain

Hi, Is there anyway burn can handle installing/uninstalling exe/msi packages 
which are not part of the chain. In other words these msi/exe packages will be 
added later at runtime.

Currently, I have bunch of MSIs I run part of my burn chain, but the 
requirement is that burn should be able to pick additional MSIs added to media 
at later point in time.

Thanks
Gowri
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration Continuously Automate 
Build, Test & Deployment Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration Continuously Automate 
Build, Test & Deployment Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration Continuously Automate 
Build, Test & Deployment Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration Continuously Automate 
Build, Test & Deployment Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Best Practice for Updating UI from Custom Action

2014-04-11 Thread Phil Wilson 
The general methodology is here:

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

That covers the APIs which probably have C# mappings in DTF (if that's
what you're using)

The status text comes from the ActionText MSI table, WiX ProgressText.
The format is templated and many setups use standard lists of actions.
You don't need any code to show your custom action in the status, it's
just an action in ProgressText with whatever text you want to provide.
If you have the need to dynamically provide your own text, see this:

http://stackoverflow.com/questions/11722541/wix-dynamically-changing-the-status-text-during-customaction


---
Phil Wilson


On Fri, Apr 11, 2014 at 9:53 AM, Arthur, Christopher
 wrote:
> Hi,
>
> I would like to know, what's the best Way for Updating PeogressBar and 
> StatusText From c# Custom Action.
>
> Sincerly
> Chris
>
> Wichtiger Hinweis: Diese E-Mail und etwa angehängte Dateien können 
> vertrauliche Informationen enthalten und sind ausschließlich für den/die 
> Adressaten bestimmt. Sollten Sie irrtümlich diese E-Mail erhalten haben, 
> bitten wir Sie, uns darüber zu informieren und die E-Mail aus Ihrem System zu 
> löschen. Das unerlaubte Kopieren und die unbefugte Weitergabe dieser Mail und 
> ihrer Inhalte sind nicht gestattet.
>
> Important notice: This email and some of the attached files can contain 
> confidential information and are intended solely for the addressee. Should 
> you have received this email in error, we ask that you inform us about this 
> and delete the email from your system. The illegal copying and unauthorised 
> re-distribution of this email and its contents are not permitted.
> --
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] advertised install and user permissions

2014-04-11 Thread Phil Wilson 
When you say it's advertised, I'm not sure whether you're referring to
other users on the machine, and if some of the scenarios are about an
administrator doing a repair but a limited user can't use the
advertised feature correctly.

If it's registry data intended for different users it typically goes
into HKCU so that each new user gets the data when they use the
feature.  Windows Installer does not violate security rules, so if the
basic situation is that a limited user is doing something that
installs registry data to HKLM then I can't see that working without
some administrator blessing somewhere (such as via group policy).

You probably need logging policy set to get log for these spontaneous
repair-type situations:

http://support.microsoft.com/kb/223300

or the issue might be that you're using * in MsiLogging, which seems
to like * so spell out the options:

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


---
Phil Wilson


On Fri, Apr 11, 2014 at 6:20 AM, Phill Hogland  wrote:
> Yes, the MSI package has the following:
>
>InstallerVersion="500"
>   Compressed="yes" InstallScope="perMachine"
>   SummaryCodepage="!(loc.SummaryCodepage)" />
>
> When this package is launched as part of the bundle chain the log indicates
> that ALLUSERS is 1.
>
> This package has been installing with the feature advertized, but without
> complaining about this registry value for some time.  However I recently
> refactored some of the wxs files to make then more maintainable, and I moved
> this registry key to a different fragment, but also associated with the same
> advertised feature.
>
> This old code, which did not result in an error, and the key was written
> during the advertised portion of the install:
> 
> 
>   
>  Value="0" Type="integer" KeyPath="yes" />
>   
> 
>   
>
> This is the current code which does result in the error (but only when being
> installed as result of advertised feature):
>   
>  Directory="$(var.ProductDir)">
>   
>  Name="SDA" Value="[SDA]" Type="integer" KeyPath="yes" />
>   
> 
>   
>
> I also found that I can add AllowAdvertise="no" to the feature and avoid the
> problem, but I appreciate any advice so that I can understand this behavior
> and learn the best practices to avoid this problem.
>
>
>
> --
> View this message in context: 
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058p7594070.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
> --
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] advertised install and user permissions

2014-04-11 Thread Phil Wilson 
...ooops  MsiLogging, which seems NOT to like * so spell out the options..
---
Phil Wilson


On Fri, Apr 11, 2014 at 12:01 PM, Phil Wilson  wrote:
> When you say it's advertised, I'm not sure whether you're referring to
> other users on the machine, and if some of the scenarios are about an
> administrator doing a repair but a limited user can't use the
> advertised feature correctly.
>
> If it's registry data intended for different users it typically goes
> into HKCU so that each new user gets the data when they use the
> feature.  Windows Installer does not violate security rules, so if the
> basic situation is that a limited user is doing something that
> installs registry data to HKLM then I can't see that working without
> some administrator blessing somewhere (such as via group policy).
>
> You probably need logging policy set to get log for these spontaneous
> repair-type situations:
>
> http://support.microsoft.com/kb/223300
>
> or the issue might be that you're using * in MsiLogging, which seems
> to like * so spell out the options:
>
> http://msdn.microsoft.com/en-us/library/aa370322(v=vs.85).aspx
>
>
> ---
> Phil Wilson
>
>
> On Fri, Apr 11, 2014 at 6:20 AM, Phill Hogland  wrote:
>> Yes, the MSI package has the following:
>>
>> >   InstallerVersion="500"
>>   Compressed="yes" InstallScope="perMachine"
>>   SummaryCodepage="!(loc.SummaryCodepage)" />
>>
>> When this package is launched as part of the bundle chain the log indicates
>> that ALLUSERS is 1.
>>
>> This package has been installing with the feature advertized, but without
>> complaining about this registry value for some time.  However I recently
>> refactored some of the wxs files to make then more maintainable, and I moved
>> this registry key to a different fragment, but also associated with the same
>> advertised feature.
>>
>> This old code, which did not result in an error, and the key was written
>> during the advertised portion of the install:
>> 
>> 
>>   
>> > Value="0" Type="integer" KeyPath="yes" />
>>   
>> 
>>   
>>
>> This is the current code which does result in the error (but only when being
>> installed as result of advertised feature):
>>   
>> > Directory="$(var.ProductDir)">
>>   
>> > Name="SDA" Value="[SDA]" Type="integer" KeyPath="yes" />
>>   
>> 
>>   
>>
>> I also found that I can add AllowAdvertise="no" to the feature and avoid the
>> problem, but I appreciate any advice so that I can understand this behavior
>> and learn the best practices to avoid this problem.
>>
>>
>>
>> --
>> View this message in context: 
>> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058p7594070.html
>> Sent from the wix-users mailing list archive at Nabble.com.
>>
>> --
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Adding msi/exe packages outside the burn chain

2014-04-11 Thread Rob Mensching 
Note: there have been discussions about adding a feature called "modifiable 
chain" to Burn. However, the security implications are massively challenging 
and backwards compatibility would be ratcheted up. At this point, is far more 
straight forward and secure to distribute an updated bundle. Since Burn is so 
smart about sharing packages, updates where most of the packages are already on 
the machine are really fast.

___
 FireGiant  |  Dedicated support for the WiX toolset  |  
http://www.firegiant.com/

-Original Message-
From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com] 
Sent: Friday, April 11, 2014 11:54 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain

Got it. Thank you Rob.

-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: Friday, April 11, 2014 10:38 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain

Is there a way to bypass the security features of the Burn engine designed to 
prevent evil people from slipping malware into your Bundle? I certainly hope 
not. If you find such a bug, please do let us know.

___
 FireGiant  |  Dedicated support for the WiX toolset  |  
http://www.firegiant.com/

-Original Message-
From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com]
Sent: Friday, April 11, 2014 10:26 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain

Thanks Rob. Is there a work around to achieve this?

-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: Thursday, April 10, 2014 11:34 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain

No. Burn provides a very strong security statement for the contained packages. 
If you add packages, you'll want to update the bundle to include them in the 
chain or include the additional packages in a related bundle and launch them in 
succession.

___
 FireGiant  |  Dedicated support for the WiX toolset  |  
http://www.firegiant.com/

-Original Message-
From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com]
Sent: Thursday, April 10, 2014 4:04 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Adding msi/exe packages outside the burn chain

Hi, Is there anyway burn can handle installing/uninstalling exe/msi packages 
which are not part of the chain. In other words these msi/exe packages will be 
added later at runtime.

Currently, I have bunch of MSIs I run part of my burn chain, but the 
requirement is that burn should be able to pick additional MSIs added to media 
at later point in time.

Thanks
Gowri
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration Continuously Automate 
Build, Test & Deployment Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration Continuously Automate 
Build, Test & Deployment Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration Continuously Automate 
Build, Test & Deployment Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration Continuously Automate 
Build, Test & Deployment Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration Conti

[WiX-users] unsubscribe

2014-04-11 Thread Tom McMillan 

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Util:XmlFile Custom Action Displaying Sensitive Information in Log Files

2014-04-11 Thread Kevin Spence 
Hi all,
How does one handle the situation where the Util:XmlFile custom action logs
sensitive information to the log file?

Eg:

MSI (s) (F8:8C) [11:43:03:072]: Executing op:
ActionStart(Name=ExecXmlFile,,)
MSI (s) (F8:8C) [11:43:03:074]: Executing op:
CustomActionSchedule(Action=ExecXmlFile,ActionType=3073,Source=BinaryData,Target=ExecXmlFile,CustomActionData=2€0€C:\Program
Files\ABC\File.exe.config€3€0€//configuration/connectionStrings/add[@name='ABC']€connectionString€User
ID=user;Password='q9h581)D3]';)


This 
message
by
RobM suggests that the situation is a bug. (Dec 2012)

It looks like this issue was addressed previously
(bug3859),
but the result was that it is not a bug by Bob Arnson (Oct 2013).

I found the workaround hack of adjusting the Type in the CustomAction table
for the ExecXmlFile Action after the msi is produced... Is this the only
way?

Thanks,
Kevin
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] advertised install and user permissions

2014-04-11 Thread Phill Hogland 
I don't want to violate the security.  The applications in the bundle were
installed on the first install in a per-machine install.  Burn was elevated
at the UAC prompt. There are many other keys which are part of this app
which are also written under HKLM.  (I am not intending to do a per-user
install.)

However in one MSI package in my bundle chain, the only Feature had:


and there is a shortcut on the desktop which is advertised.

So for some time now (testing on Windows 8) I run the bundle and all
packages get installed, but the files related to this particular package do
not get installed, until after the bundle completes and I click on the
application's desktop shortcut.  At which point msiexec launches the package
to do what I am calling the 'advertised' install of the files, and then
launches the application.  (I did not realize that it is a 'repair' if that
is the case.)  So these registry keys that write to HKLM have been part of
the package for some time, but only recently does this one fragment, which I
moved from one wxs to another wxs file start displaying this error.  The log
for this package when Burn is running is verbose, but when the shortcut
launches msiexec only the error line is displayed.  I will work on this more
next week.

Since I want to install the application on a per-machine basis (and write
config info to HKLM) it sounds like I should not allow the feature to be
advertised (or go back to the application developer and get them to write
the application so that interaction with HKLM is not needed, which I would
prefer).

I think I assumed that when Burn was run, and UAC was accepted to elevate
the install, that the automatic invoking of msiexec by clicking on the
advertised shortcut would either also run elevated (or that the elevated
stuff had already been done when the package was launched by burn as a
per-machine ALLUSER=1 package).  So am a little confused wondering:
1) why it worked for so long and when I moved source code it stopped
working?  (I know, I should know what I changed more than others.)   But I
wonder if I am missing something in understanding this.
2) If the install of the application (by clicking on the advertised
shortcut) is in a per user context, and this is a per-machine setup, should
I disable advertising the feature?  or do something else to prevent this?

In the MSI package (on Win 7 and later, based on the MSDN ALLUSERS docs)
should set the properties in my MSI of ALLUSERS and  MSIINSTALLPERUSER to
assure a per-machine installation? 

I'm just wondering what the best approach for a per-machine installation,
and not trying to do something that would violate security.
thanks for any advice.




--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058p7594083.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users