by Tom Dykstra
This tutorial series shows you how to deploy (publish) an ASP.NET web application to Azure App Service Web Apps or to a third-party hosting provider, by using Visual Studio 2012 or Visual Studio 2010. For information about the series, see the first tutorial in the series.
In this tutorial, you set folder permissions for the Elmah folder in the deployed web site so that the application can create log files in that folder.
When you test a web application in Visual Studio using the Visual Studio Development Server (Cassini) or IIS Express, the application runs under your identity. You are most likely an administrator on your development computer and have full authority to do anything to any file in any folder. But when an application runs under IIS, it runs under the identity defined for the application pool that the site is assigned to. This is typically a system-defined account that has limited permissions. By default it has read and execute permissions on your web application's files and folders, but it doesn't have write access.
This becomes an issue if your application creates or updates files, which is a common need in web applications. In the Contoso University application, Elmah creates XML files in the Elmah folder in order to save details about errors. Even if you don't use something like Elmah, your site might let users upload files or perform other tasks that write data to a folder in your site.
Reminder: If you get an error message or something doesn't work as you go through the tutorial, be sure to check the troubleshooting page.
Test error logging and reporting
To see how the application doesn't work correctly in IIS (although it did when you tested it in Visual Studio), you can cause an error that would normally be logged by Elmah, and then open the Elmah error log to see the details. If Elmah was unable to create an XML file and store the error details, you see an empty error report.
Open a browser and go to
http://localhost/ContosoUniversity, and then request an invalid URL like Studentsxxx.aspx. You see a system-generated error page instead of the GenericErrorPage.aspx page because the
customErrors setting in the Web.config file is "RemoteOnly" and you are running IIS locally:
Now run Elmah.axd to see the error report. After you log in with the administrator account credentials ("admin" and "devpwd"), you see an empty error log page because Elmah was unable to create an XML file in the Elmah folder:
Set write permission on the Elmah folder
You can set folder permissions manually or you can make it an automatic part of the deployment process. Making it automatic requires complex MSBuild code, and since you only have to do this the first time you deploy, the following steps how to do it manually. (For information about how to make this part of the deployment process, see Setting Folder Permissions on Web Publish on Sayed Hashimi's blog.)
- In File Explorer, navigate to C:\inetpub\wwwroot\ContosoUniversity. Right-click the Elmah folder, select Properties, and then select the Security tab.
- Click Edit.
In the Permissions for Elmah dialog box, select DefaultAppPool, and then select the Write check box in the Allow column.
(If you don't see DefaultAppPool in the Group or user names list, you probably used some other method than the one specified in this tutorial to set up IIS and ASP.NET 4 on your computer. In that case, find out what identity is used by the application pool assigned to the Contoso University application, and grant write permission to that identity. See the links about application pool identities at the end of this tutorial.) Click OK in both dialog boxes.
Retest error logging and reporting
Test by causing an error again in the same way (request a bad URL) and run the Error Log page. This time the error appears on the page.
You have now completed all of the tasks necessary to get Contoso University working correctly in IIS on your local computer. In the next tutorial, you will make the site publicly available by deploying it to Azure.
In this example, the reason why Elmah was unable to save log files was fairly obvious. You can use IIS tracing in cases where the cause of the problem is not so obvious; see Troubleshooting Failed Requests Using Tracing in IIS 7 on the IIS.net site.