0

I'm deploying a .NET application with VS2010. My application creates .txt file in the logs folder in the same directory with .exe: 

app.exe
add.exe.config
logs (folder)

I used setup project to create a MSI installer. When I installed in the client machine C: drive or any drives I have no problem to create the .txt file, but when I installed in C:\Program File\myAppFolder or C:\Program File(x86)\myAppFolder I cannot to create the .txt file.

ProgramFOX
  • 6,131
  • 11
  • 45
  • 51
May
  • 1
  • Yes. Don't try to write to `C:\Program Files`. It's not allowed since at least Windows Vista. (Actually, before then - it was deprecated as far back as Windows XP.) There are dozens of posts here about where applcations should save their data on Windows. A search for them should find one for you. Start [here](http://stackoverflow.com/q/13163611/62576). – Ken White Apr 24 '13 at 01:22

3 Answers3

1

It is a poor design to write to install location for your application. It is better to write to the ApplicationDataFolder. The ApplicationDataFolder is under the user profile and the application will have access to write there when run as that user. @Ken White provided a very good pointer to an existing StackOverflow answer about this.

If this is a legacy application that must write to that folder, then you'll need to modify the permissions on the log folder such that all users can write to the folder. This is possible to do with the Windows Installer (aka: MSI) but I'm not sure that the Visual Studio setup projects expose it. The WiX toolset definitely supports doing such things.

Community
  • 1
  • 1
Rob Mensching
  • 33,834
  • 5
  • 90
  • 130
0

An old post but I needed to do similar recently so I guess it is still valid! While I don't advocate bad design, in the real world sometimes we have to bend to requirement.

Writing to the application folder is possibly under Win7 and it is possible to set this up via an installer class in an MSI created by VS2010. You just need to give a relevant group (suggest either the "Users" group, or if you want to give more control over who gets what, supply a selection screen) Write-Data access.

Using DirectoryInfo on a path you can then get the security data from GetAccessControl. When you have your Group known, get the SID for the group and AddAccessRule also supplying the required ControlType value.

Then set the access control on the DirectoryInfo object (SetAccessControl) using the security data object.

You can get the SID from the Groups principal object if you do a search with PrincipalSearcher.

Hope this helps

paul

Paul Eden
  • 338
  • 1
  • 3
  • 10
0

This generally all depends on:

  1. Whether your app requires to be run as administrator for other reasons and..

  2. Whether your app is provided for limited users.

If the app requires elevation for a bunch of other reasons (and not just updating files in restricted locations) then the normal way is to have an elevation manifest embedded in your app. This isn't a good thing from the security point of view, but if you absolutely need admin privilege then this is the way to do it.

If the only operation requiring elevation is updating/creating data in the Program Files folder then don't put the file there. Every case of this that I've seen has been lazy programming where the code just refers to the file name and consequently it goes in the Program Files folder (more accurately in the same folder that the app runs in). The cure for this is to put the data file in the correct location (such as User's Application Data folder). As Rob Mensching says, you should alter the permissions on the install folder only if this is a legacy app that you cannot change.

PhilDW
  • 20,260
  • 1
  • 18
  • 28