It’s not uncommon that ASP.NET applications have the need to use a personal .config file to write some runtime information. Since ASP.NET applications are not granted the permission to create or edit files on the server, the best place to store persistent data is a table in a database server (not an Access database). However, let’s assume that you just want to write to a file. How can you work around the lack of write permissions? The .NET documentation suggests that you change the named security information for the file. On an NTFS formatted disk, this can be easily done manually by displaying the Properties dialog of the file and selecting the Security tab. Next, you ensure that the ASPNET user is authorized to operate on the file with write permissions. So far so good.
What happens when you deploy the application? In most cases, the administrator will be more than happy (so to speak…) to take care of it. However, should you have the need to accomplish that task programmatically, be ready to face a bad and a good news. The bad news is that you must necessarily resort to Win32 API calls and in particular to the SetNamedSecurityInfo API function from advapi32.dll. Neither version 1.0 of the Framework, nor Everett (v. 1.1) will provide a redesigned managed API for system security. In the end, either you write a managed wrapper for the API (sample code is available at http://www.gotdotnet.com/team/csharp/code/default.aspx) or resort an extremely handy tool that ships with the operating system: cacls.exe. The following command line shows how to configure data.config so that ASP.NET applications can write to it.
cacls.exe data.config /E /G: ASPNET:FThe /E switch indicates that you want to edit the security descriptor, not replace it. The /G switch indicates that you want to add a new user to the group with the specified privileges. If the specified user exists in the group, the existing account is modified. The F argument means that you want to give the ASPNET user full control over the file. This is exactly what ASP.NET applications need for a smooth setup. The best way to integrate this code with the setup is by defining a custom action on the Visual Studio .NET setup project and use that command line for it.
