[WiX-users] Force ACLs to child objects

[Chris Lindal]

Trying this post one more time...

> I'm having issues with setting perms with the util:PermissionEx and
> Permission elements. The folder ACLs are being set correctly but they
> are not being propagated down if there are child folders with
> different permissions. Is there a way to force or reset the permission
> entries on child objects? 
> 
> This is my snippet..
> 
> 
>   
>   
>GenericRead="yes" Read="yes" GenericExecute="yes" />
>User="IUSR_[ComputerName]" GenericRead="yes" Read="yes"
> GenericExecute="yes" />
>   
> 
> 
> Thanks tons!
> 
> Chris
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] how does preprocessor suppose to work

[Jordan Fitzgibbon]

The syntax for ifdef is , not . 
So, it would appear that ifdef only checks for preprocessor variables and not 
environment variables. Even if you had  or any other 
existing environment variable, the ifdef wouldn't be working as you'd expect it 
to.

Your other approach,  won't work because the 
preprocessor doesn't know about 'null' (that's what ifdef is for).  I don't 
think it would be unreasonable to log a feature request on sourceforge to have 
an undefined environment variable resolve to an empty string instead of a 
compiler error.

A possible solution for you would be evaluate _BuildArch on the command line 
and pass it as a preprocessor variable to candle.


1.   You'll want to use a command line like:

Candle.exe source.wxs -out out.wixobj -dBuildArchVar=%_BuildArch%

2.   And sse  authoring similar to this:







If %_BuildArch% is defined in your environment, it will be resolved before it 
gets passed to candle. If it is not defined in your environment, it will get 
resolved to the string "%_BuildArch%" which is fine because the  won't 
evaluate to true.

Hope this helps.


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of zhisheng huang
Sent: Monday, March 24, 2008 2:38 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] how does preprocessor suppose to work

Hi,

When environment variable _BuildArch is not defined. The following code fails 
with "Undefined preprocessor variable '$(env._BuildArch)'".


   
   

   


Actually I think I should use  for the first 
statement. But I got "Undefined preprocessor variable '$(env._BuildArch)'" for 
that too.
The warning text "You should not see this" is NOT displayed, which means the 
the first statement is evaluated false. Then why is the  inside that 
  is evaluated?

How can I check if an environment variable is defined or not?

I am using Wix 3.0. Thanks for any comment or suggestion!

Zhisheng

Test your Star IQ Play 
now!
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] how does preprocessor suppose to work

[zhisheng huang]

Hi,
 
When environment variable _BuildArch is not defined. The following code fails 
with "Undefined preprocessor variable '$(env._BuildArch)'". 
 

   
   

   

 
Actually I think I should use  for the first 
statement. But I got "Undefined preprocessor variable '$(env._BuildArch)'" for 
that too. 
The warning text "You should not see this" is NOT displayed, which means the 
the first statement is evaluated false. Then why is the  inside that 
  is evaluated? 
 
How can I check if an environment variable is defined or not?
 
I am using Wix 3.0. Thanks for any comment or suggestion!
 
Zhisheng
_
Test your Star IQ
http://club.live.com/red_carpet_reveal.aspx?icid=redcarpet_HMTAGMAR-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Re compiling WiX C++ libs for 64-bit

[Sanin]

I have a C++ WiX custom action which happens to be a shim to a .NET assembly.
I am now trying to produce a 64-bit version of the installation kit.

Questions:

1. Do I have to recompile my shim (i.e. C++ custom action) to 64-bit?
2. If so, here is the problem:
  - existing WiX C++ libraries (wcautil.lib and dutil.lib) are 32-bit.
  - i tried linking against them while doing the 64-bit compile but a number
of symbols is not found.
  - trying to solve the problem i ventured down the path of recompiling
these libs on to 64-bit platform, but hit a roadblock as i do not know how
to pass the required compiler #define to the VisualCPP.ClTask in Nant.

  Questions:

  1. How do i pass /D _X64_ via nant script? Based on the log output, the
task that gets executed is VisualCpp.Tasks.ClTask.ExecuteTask. now the nant
script only has a call to "makeNativeLib". I am quite puzzled about this
target. Where is this coming from?
And more importantly how do I pass ClTask.options values through it?
Obviously a bunch of "standard" defines are already present (see the log)
but i am not sure how i can add my defines to it...

Hope this makes sense.

Thanks.

Sanin

Here is the log output -- check the:

NAnt 0.86 (Build 0.86.2962.0; nightly; 2/10/2008)
Copyright (C) 2001-2008 Gerry Shaw
http://nant.sourceforge.net

Buildfile: file:///C:/Documents and
Settings/Administrator/Desktop/wix3-sources/wix.build
Target framework: Microsoft .NET Framework 2.0
Base Directory: C:\Documents and
Settings\Administrator\Desktop\wix3-sources.
Target(s) specified: wcautil 

  [include] Including file C:\Documents and
Settings\Administrator\Desktop\wix3-sources\wix.include.
  [include] Including file C:\Documents and
Settings\Administrator\Desktop\wix3-sources\global.include.
  [include] Including file C:\Documents and
Settings\Administrator\Desktop\wix3-sources\directories.include.
 [property] Property "dir.root" already exists, and "overwrite" is set to
false.
 [echo] dir.root = C:\Documents and
Settings\Administrator\Desktop\wix3-sources\
 [property] Property "flavor" already exists, and "overwrite" is set to
false.
[readregistry] Opening LocalMachine:SOFTWARE\Microsoft\Microsoft
SDKs\Windows\v6.0\.
[readregistry] Opening
LocalMachine:SOFTWARE\Microsoft\VisualStudio\VSIP\8.0.60912\.
[readregistry] Registry Path Not Found! -
key='SOFTWARE\Microsoft\VisualStudio\VSIP\8.0.60912\';hive='Microsoft.Win32.RegistryHive[]';:
[readregistry] NAnt.Core.BuildException: Registry Path Not Found! -
key='SOFTWARE\Microsoft\VisualStudio\VSIP\8.0.60912\';hive='Microsoft.Win32.RegistryHive[]';
[readregistry]at NAnt.Win32.Tasks.ReadRegistryTask.LookupRegKey(String
key, RegistryHive[] registries) in
d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line
183
[readregistry]at NAnt.Win32.Tasks.ReadRegistryTask.ExecuteTask() in
d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line
145
[readregistry]at NAnt.Core.Task.Execute() in
d:\Source\nant-20080210T102007Z\src\NAnt.Core\Task.cs:line 178
 [echo] Visual Studio 2005 SDK September 2006 not detected; VS 2005
versions of Sconce and Votive will not be built.
[readregistry] Opening
LocalMachine:SOFTWARE\Microsoft\VisualStudio\VSIP\9.0\.
[readregistry] Registry Path Not Found! -
key='SOFTWARE\Microsoft\VisualStudio\VSIP\9.0\';hive='Microsoft.Win32.RegistryHive[]';:
[readregistry] NAnt.Core.BuildException: Registry Path Not Found! -
key='SOFTWARE\Microsoft\VisualStudio\VSIP\9.0\';hive='Microsoft.Win32.RegistryHive[]';
[readregistry]at NAnt.Win32.Tasks.ReadRegistryTask.LookupRegKey(String
key, RegistryHive[] registries) in
d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line
183
[readregistry]at NAnt.Win32.Tasks.ReadRegistryTask.ExecuteTask() in
d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line
145
[readregistry]at NAnt.Core.Task.Execute() in
d:\Source\nant-20080210T102007Z\src\NAnt.Core\Task.cs:line 178
 [echo] Visual Studio 2008 SDK not detected; VS 2008 versions of Sconce
and Votive will not be built.
 [echo] PlatformSDK directory (dir.platformsdk) = C:\Program
Files\Microsoft SDKs\Windows\v6.0\
 [echo] VC8 directory (dir.vc8) = c:\Program Files\Microsoft Visual
Studio 8\Common7\Tools\..\..\VC
 [echo] NAnt directory (dir.nant) = c:\SpareDisk\nant-0.86-beta1\bin\
 [echo] hhc.exe (tool.hhc) found at C:\Program Files\HTML Help
Workshop\hhc.exe
  [include] Including file C:\Documents and
Settings\Administrator\Desktop\wix3-sources\src\ambient\appsynup\appsynup.build.
  [include] Including file C:\Documents and
Settings\Administrator\Desktop\wix3-sources\src\dutil\dutil.build.
  [include] Including file C:\Documents and
Settings\Administrator\Desktop\wix3-sources\src\ext\ext.build.
  [include] Including file C:\Documents and
Settings\Administrator\Desktop\wix3-sources\src\ext\complusextension\complusextension.build.
  [include] Including file C:\Documents and
Settings\Administrat

Re: [WiX-users] WiX-users Digest, Vol 22, Issue 97

[Zenko Klapko Jr.]

On 3/24/08, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Send WiX-users mailing list submissions to
> wix-users@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/wix-users
> or, via email, send a message with subject or body 'help' to
> [EMAIL PROTECTED]
>
> You can reach the person managing the list at
> [EMAIL PROTECTED]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WiX-users digest..."
>
>
> Today's Topics:
>
> 1. (no subject) (=?GB2312?B?1tPOxLvU?=)
> 2. Re: WiXSqlExtension issue on Vista with UAC (Sajo Jacob)
> 3. ??? ??? ()
>
>
> --
>
> Message: 1
> Date: Mon, 24 Mar 2008 04:53:00 +0800
> From: =?GB2312?B?1tPOxLvU?= <[EMAIL PROTECTED] >
> Subject: [WiX-users] (no subject)
> To: wix-users@lists.sourceforge.net
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain;charset="GB2312"
>
>
>
>
> ??
>
>
> 2008??
> ??
> 
>
>
> ??
> ??
>
> ??..??
>
>
> ??
>
> ??
> ??
> ??0755-81153047??
> ??
> ??0755-81172940??
> ??
> ??15817477278??
> ??
> 
> ??
> ??
>
>
>
> ??
> ??
>
>
>
> --
>
> Message: 2
> Date: Sun, 23 Mar 2008 20:44:21 -0500
> From: "Sajo Jacob" <[EMAIL PROTECTED]>
> Subject: Re: [WiX-users] WiXSqlExtension issue on Vista with UAC
> To: "Mike Dimmick" <[EMAIL PROTECTED]>
> Cc: Bob Arnson <[EMAIL PROTECTED]>, wix-users@lists.sourceforge.net
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="windows-1252"
>
> are you testing by running from an elevated command prompt? I believe this
> will cause impersonated actions to be elevated.
> No, Running uninstallation from an elevated command prompt is the only way I
> am able to cleanly uninstall the product along with the database. The
> uninstallation fails when I am trying to uninstall by going to Add Remove
> Programs and clicking on uninstall.
>
> If you turned impersonation *off* this would help you for the local
> installation case ? as the action then runs as LocalSystem, which is a
> member of BUILTIN\Administrators
> Which immediate custom actions are you talking about here? And I am assuming
> you want me to edit the MSI with a post build event to turn off
> impersonation for these immediate actions that you mention of?
>
> My product installs a database on a local machine only, which it does create
> sucessfully without any issues even on SQLExpress. Like I mentioned earlier,
> the issue is only when I uninstall and the installer attempts to drop the
> database.
>
> Do you think I should simply do a DropOnUninstall="no" so that the database
> is not dropped by the custom actions generated by the WiXSQLExtension and
> manually drop the database from a VBScript custom action which is deferred?
>
> Jacob
>
>
> On Sun, Mar 23, 2008 at 2:56 AM, Mike Dimmick <[EMAIL PROTECTED]>
> wrote:
>
> > SQL Server 2005 has a very extensive security model of its own. In order
> > to drop a database, the connecting account needs CONTROL permission on the
> > database. This permission is automatically granted to the database owner
> and
> > implicitly to members of the *sysadmin* server role (CONTROL on a database
> > is implied by CONTROL SERVER permission on the server). The
> > BUILTIN\Administrators Windows security group is by default a member of
> the
> > *sysadmin* server role. On Windows Vista the membership of this group is
> > only expressed in the privileged token accessed through UAC, not in the
> > low-privilege token.
> >
> >
> >
> > The modifying SQL custom actions are all executed deferred and
> > impersonated. (As always, the custom tables built by the compiler are read
> > and turned into appropriate deferred custom action data by the immediate
> > actions, but the actual *operations* are performed by deferred actions as
> > part of the installation transaction.) My understanding of the
> installation
> > process under UAC was that even the create actions would not be elevated ?
> > are you testing by running from an elevated command prompt? I believe this
> > will cause impersonated actions to be elevated.
> >
> >
> >
> > If you turned impersonation *off* this would help you for the local
> > installation case ? as the action then runs as LocalSystem, which is a
> > member of BUILTIN\Administrators ? but doesn't help for installation on a
> > remote SQL Server, which some users of WiX may need (as LocalSystem
> > authenticates as the machine on a domain network, but has no network
> > c

[WiX-users] 2 capsules for 3 inches

[Flip Colvin]

Want crazy enjoyable lovemaking sessions every day? Simply click here!

http://www.Permanantups.com/
Women love this

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] MSI Deployment Technology

[dB.]

Apologies if this is slightly off-topic.

 

We have a large enterprise product with tons of installation and
deployment problems produced by years of hacking. We have started
rewriting the pieces in Wix to cleanup the mess, but we still need
something to put things together. We end up with at least a dozen moving
parts, so we want a technology that deals with dependencies and
pre-requisites. Basically we want a small bootstrapper and then
something that looks like the Microsoft SQL Server 2005 Setup. 

 

Anyone has any pointers to commercial/non-commercial products like this?


 

Thx 

dB. 

 

-dB.

dblock.org   / foodcandy.com
 

 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Best Way to Handle Auto Updates

[Victor Sergienko]

I've make a certain research about auto-update.

Short answer is: there's no working solution.

Middle answer is:
* ClickThrough hardly works for SmartClient apps;
* Updater app block compiles only with EntLib 2006, not latest, and is
somewhat broken in .NET 3.5 (configuration is overcomplicated and
doesn't load proper factories);
* NSIS (ops!) offers only a low-level download API.

I stopped on own code based on Updater (it's very well designed, so
you can take pieces from there), that checks for update and runs
msiexec /qb /i AAA.msi REINSTALL=ALL REINSTALLMODE=vomus
after application exit.

A way more details about that research are on my blog:
http://victorsergienko.com/

I wish I could publish the code, but sadly it's now proprietary.


On Mon, Mar 17, 2008 at 10:12 PM,  <[EMAIL PROTECTED]> wrote:
> Hi guys, sorry for double posting this but my earlier post may've been
>  overlooked amongst the spam as I didn't set the subject heading properly.
>  Would really apreciate it if I could get some advise re auto-updates.  I
>  envisage normal rules:
>
>  a) my app checks to see if an update is available and prompts user to
>  upgrade
>
>  b) the update (aka patch) app is downloaded and installed
>
>  I've researched options e.g. the Microsoft Application Updater Block and
>  various home grown solutions on http://www.devx and codeproject etc
>
>  - http://www.devx.com/dotnet/Article/10045
>  - http://msdn.microsoft.com/msdnmag/issues/03/02/BITS/default.aspx
>
>  My current thinking is I should buy or hand-code (or reuse) a homegrown
>  mechanism for detecting new updates & prompting for their download, write
>  a new wix patched install for each update, then execute the wix patch
>  somehow from my app (not clear on this but I assume I have to exit my
>  app then call the patch to install the new one in one step??)
>
>  What would my best option be for providing an auto-update type facility
>  prior to rolling out my application? Would appreciate any advice/options.
>  I assume given this is very, very common there is either a third party
>  component I can purchase or ..?
>
>  more than one opinion really apreciated! :)
>
>  regards
>  ewart
>
>
>
>  -
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
>  ___
>  WiX-users mailing list
>  WiX-users@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/wix-users
>

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Changing INSTALLDIR

[Sneha Gharpure]

Hi,

The scenario is that the installation path has to be decided dynamically.
Our application is deployed under IIS. There are two virtual directories
deployed under the website. There is a dialog that allows user to select a
website under which the application is deployed. So, Home Directory of this
website decides the installation directory. I am setting the INSTALLDIR
property to this home directory of the website on the button click event of
the website selection dialog. 

The problem is that I have created 2 websites in my IIS. One is the default
website and other one I have created whose home directory is "C:\" (say
custom website). The installation goes fine when the application is
installed under this custom website. But in case of default website one of
the virtual directory is installed under "C:\inetpub\wwroot" and the other
one is deployed under "C:\". 

Following is sample code that I have used to create directory structure.


  




  


My guess is that the TARGETDIR is having the value "C:\" and thats why one
of the directory is getting deployed under "C:\". But what about the other
directory that is getting installed under "C:\inetpub\wwwroot"

Any pointers? 

Thanks in Advance,
Sneha
-- 
View this message in context: 
http://www.nabble.com/Changing-INSTALLDIR-tp16248479p16248479.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users