Software Deployment

If you install SetAcl.exe as a file through the MSI you should use "Execute Program From Destination" instead....for the uninstall part. Remember to condition the CA: IF REMOVE~="ALL"...and place it above the RemoveFiles action.

BTW, for file permissioning, I prefer to add SetACL in the Binary table and run it like that because, if you run it after InstallFinalize, it can potentially take F O R E V E R to run, since it has to permission every file in the tree. If you run it after CreateFolders, files copied into those folders can inherit the folder's permissions. For larger apps, the time difference can be significant.

Spot on, but you may as well leave SetACL there. It does no harm.

It works, but I had to put the custom action after the InstallFinalize, otherwise the setACL file is not recognized on the system. I guess this isn't a problem.

Thank you.

Marin,

I think you are using an immediate custom action. Am I correct?

Yes,

But I am still struggling with the installation.

During the uninstall the setACL is removed from the system, so the custom action cannot run anymore. I tried to create an if statement, but I get an error: Internal Error 2717 - ActionSetCustomActionData

I created a property names VAR_SETACL and gave it the value c:\windows\system32\setACL.exe
Then I created an if statement

If File exists VAR_SETACL then
'Do the custom action
End

But then the error appears.

If you install SetAcl.exe as a file through the MSI you should use "Execute Program From Destionation" instead.
Set the component holding the file as permanent using the "msidbComponentAttributesPermanent" attribute bit on the component. This will prevent it from getting removed during uninstall as it seems that you are calling the file through the custom action after the file as been removed.

Marin,

You should not use an immediate custom action to modify the system, see the best practice.
http://msdn2.microsoft.com/en-us/library/aa372409.aspx
Specifically: http://msdn2.microsoft.com/en-us/library/aa367851.aspx

Also, if you use InstallShield you could use the support directory mechanism.
http://helpnet.installshield.com/robo/projects/HelpLibDevStudio9/SetupFilesView.htm

Hi Dennis,
i can strongly second every line that Frank and Ian wrote.

@Ian: Nice idea with applying the permission to the folders and let inheritance do the rest!

Regards, Nick

@Ian: Nice idea with applying the permission to the folders and let inheritance do the rest!Born out of the experience of waiting for almost an HOUR for permissioning on WebLogic's BEA web server to complete...LOL...

What was even more hilarious was when I picked up the job for doing a second update to that product, I noticed straight away that another scripter had switched it BACK to permissioning after the file copy because "that's the way it is in the corporate template. It'll never get past QA." No amount of explaining about permission inheritance, nor detailing the multitude of packages I'd released which had already passed QA, would make him change his ways. Idiot. There's a nice quote which someone uses on another (unrelated) forum I belong to:

"Never argue with an idiot: they drag you down to their level and beat you with experience."

Nice quote Ian,

As for the SetACL thingo put a condition on the CA of

NOT Installed

I always use SECEDIT to modify my file/registry perms. I create my security template on my reference system and then add the secedt.sdb and *.inf security template file to my package then create a custom action to run it jsut before the InstallFinalize phase. If you do this you don't really have to add any 'foreign' files to the system although doing so is no big deal.