File / Folder Resolution MSI Installer

Question

I am trying to install a set of files in the programdata folder using the main MSI installer. Since the contents of the files are dynamic and are generated during the installation process, I create files in C # code during the installation.

Files are created in the appropriate folders, and everything is fine, except for file permissions. As far as I understand, files should inherit their permissions from the parent folder (if they are included), but in this case this does not happen. The files that I create must be writable by regular users, and I do not want to explicitly set permissions for each file I create. Could the problem be that the installer works with different permissions, and therefore the files do not inherit permissions from their parent folders?

Thanks in advance for your help.

Answer 1

the installer works with administrator access, which will allow him to change something in the program files. A typical user would have read-only access to the program files folder and the ProgramData / Common Application Data folder.

The MSI lock permissions table allows the installer to change the permission of the folder after it is created in the ProgramData / Common Application Data. Visual Studio configuration projects do not support the MSI lock permissions table, so if you need a folder that you created for writing to ordinary users in the configuration project, you need to grant the right in a custom action using SetNamedSecurityInfo or change the MSI database as a message to build a step. You can also find MSI development software that can handle the MSI lock permissions table.

Answer 2

I had a very similar problem and I was able to solve it using here .

Answer 3

If you manually set permissions for a folder using a user action and generate and install files with another user action, the problem may be caused by the execution order.

Answer 4

I had a similar problem. The problem here is that msi created files using the SYSTEM user. And the application at run time used the registered user (who did not have permission to write to this file). What I did was create a new file (if it does not exist) during the initialization of the application using the file created by the installer. Then this file will have write permission. This is not a good practice, but it solved my problem.