Calcs.exe, Assigning the permissions

I can't think of any packaging product which caters *properly* for permissioning (if ANYONE mentions Windows Installer's Lockpermissions table I will seek them out and.....)

Why not shell out to START.EXE instead? You can tell it that you don't want a window using the '/B' switch. Also, get to know SetACL instead of CACLS, as it can permission the registry as well as the file system.

Do you still get the same issues in Vista if you turn off the UAC ? 
How are you calling CACLS?  Immediate/Deferred CA?  User or System context?
Are you setting permissions on a local or global basis?

Apart from SetACL, there is also the native secedit utility that is installed automatically with current Windows operating systems.

way would be to "wrap" the cmd.exe / command shell in a WSE script, and call it using the "hidden" parameter. any parameters passed to the shell are executed, but are hidden. As the wse script can be set to "As Invoker" you should not have any problems with permissions under Vista.
As Ian has already stated, the lock tables *should not* be used.
Personally I prefer to use SecEdit + security template, as this is more flexible that CACLS, and not as complicated as SetACL.
Cheers
Phil

Take advantage of the wixca.dll as posted by spartacus at Suppress Custom Action EXE, it will do what you are after.

I will make use of SetACL and secedit utilities to see if these made a difference also check on wixca.dll.
Thanks

Using a different tool won't alter the fact that you get a UAC prompt . We are just presenting alternative tools. You'll need the WixCA.DLL work-around to bypass the prompt.

Hi Ian,
if you create a wse script that wraps the call to Secedit with the parameters (ensuring that the wse is compiled to be called "as involker"), and the CA that calls the wse script is in execute deferrred (of course, making sure that the deferred seq. is evelated) then you do not get the UAC prompt...

Cheers
Phil

Hi,some more details and other options for giveing permissions can be seen in my article here:
www-secure.symantec.com/connect/articles/different-ways-giving-permissions-your-windows-installer
 
Hope this helps.

We have recently been using SetACL.exe to perform the permission settings. We integrate this into our MSI/WSI templates so all you have to do is create a property with the directory that you want the permissions created on.
One of our technicians found this and implemented it into the WSI template for our use. 
If the property is not there, it doesnt worry about the SetACL.exe. We set a custom action in execute deferred that is directly below Create Folders. It calls the SetACL.exe and applies the permissions to the directory and all sub directories that may get created as well. This is done before all the files are installed, so it is much quicker than running cacls after the directory is populated. We have a function that is in our wrapper that looks for the SetACL.exe on the local machine, if it is not there, it copies it down to the pc. Eventually this file will be in all our corporate images.
The SetACL.exe can be found here and it has many examples there as well. It is a very robust application as it can set directory, registry, services, and more.

Good Luck

Kevin Elwell

So, you must therefore have a separate action for extracting the EXE from the Binary table, right?

Take note that all of you using CA's like this should be using the Directory variables and CustomActionData if your users have the ability to change the installation locations.

for example

[Directory]
[#filekey]
[$componentkey]

If you hardcode the path in your CA's and the users changes the installation directories your install's will fail. You should be building these CA's to cater for ALL installation scenario's for best practice results.

However, permissioning is usually an aspect of a corporate environment where the installation locations tend to be hard coded to fit in with the build design. Hopefully, any software intended for public consumption will follow the correct coding practices so that any content requiring write access will be in the user folders where write access is already provided.
The good thing is that the increasing security of operating systems such as Vista is forcing developers to mend their ways and produce better code that does not assume each user is a local admin.