Re: [WiX-users] Creating just a web app pool on Server 2008 R2 with IIS 7.5, WiX 3.5 RTM

[Yan Sklyarenko]

I've recently faced this issue myself and here's even an easier work around:

Just place  elements for IIsWebSite and IIsWebAddress tables,
and the application pool will be created successfully. So, no need to define
a fake website.

-- Yan

On Thu, Feb 17, 2011 at 6:06 AM, John Robbins  wrote:

> Just to complete the circle in case someone else has this problem.
>
> Turns out the IIS CAs in WiX require the WebSite element to be declared. In
> my example below, I added the following under the Product element and the
> IIS CA sprung to life. :)
>
>
>  
>
>
> John
> Wintellect
> http://www.wintellect.com
> +1-877-968-5528
>
>
> -Original Message-
> From: John Robbins [mailto:j...@wintellect.com]
> Sent: Wednesday, February 16, 2011 6:35 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Creating just a web app pool on Server 2008 R2
> with IIS 7.5, WiX 3.5 RTM
>
> Good to know my beloved PDF files are there for 3.6. Good job! Sadly, we
> are using 3.5 for this project. :(
>
> John
> Wintellect
> http://www.wintellect.com
> +1-877-968-5528
>
>
> -Original Message-
> From: Bob Arnson [mailto:b...@joyofsetup.com]
> Sent: Wednesday, February 16, 2011 5:10 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Creating just a web app pool on Server 2008 R2
> with IIS 7.5, WiX 3.5 RTM
>
> On 16-Feb-11 19:15, John Robbins wrote:
> > Also, I'm going to file a bug report for WiX 3.6 that they start adding
> the PDB files for the CAs to the distributions. If I had those, I'd break in
> and be able to debug the CA myself.
>
> You misspelled "feature request." Alas, it's already implemented, so
> WinBag to your heart's content:
> http://wix.sourceforge.net/releases/3.6.1321.0/wix36-pdbs.zip
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Enabling/disabling features by script

[Eschenbacher, Frank]

Hi all,
 
does anyone know how to enable or disable a feature in a script?
 
Cheers
Frank
 
Go Green - Please consider the environment before printing this email
 

 
Volt Delta International GmbH, Landsberger Str. 110, D-80339 Muenchen 
Sitz: Muenchen, Amtsgericht Muenchen, HRB 156693, VAT-ID DE814437634 
Managing Directors (Geschaeftsfuehrer): Noel Hughes, Hans Pokorny, Yusuf Bulan
 
 
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Creating just a web app pool on Server 2008 R2 with IIS 7.5, WiX 3.5 RTM

[John Robbins]

Just to complete the circle in case someone else has this problem.

Turns out the IIS CAs in WiX require the WebSite element to be declared. In my 
example below, I added the following under the Product element and the IIS CA 
sprung to life. :)


  


John
Wintellect
http://www.wintellect.com
+1-877-968-5528


-Original Message-
From: John Robbins [mailto:j...@wintellect.com] 
Sent: Wednesday, February 16, 2011 6:35 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Creating just a web app pool on Server 2008 R2 with 
IIS 7.5, WiX 3.5 RTM

Good to know my beloved PDF files are there for 3.6. Good job! Sadly, we are 
using 3.5 for this project. :( 

John
Wintellect
http://www.wintellect.com
+1-877-968-5528


-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Wednesday, February 16, 2011 5:10 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Creating just a web app pool on Server 2008 R2 with 
IIS 7.5, WiX 3.5 RTM

On 16-Feb-11 19:15, John Robbins wrote:
> Also, I'm going to file a bug report for WiX 3.6 that they start adding the 
> PDB files for the CAs to the distributions. If I had those, I'd break in and 
> be able to debug the CA myself.

You misspelled "feature request." Alas, it's already implemented, so WinBag 
to your heart's content: 
http://wix.sourceforge.net/releases/3.6.1321.0/wix36-pdbs.zip

--
sig://boB
http://joyofsetup.com/


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Creating just a web app pool on Server 2008 R2 with IIS 7.5, WiX 3.5 RTM

[John Robbins]

Good to know my beloved PDF files are there for 3.6. Good job! Sadly, we are 
using 3.5 for this project. :( 

John
Wintellect
http://www.wintellect.com
+1-877-968-5528


-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Wednesday, February 16, 2011 5:10 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Creating just a web app pool on Server 2008 R2 with 
IIS 7.5, WiX 3.5 RTM

On 16-Feb-11 19:15, John Robbins wrote:
> Also, I'm going to file a bug report for WiX 3.6 that they start adding the 
> PDB files for the CAs to the distributions. If I had those, I'd break in and 
> be able to debug the CA myself.

You misspelled "feature request." Alas, it's already implemented, so WinBag 
to your heart's content: 
http://wix.sourceforge.net/releases/3.6.1321.0/wix36-pdbs.zip

--
sig://boB
http://joyofsetup.com/


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] admin vs. non-admin

[Bob Arnson]

On 16-Feb-11 17:13, Lukas Haase wrote:
> However, what happens when program with same UpgradeCode is first
> installed globally as administrator and the next version installed as
> non-admin user?

MSI doesn't support a per-machine package upgrading a per-user package, 
or vice-versa. It's best to pick one and stick with it.

-- 
sig://boB
http://joyofsetup.com/


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Creating just a web app pool on Server 2008 R2 with IIS 7.5, WiX 3.5 RTM

[Bob Arnson]

On 16-Feb-11 19:15, John Robbins wrote:
> Also, I'm going to file a bug report for WiX 3.6 that they start adding the 
> PDB files for the CAs to the distributions. If I had those, I'd break in and 
> be able to debug the CA myself.

You misspelled "feature request." Alas, it's already implemented, so 
WinBag to your heart's content: 
http://wix.sourceforge.net/releases/3.6.1321.0/wix36-pdbs.zip

-- 
sig://boB
http://joyofsetup.com/


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to use the InstallCondition on a MsiPackage

[Bob Arnson]

On 16-Feb-11 13:35, Gregg Swanson wrote:
> How do I use the "InstallCondition" on a MsiPackage?

Burn expressions support the same syntax as MSI, so you'd use

FOO = "ALL"

-- 
sig://boB
http://joyofsetup.com/


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] wix200x.targets missing from 3.6?

[Bob Arnson]

On 14-Feb-11 14:06, John Thornborrow wrote:
> I've just updated my installation to 3.6.1321.0, and when reloading existing 
> wix projects, I am prompted with "Access to the path 'C:\Program Files 
> (x86)\MSBuild\Microsoft\Wix\v3.x\wix200x.targets' is denied." Error. Upon 
> checking, this is because Wix directory no longer lives there, and I do not 
> have a wix200x.targets file anywhere on my machine anymore.

Try running a repair; depending on which version you upgraded from, a 
component-rules violation would have deleted the file.

-- 
sig://boB
http://joyofsetup.com/


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Creating just a web app pool on Server 2008 R2 with IIS 7.5, WiX 3.5 RTM

[John Robbins]

Hello,

I'm at wits end trying to make an installer that does nothing more than create 
an IIS7 app pool and set a registry key. No matter what I've tried, the 
application pool never gets created, but the registry key is written. They are 
both part of the same component like the following:


  
  

  
  

  
  
 


Both DOMAIN_NAME and USER_NAME are valid and I have tried setting the password 
attribute as well.

The problem appears to be in the bowls of the ConfigureIIs custom action. I've 
set LOGVERBOSE=1 and the only information I get in the /l*vx logs from 
ConfigureIIs is just the following:

MSI (s) (D8:48) [16:01:03:946]: Doing action: ConfigureIIs
Action start 16:01:03: ConfigureIIs.
MSI (s) (D8:48) [16:01:03:946]: Creating MSIHANDLE (226) of type 790542 for 
thread 2120
MSI (s) (D8:CC) [16:01:03:946]: Invoking remote custom action. DLL: 
C:\Windows\Installer\MSIDB77.tmp, Entrypoint: ConfigureIIs
MSI (s) (D8!08) [16:01:03:978]: Creating MSIHANDLE (227) of type 790541 for 
thread 1544
MSI (s) (D8!08) [16:01:03:978]: Closing MSIHANDLE (227) of type 790541 for 
thread 1544
MSI (s) (D8:CC) [16:01:03:978]: Closing MSIHANDLE (226) of type 790542 for 
thread 2120
Action ended 16:01:03: ConfigureIIs. Return value 1.

In another installer, I can use WebAppPool to access existing app pools just 
fine when used outside the component. 

Any ideas or hints? Please don't make me resort to appcmd. :)

Also, I'm going to file a bug report for WiX 3.6 that they start adding the PDB 
files for the CAs to the distributions. If I had those, I'd break in and be 
able to debug the CA myself.

John
Wintellect
http://www.wintellect.com
+1-877-968-5528


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Encrypt and store the SQL sa password in the windows registry

[Wilson, Phil]

The secure way to do this is to use the DPAPI. 

Phil Wilson 

-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] 
Sent: Wednesday, February 16, 2011 10:33 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the windows 
registry

That all depends on what key you use to encrypt the data. If the key is 
associated with the SYSTEM context then only the SYSTEM context will be able to 
decrypt the data. If an attacker already has access to the SYSTEM context then 
it's already Game Over.

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

> -Original Message-
> From: James Johnston [mailto:johnst...@inn-soft.com]
> Sent: Wednesday, February 16, 2011 8:19 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the
> windows registry
> 
> Isn't storing the administrator password for a server in the registry a 
> terrible
> idea?  This is setting off all kinds of alarm bells in my mind...
> Even if you "encrypt" it, I would think it would still be easy enough to 
> recover
> the plaintext just by finding the key in the MSI file and then decrypting.  I
> don't see how it offers any real security beyond shielding from casual prying
> eyes.  I would think an installer that does this without telling could easily 
> trap
> the unwary system administrator who wants to run a tight ship...
> 
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Wednesday, February 16, 2011 15:35
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the
> windows registry
> 
> Not today but it would be a great custom action to have.
> 
> On Tue, Feb 15, 2011 at 2:40 PM, Thai-Hoa Nguyen
> wrote:
> 
> >
> >
> > Hello
> >
> > I'm currently storing the SQL sa password so the database can be
> > uninstalled later.
> >
> >  > Value='[SQLPASSWORD]' Type='string' />
> >
> >
> >   > Id='SqlPwdReg' Key='SOFTWARE\xyz\abc' Name='SQLPwd'
> > Root='HKLM' Type='raw'/>
> > 
> >
> > Is there a quick and easy way to encrypt and decypt the password in Wix?
> >
> > Thank you.
> >
> > --
> >  The ultimate all-in-one performance toolkit: Intel(R)
> > Parallel Studio XE:
> > Pinpoint memory and threading errors before they happen.
> > Find and fix more than 250 security defects in the development cycle.
> > Locate bottlenecks in serial and parallel code that limit performance.
> > http://p.sf.net/sfu/intel-dev2devfeb
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> 
> 
> --
> virtually, Rob Mensching - http://RobMensching.com LLC
> 
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

*** Confidentiality Notice: This e-mail, including any associated or attached 
files, is intended solely for the individual or entity to which it is 
addressed. This e-mail is confidential and may well also be legally privi

[WiX-users] admin vs. non-admin

[Lukas Haase]

Hi,

How is it handled when I do not check for admin rights and users install 
my program without admin privileges?

In this case, they won't be able to register the program in the global 
Uninstall list/MSI registry I guess.

However, what happens when program with same UpgradeCode is first 
installed globally as administrator and the next version installed as 
non-admin user?

I especially ask because at first my application needed to register a 
COM object and therefore required admin privs:

 
   Privileged
 
 1
 

Furthermore I wrote a DLL which searches old instances from my 
application (using a proprietary Installer) and removes it first. This 
also required admin privileges.

However, the new version does not require admin privileged any more (COM 
object does not need to be registered).

What is the correct way to handle this situation?

Regards
Luke


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Transform xsl does not indent

[sangeeta1]

Hi,

  I am passing Transform xls to Heat.exe command to generate a
fragment wxs source file. The xsl has the indent attribute set to
"yes" and yet the output wxs file does not show indentation. Any idea
what's the right way to indent the output wxs file?


http://www.w3.org/1999/XSL/Transform";
xmlns:wix="http://schemas.microsoft.com/wix/2006/wi";>

.
...

thanks,
sangeeta

-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Transform-xsl-does-not-indent-tp6033404p6033404.html
Sent from the wix-users mailing list archive at Nabble.com.
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Encrypt and store the SQL sa password in the windows registry

[Castro, Edwin G. (Hillsboro)]

I completely agree with you assessment of the storage of the sa password. You 
should *NEVER* store a god/root password like that anywhere. I'm looking more 
closely at the thread subject and realize now that the question is specifically 
about the sa password. I would discourage this action. I would encourage the 
use of Windows Authentication and explicitly manage permissions on the SQL 
Server side of the world.

Saving encrypted identity credentials for a web application pool or windows 
service might be more acceptable *IF* you follow appropriate procedures to make 
sure that identity has Least Privilege access to dependent services like 
databases. You always want to minimize the impact of a compromised account.

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


> -Original Message-
> From: James Johnston [mailto:johnst...@inn-soft.com]
> Sent: Wednesday, February 16, 2011 10:46 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the
> windows registry
> 
> I think that would depend on whether the SQL Server is located on the same
> physical computer as the software in question that wants to store an account
> password.  If it's the same computer then you are correct - in fact that
> thought had already crossed my mind.  The one remaining issue I can think of
> is that the user's password is still compromised in a way that it wouldn't be
> otherwise.  Windows and I'm sure SQL Server uses one-way hash functions
> so that, even if the "password file" is stolen, significant effort must be
> expended to determine what the passwords are if the quality of the
> passwords is good.  If the administrator is using the same password for
> everything then there could be a problem: it might allow an attacker to
> further infiltrate the network.  If the password was only used for that one
> account then it's a non-issue.
> 
> I think that the "save password" concept really gets scary if the SQL Server 
> is
> located on a different computer.  For example, suppose the app uses the
> "sa" password to create the database on a remote server.  But for security
> reasons the app should not use the "sa" account for day-to-day use, and so
> the "sa" password is never used again except for uninstall and is saved in the
> registry somehow as has been discussed.  In that case, if the client computer
> is compromised, this "saved password" registry key.  I.e. the attacker pulls
> the hard drive from the client computer, reads the key associated with the
> SYSTEM context somehow, and then decrypts the password.  Now he's
> gained access to the server that he did not previously have.
> 
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
> Sent: Wednesday, February 16, 2011 18:33
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the
> windows registry
> 
> That all depends on what key you use to encrypt the data. If the key is
> associated with the SYSTEM context then only the SYSTEM context will be
> able to decrypt the data. If an attacker already has access to the SYSTEM
> context then it's already Game Over.
> 
> Edwin G. Castro
> Software Developer - Staff
> Electronic Banking Services
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> P Please consider the environment before printing this e-mail
> 
> > -Original Message-
> > From: James Johnston [mailto:johnst...@inn-soft.com]
> > Sent: Wednesday, February 16, 2011 8:19 AM
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the
> > windows registry
> >
> > Isn't storing the administrator password for a server in the registry
> > a terrible idea?  This is setting off all kinds of alarm bells in my mind...
> > Even if you "encrypt" it, I would think it would still be easy enough
> > to recover the plaintext just by finding the key in the MSI file and
> > then decrypting.  I don't see how it offers any real security beyond
> > shielding from casual prying eyes.  I would think an installer that
> > does this without telling could easily trap the unwary system administrator
> who wants to run a tight ship...
> >
> > -Original Message-
> > From: Rob Mensching [mailto:r...@robmensching.com]
> > Sent: Wednesday, February 16, 2011 15:35
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the
> > windows registry
> >
> > Not today but it would be a great custom action to have.
> >
> > On Tue, Feb 15, 2011 at 2:40 PM, Thai-Hoa Nguyen
> > wrote:
> >
> > >
> > >
> > > Hello
> > >
> > > I'm currently storing the SQL sa password so the dat

Re: [WiX-users] Encrypt and store the SQL sa password in the windows registry

[James Johnston]

I think that would depend on whether the SQL Server is located on the same 
physical computer as the software in question that wants to store an account 
password.  If it's the same computer then you are correct - in fact that 
thought had already crossed my mind.  The one remaining issue I can think of is 
that the user's password is still compromised in a way that it wouldn't be 
otherwise.  Windows and I'm sure SQL Server uses one-way hash functions so 
that, even if the "password file" is stolen, significant effort must be 
expended to determine what the passwords are if the quality of the passwords is 
good.  If the administrator is using the same password for everything then 
there could be a problem: it might allow an attacker to further infiltrate the 
network.  If the password was only used for that one account then it's a 
non-issue.

I think that the "save password" concept really gets scary if the SQL Server is 
located on a different computer.  For example, suppose the app uses the "sa" 
password to create the database on a remote server.  But for security reasons 
the app should not use the "sa" account for day-to-day use, and so the "sa" 
password is never used again except for uninstall and is saved in the registry 
somehow as has been discussed.  In that case, if the client computer is 
compromised, this "saved password" registry key.  I.e. the attacker pulls the 
hard drive from the client computer, reads the key associated with the SYSTEM 
context somehow, and then decrypts the password.  Now he's gained access to the 
server that he did not previously have. 

-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] 
Sent: Wednesday, February 16, 2011 18:33
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the windows 
registry

That all depends on what key you use to encrypt the data. If the key is 
associated with the SYSTEM context then only the SYSTEM context will be able to 
decrypt the data. If an attacker already has access to the SYSTEM context then 
it's already Game Over.

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

> -Original Message-
> From: James Johnston [mailto:johnst...@inn-soft.com]
> Sent: Wednesday, February 16, 2011 8:19 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the 
> windows registry
> 
> Isn't storing the administrator password for a server in the registry 
> a terrible idea?  This is setting off all kinds of alarm bells in my mind...
> Even if you "encrypt" it, I would think it would still be easy enough 
> to recover the plaintext just by finding the key in the MSI file and 
> then decrypting.  I don't see how it offers any real security beyond 
> shielding from casual prying eyes.  I would think an installer that 
> does this without telling could easily trap the unwary system administrator 
> who wants to run a tight ship...
> 
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Wednesday, February 16, 2011 15:35
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the 
> windows registry
> 
> Not today but it would be a great custom action to have.
> 
> On Tue, Feb 15, 2011 at 2:40 PM, Thai-Hoa Nguyen
> wrote:
> 
> >
> >
> > Hello
> >
> > I'm currently storing the SQL sa password so the database can be 
> > uninstalled later.
> >
> >  > Value='[SQLPASSWORD]' Type='string' />
> >
> >
> >   > Id='SqlPwdReg' Key='SOFTWARE\xyz\abc' Name='SQLPwd'
> > Root='HKLM' Type='raw'/>
> > 
> >
> > Is there a quick and easy way to encrypt and decypt the password in Wix?
> >
> > Thank you.
> >
> > 
> > --
> >  The ultimate all-in-one performance toolkit: Intel(R) 
> > Parallel Studio XE:
> > Pinpoint memory and threading errors before they happen.
> > Find and fix more than 250 security defects in the development cycle.
> > Locate bottlenecks in serial and parallel code that limit performance.
> > http://p.sf.net/sfu/intel-dev2devfeb
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> 
> 
> --
> virtually, Rob Mensching - http://RobMensching.com LLC
> --
> --
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performan

[WiX-users] How to use the InstallCondition on a MsiPackage

[Gregg Swanson]

How do I use the "InstallCondition" on a MsiPackage?


I would like to install this MSI package of the property FOO is set to ALL.

  

Thanks,
Gregg
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Encrypt and store the SQL sa password in the windows registry

[Castro, Edwin G. (Hillsboro)]

That all depends on what key you use to encrypt the data. If the key is 
associated with the SYSTEM context then only the SYSTEM context will be able to 
decrypt the data. If an attacker already has access to the SYSTEM context then 
it's already Game Over.

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

> -Original Message-
> From: James Johnston [mailto:johnst...@inn-soft.com]
> Sent: Wednesday, February 16, 2011 8:19 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the
> windows registry
> 
> Isn't storing the administrator password for a server in the registry a 
> terrible
> idea?  This is setting off all kinds of alarm bells in my mind...
> Even if you "encrypt" it, I would think it would still be easy enough to 
> recover
> the plaintext just by finding the key in the MSI file and then decrypting.  I
> don't see how it offers any real security beyond shielding from casual prying
> eyes.  I would think an installer that does this without telling could easily 
> trap
> the unwary system administrator who wants to run a tight ship...
> 
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Wednesday, February 16, 2011 15:35
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the
> windows registry
> 
> Not today but it would be a great custom action to have.
> 
> On Tue, Feb 15, 2011 at 2:40 PM, Thai-Hoa Nguyen
> wrote:
> 
> >
> >
> > Hello
> >
> > I'm currently storing the SQL sa password so the database can be
> > uninstalled later.
> >
> >  > Value='[SQLPASSWORD]' Type='string' />
> >
> >
> >   > Id='SqlPwdReg' Key='SOFTWARE\xyz\abc' Name='SQLPwd'
> > Root='HKLM' Type='raw'/>
> > 
> >
> > Is there a quick and easy way to encrypt and decypt the password in Wix?
> >
> > Thank you.
> >
> > --
> >  The ultimate all-in-one performance toolkit: Intel(R)
> > Parallel Studio XE:
> > Pinpoint memory and threading errors before they happen.
> > Find and fix more than 250 security defects in the development cycle.
> > Locate bottlenecks in serial and parallel code that limit performance.
> > http://p.sf.net/sfu/intel-dev2devfeb
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> 
> 
> --
> virtually, Rob Mensching - http://RobMensching.com LLC
> 
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] heat to generate directoryid same as the directory name

[Konda, Kavya R]

I got itI used -suid to do it.

Thanks,
KK

From: Konda, Kavya R
Sent: Wednesday, February 16, 2011 11:00 AM
To: 'wix-users@lists.sourceforge.net'
Subject: heat to generate directoryid same as the directory name

Hi,

I am using heat to harvest a directory with sub-directories in it. I was 
wondering if there is a way to make Heat get the directory id same as the 
directory name. Currently this is command I have for using heat:

heat dir " BuildOutputs\ABC" -cg DirectoryStructure  -gg -sfrag -sreg -srd -dr 
ABC -var "var.BuildOutputs" -out "C:\Directory.wxs"

Thanks,
Kavya
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] heat to generate directoryid same as the directory name

[Konda, Kavya R]

Hi,

I am using heat to harvest a directory with sub-directories in it. I was 
wondering if there is a way to make Heat get the directory id same as the 
directory name. Currently this is command I have for using heat:

heat dir " BuildOutputs\ABC" -cg DirectoryStructure  -gg -sfrag -sreg -srd -dr 
ABC -var "var.BuildOutputs" -out "C:\Directory.wxs"

Thanks,
Kavya
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Possible to force an uninstall and ignore errors?

[sd]

Thanks!  That was just what I was looking for.  I did try the /f flag
before but the options I was using weren't working.

Thanks again,

Jeff


> 1. Build a new MSI (with the same ProductCode) that uninstalls correctly.
> 2. "msiexec /fv new.msi" to recache/reinstall your MSI over the bad MSI.
> 3. You should now be able to uninstall.
>
> On Tue, Feb 15, 2011 at 11:32 AM,  wrote:
>
>> Although my issue and question isn't wix-specific, it does pertain to
>> installers in general so I'm hoping someone on this mailing list might
>> have some suggestions.
>>
>> I'm working on the installer for my product (using the VisualStudio 2008
>> Setup Project template) and I've boxed myself into a corner.  I've been
>> playing around with custom actions and messed up the uninstall custom
>> action.  The problem is that the original MSI doesn't exist anymore (I
>> overwrote it when I rebuilt the installer), and when I try to uninstall
>> (via Add/Remove Programs, or directly via msiexec) the uninstall's
>> custom
>> action fails and I can't remove the product.  When I try to run a new
>> version of my installer, I get an error from the system telling me that
>> another version of the product exists and to use Add/Remove programs.
>>
>> In RegEdit I've located my product within
>>
>> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{my_product_guid}
>> and when I try:
>>
>>msiexec /x {my_product_guid}
>>
>> ...I get the error I mentioned.  The error/issue is that the custom
>> delete
>> action requires a parameter passed in, and when the parameter is missing
>> the uninstall fails, however when I provide the missing parameter:
>>
>>msiexec /x {my_product_guid} MY_PARAMETER="some_value"
>>
>> ...I still get the error telling me the parameter is missing.
>>
>>
>> Is there a way to force an uninstall and to ignore errors?  Or is there
>> a
>> way to brute force the removal?
>>
>> Thanks,
>>
>> Jeff
>>
>>
>>
>> --
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
>> XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development cycle.
>> Locate bottlenecks in serial and parallel code that limit performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>
>
> --
> virtually, Rob Mensching - http://RobMensching.com LLC
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>



--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Encrypt and store the SQL sa password in the windows registry

[James Johnston]

Isn't storing the administrator password for a server in the registry a
terrible idea?  This is setting off all kinds of alarm bells in my mind...
Even if you "encrypt" it, I would think it would still be easy enough to
recover the plaintext just by finding the key in the MSI file and then
decrypting.  I don't see how it offers any real security beyond shielding
from casual prying eyes.  I would think an installer that does this without
telling could easily trap the unwary system administrator who wants to run a
tight ship...

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: Wednesday, February 16, 2011 15:35
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the
windows registry

Not today but it would be a great custom action to have.

On Tue, Feb 15, 2011 at 2:40 PM, Thai-Hoa Nguyen
wrote:

>
>
> Hello
>
> I'm currently storing the SQL sa password so the database can be 
> uninstalled later.
>
>  Value='[SQLPASSWORD]' Type='string' />
>
>
>   Id='SqlPwdReg' Key='SOFTWARE\xyz\abc' Name='SQLPwd'
> Root='HKLM' Type='raw'/>
> 
>
> Is there a quick and easy way to encrypt and decypt the password in Wix?
>
> Thank you.
>
> --
>  The ultimate all-in-one performance toolkit: Intel(R) 
> Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


--
virtually, Rob Mensching - http://RobMensching.com LLC

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Conditionally invoking ServiceInstall Element

[Christopher Painter]

I usually try to do two different file names to avoid the ICE warning about 
conditional components.  Will smart cabbing  work on two files with different 
names but the same hash?
 
---
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me



- Original Message 
From: Rob Mensching 
To: General discussion for Windows Installer XML toolset. 

Sent: Wed, February 16, 2011 9:39:56 AM
Subject: Re: [WiX-users] Conditionally invoking ServiceInstall Element

I don't think more disk space should be consumed if things are cabbed and
the service executable is identical in the two Components (one Conditioned,
the other not) because only one will ever get installed on the machine (due
to mutually exclusive Conditions) and smart-cabbing should make sure only
one file is in the cabinet.

(wow, that's one sentence ).
On Mon, Feb 14, 2011 at 8:50 AM, Christopher Painter <
chr...@deploymentengineering.com> wrote:

> Technically it's a violation of the component rules.  However, if you can
> make
> sure that the two components ( whether they be in two merge modules or no
> merge
> modules ) have mutually exclusive component conditions so that only one
> will
> ever be installed you can pretty much get away with it.  You will still
> get
> validation errors as part of the build though I believe.  I've done this in
> the
> past  and my main complaint about it is it doesn't scale well.
>
>
> If dev doesn't want to redo the app,  what would be the effect of taking
> consoleappservice.exe and copying / renaming it to have two files:
>
> consoleapp.exe
> service.exe
>
> It's a confusing hack and you'll eat up more disk space then if you
> factored it
> out into the shared.dll  but you should be able to still do everything I
> mentioned previously.  If this is .NET code it might not be happy but you
> could
> give it a try.
>
> Personally if it is a .NET service, I can't imagine it taking more then a
> few
> hours to factor out, build and test.
>
> ---
> Christopher Painter, Author of Deployment Engineering Blog
> Have a hot tip, know a secret or read a really good thread that deserves
> attention? E-Mail Me
>
>
>
> - Original Message 
> From: Gregg Swanson 
> To: General discussion for Windows Installer XML toolset.
> 
> Sent: Mon, February 14, 2011 10:38:26 AM
> Subject: Re: [WiX-users] Conditionally invoking ServiceInstall Element
>
> Thanks for the help...
>
> I am a WIX rooky.
>
> Is this is a valid option -
>
> Package the consleappservice.exe in two separate merge modules, the first
> doesn't invoke ServiceInstall the second does invoke ServiceInstall?
>
> The application that I am helping will have to refactor code and they may
> be
> reluctant to do so at this point in time.
>
> Thanks,
> Gregg
>
>
> -Original Message-
> From: Christopher Painter [mailto:chr...@deploymentengineering.com]
> Sent: Monday, February 14, 2011 10:14 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Conditionally invoking ServiceInstall Element
>
> The ServiceControl element is a child of the Component which is a child of
> the
> Feature element so the condition can be applied at the Feature or Component
> level.  If the component is installed the service will be installed and
> there's
> no way around that except to factor your service out of the console app:
>
> consleappservice.exe ->  consoleapp.exe, service.exe, shared.dll
>
> Then you can put have Feature A reference  the consoleapp.exe
> and shared.dll
> components and Feature B referene service.exe and shared.dll components.  (
> Note: There is only 1 shared.dll component )
>
> If feature B is installed you will get a service.  If feature B is not
> installed
> you will not get a service but you can still have your console app if
> feature A
> is installed.
>
> >From a SysAdmin's point of view it's silent installs can be:
>
> msiexec /i foo.msi ADDLOCAL=A  /qn  or
> msiexec /i foo.msi ADDLOCAL=A,B /qn
>
> If the service was not previously installed and now desired they can issue
> the
> command:
>
> msiexec /i foo.msi ADDLOCAL=B /qn
>
> If the service was previously installed and no longer desired they can
> issue the
> command
>
> msiexec /i foo.msi REMOVE=B /qn
>
> If they want to uninstall all together they can say:
>
> msiexec /x foo.msi  /qn  or
> msiexec /i foo.msi REMOVE=ALL /qn
>
>
> ---
> Christopher Painter, Author of Deployment Engineering Blog Have a hot tip,
> know
> a secret or read a really good thread that deserves attention? E-Mail Me
>
>
>
> - Original Message 
> From: Gregg Swanson 
> To: "wix-users@lists.sourceforge.net" 
> Sent: Mon, February 14, 2011 9:48:47 AM
> Subject: [WiX-users] Conditionally invoking ServiceInstall Element
>
> Hello,
>
> I have a Console application that may also be used as a Windows Service. Is
> it
> possible to conditionally invoke or not invoke the ServiceInstall elemen

Re: [WiX-users] UAC - random name

[Andreas Hiltner]

Thanks, that works great!

-- 

Viele Gruesse,

  Andreas mailto:andr...@andreas-hiltner.de 


> 
>
>   Bruce Cran 
> Wednesday, February 16, 2011 11:13
>
>
> On Wed, 16 Feb 2011 10:21:33 -0500
>
> You can set it with the /d flag if you use signtool to sign the MSI.
>
> 
>
>   Andreas Hiltner 
> Wednesday, February 16, 2011 10:21
>
>
> Hi,
>
> When I install our generated MSI file, a dialog pops up, to ask the 
> user, if he wants to allow the "[insert random number here].msi" to 
> make any changes to the computer.
> Now we would like to replace the "random number" with the name of the 
> MSI file or ProductCode.
> How do I do that?
> Maybe you could point me to the right area in the documentation.
>
> Thanks a lot,
> Andreas

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] UAC - random name

[Bruce Cran]

On Wed, 16 Feb 2011 10:21:33 -0500
Andreas Hiltner  wrote:

> Hi,
> 
> When I install our generated MSI file, a dialog pops up, to ask the 
> user, if he wants to allow the "[insert random number here].msi" to
> make any changes to the computer.
> Now we would like to replace the "random number" with the name of the 
> MSI file or ProductCode.
> How do I do that?
> Maybe you could point me to the right area in the documentation.

You can set it with the /d flag if you use signtool to sign the MSI.

-- 
Bruce Cran

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Disable "Log in as admin" Dialog during uninstall

[Odamteng, Abraham]

 

While Windows UAC is enabled, If the user attempts to uninstall the
program using Add-Remove-Programs they will get a UAC prompt.

If the user allows this prompt to time-out (or answers "No"), a message
pops-up indicating the user must be an Administrator and should log-on
as an Admin or contact technical support - even if the user is currently
logged-on with an Admin account. 

 

Note: Other Windows applications do not display this message when the
prompt times-out (or user select "No") - instead, the user is taken back
to the Add-Remove-Programs.

 

How can I get disable this popup message without disabling UAC?

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] UAC - random name

[Andreas Hiltner]

Hi,

When I install our generated MSI file, a dialog pops up, to ask the 
user, if he wants to allow the "[insert random number here].msi" to make 
any changes to the computer.
Now we would like to replace the "random number" with the name of the 
MSI file or ProductCode.
How do I do that?
Maybe you could point me to the right area in the documentation.

Thanks a lot,
Andreas

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Conditionally invoking ServiceInstall Element

[Rob Mensching]

I don't think more disk space should be consumed if things are cabbed and
the service executable is identical in the two Components (one Conditioned,
the other not) because only one will ever get installed on the machine (due
to mutually exclusive Conditions) and smart-cabbing should make sure only
one file is in the cabinet.

(wow, that's one sentence ).
On Mon, Feb 14, 2011 at 8:50 AM, Christopher Painter <
chr...@deploymentengineering.com> wrote:

> Technically it's a violation of the component rules.   However, if you can
> make
> sure that the two components ( whether they be in two merge modules or no
> merge
> modules ) have mutually exclusive component conditions so that only one
> will
> ever be installed you can pretty much get away with it.   You will still
> get
> validation errors as part of the build though I believe.  I've done this in
> the
> past  and my main complaint about it is it doesn't scale well.
>
>
> If dev doesn't want to redo the app,  what would be the effect of taking
> consoleappservice.exe and copying / renaming it to have two files:
>
> consoleapp.exe
> service.exe
>
> It's a confusing hack and you'll eat up more disk space then if you
> factored it
> out into the shared.dll   but you should be able to still do everything I
> mentioned previously.   If this is .NET code it might not be happy but you
> could
> give it a try.
>
> Personally if it is a .NET service, I can't imagine it taking more then a
> few
> hours to factor out, build and test.
>
> ---
> Christopher Painter, Author of Deployment Engineering Blog
> Have a hot tip, know a secret or read a really good thread that deserves
> attention? E-Mail Me
>
>
>
> - Original Message 
> From: Gregg Swanson 
> To: General discussion for Windows Installer XML toolset.
> 
> Sent: Mon, February 14, 2011 10:38:26 AM
> Subject: Re: [WiX-users] Conditionally invoking ServiceInstall Element
>
> Thanks for the help...
>
> I am a WIX rooky.
>
> Is this is a valid option -
>
> Package the consleappservice.exe in two separate merge modules, the first
> doesn't invoke ServiceInstall the second does invoke ServiceInstall?
>
> The application that I am helping will have to refactor code and they may
> be
> reluctant to do so at this point in time.
>
> Thanks,
> Gregg
>
>
> -Original Message-
> From: Christopher Painter [mailto:chr...@deploymentengineering.com]
> Sent: Monday, February 14, 2011 10:14 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Conditionally invoking ServiceInstall Element
>
> The ServiceControl element is a child of the Component which is a child of
> the
> Feature element so the condition can be applied at the Feature or Component
> level.  If the component is installed the service will be installed and
> there's
> no way around that except to factor your service out of the console app:
>
> consleappservice.exe ->  consoleapp.exe, service.exe, shared.dll
>
> Then you can put have Feature A reference  the consoleapp.exe
> and shared.dll
> components and Feature B referene service.exe and shared.dll components.  (
> Note: There is only 1 shared.dll component )
>
> If feature B is installed you will get a service.  If feature B is not
> installed
> you will not get a service but you can still have your console app if
> feature A
> is installed.
>
> >From a SysAdmin's point of view it's silent installs can be:
>
> msiexec /i foo.msi ADDLOCAL=A  /qn   or
> msiexec /i foo.msi ADDLOCAL=A,B /qn
>
> If the service was not previously installed and now desired they can issue
> the
> command:
>
> msiexec /i foo.msi ADDLOCAL=B /qn
>
> If the service was previously installed and no longer desired they can
> issue the
> command
>
> msiexec /i foo.msi REMOVE=B /qn
>
> If they want to uninstall all together they can say:
>
> msiexec /x foo.msi  /qn  or
> msiexec /i foo.msi REMOVE=ALL /qn
>
>
> ---
> Christopher Painter, Author of Deployment Engineering Blog Have a hot tip,
> know
> a secret or read a really good thread that deserves attention? E-Mail Me
>
>
>
> - Original Message 
> From: Gregg Swanson 
> To: "wix-users@lists.sourceforge.net" 
> Sent: Mon, February 14, 2011 9:48:47 AM
> Subject: [WiX-users] Conditionally invoking ServiceInstall Element
>
> Hello,
>
> I have a Console application that may also be used as a Windows Service. Is
> it
> possible to conditionally invoke or not invoke the ServiceInstall element
> to
> control when the service is installed?
>
>
> Thanks,
> Gregg
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@l

Re: [WiX-users] Encrypt and store the SQL sa password in the windows registry

[Rob Mensching]

Not today but it would be a great custom action to have.

On Tue, Feb 15, 2011 at 2:40 PM, Thai-Hoa Nguyen wrote:

>
>
> Hello
>
> I'm currently storing the SQL sa password so the database can be
> uninstalled later.
>
>  Value='[SQLPASSWORD]' Type='string' />
>
>
> 
>  Root='HKLM' Type='raw'/>
> 
>
> Is there a quick and easy way to encrypt and decypt the password in Wix?
>
> Thank you.
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Patching Using Purely Wix

[Liam Flanagan]

Hello All,

 

I've been wondering if it's possible to create minor patches using the
"purely wix" method, however only using the baseline and QFE MSI packages
instead of requiring the original source files and structure that the MSIs
were built from. I want have the benefits of purely wix patching (i.e.
referencing wix components etc) however not the complexity of having build
output snapshots that have a large quantities of files and file structures,
instead simply the released MSIs. 

 

The table in this msdn blog (
http://blogs.msdn.com/b/heaths/archive/2010/08/24/comparison-of-patchwiz-and
-wix-v3-patch-build.aspx ) implies that these should be possible; although I
guess not all at the same time. (CF: ticks in the "Ignore certain other
resource types to be upgraded by the patch (ex: registry values, components,
etc.)" and "Can automatically extract compressed files when creating
transforms." Boxes)

 

A little background into what I've tried so far:

. Using the wixpdb files with torch to create the transform between
the two versions appears to require the original msi build structure when
creating the patch

. Using torch on the msi files as standard appears to create a
binary mst file, I presume this is for use with PatchWiz as Wix tools don't
seem to like this at all

. If whilst using torch on the msi files you specify you want an xml
output (wixout) you appear to get a file very similar to that of the output
when using torch on the wixpdb files, however you appear to lose all
information about wix structures (wix components/component groups etc).
Therefore if I try to specify them in the patch.wxs, pyro doesn't understand
what differences you're actually trying to bring through in the patch.

Furthermore on this, this fairly dated blog post (
http://blogs.msdn.com/b/pmarcu/archive/2007/04/27/building-a-patch-using-wix
-v3-0.aspx ) implies that when creating the original msi files creating an
interim wixmsi and using light to convert that into an MSI rather than just
lighting the wixobj may change the game a bit; however I couldn't get this
to work. The produced MSI files whilst having different md5sums appeared
identical in Orca and furthermore produced identical wixout files via torch.

 

Is what I'm hoping for achievable?

 

Thanks,

Liam 

 

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] select one of two features by radio button

[Eschenbacher, Frank]

I found a solution to the problem but I still must enable/disable
features with jscript. Does anyone know how to do this?

1st I changed the two features:


  
  



  
  


2nd I added to the next button:


  1
  WINDOWSSERVICE=1
  WINDOWSSERVICE=0


A solution for enabling/disabling features with jscript would be fine.

Cheers
Frank

-Original Message-
From: Eschenbacher, Frank [mailto:frank.eschenbac...@voltdelta.net] 
Sent: Wednesday, February 16, 2011 10:35 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] select one of two features by radio button

Hello all,
 
I created the following (excerpt):
 


 


 














































































 

 












 
















 
When I select the Windows Service feature, then everything is installed
as expected, when I select the Run Key feature, then this feature ist
not installed (and the windows serivce feature is also not installed).
And when I set the following:
 


Then I can select the Run Key feature and it is installed but I can not
install the Windows Service feature by selecting it. What am I doing
wrong?

Cheers Frank

 
Go Green - Please consider the environment before printing this email
 

 
Volt Delta International GmbH, Landsberger Str. 110, D-80339 Muenchen

Sitz: Muenchen, Amtsgericht Muenchen, HRB 156693, VAT-ID DE814437634 
Managing Directors (Geschaeftsfuehrer): Noel Hughes, Hans Pokorny, Yusuf
Bulan
 
 

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Volt Delta International GmbH, Landsberger Str. 110, D-80339 Muenchen
Sitz: Muenchen, Amtsgericht Muenchen, HRB 156693, VAT-ID DE814437634
Managing Directors (Geschaeftsfuehrer): Noel Hughes, Hans Pokorny, Yusuf Bulan


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Encrypt and store the SQL sa password in the windowsregistry

[Peter Shirtcliffe]

No. You may be able to find something you can use here:
http://msiext.codeplex.com/
You should also mark your Property with Hidden="yes" so it doesn't appear in
the logs.


-Original Message-
From: Thai-Hoa Nguyen [mailto:taiwa...@hotmail.com] 
Sent: 15 February 2011 22:40
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Encrypt and store the SQL sa password in the
windowsregistry



Hello
 
I'm currently storing the SQL sa password so the database can be uninstalled
later.
 

 
 


 
 
Is there a quick and easy way to encrypt and decypt the password in Wix?
 
Thank you.
-
-
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] select one of two features by radio button

[Eschenbacher, Frank]

Hello all,
 
I created the following (excerpt):
 


 


 














































































 

 












 
















 
When I select the Windows Service feature, then everything is installed
as expected, when I select the Run Key feature, then this feature ist
not installed (and the windows serivce feature is also not installed).
And when I set the following:
 


Then I can select the Run Key feature and it is installed but I can not
install the Windows Service feature by selecting it. What am I doing
wrong?

Cheers Frank

 
Go Green - Please consider the environment before printing this email
 

 
Volt Delta International GmbH, Landsberger Str. 110, D-80339 Muenchen 
Sitz: Muenchen, Amtsgericht Muenchen, HRB 156693, VAT-ID DE814437634 
Managing Directors (Geschaeftsfuehrer): Noel Hughes, Hans Pokorny, Yusuf Bulan
 
 
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users