Building an Azure Web Site Application, Part 2: Diagnostics and Logging

In the previous article, we created a very simple starter web application and published it to Windows Azure. In this post, we’ll look at how to diagnose problems with that application.

Since we’re deploying our application to Azure , we don’t have access to the Windows event log, or to log files that we might  generate, in the way we would if we were hosting in a more traditional environment (or in a Windows Azure virtual machine for that matter). Fortunately, we do have other tools available.

Let’s look at some tools we can use to diagnose a problem that we already have with our simple application. If we navigate to /account/login on a locally running version of the site, it comes up without any problems. Visit the same URL on the Azure version, and instead you get an error page. The page is intentionally vague about the cause of the error.

image

At this point, you are probably wanting to turn off the custom error messages so you can see the exception. Let’s return to the management portal to do that. Click on the Websites side-tab, select your site, then click the Configure link. Scroll down a bit to the Diagnostics section.

image

Turn on all three of the diagnostic options. Don’t forget to scroll down and click the Save button.

image

Then try your application again. It will take a little while to respond – essentially, you’ve just changed the web.config, so it’s restarting. Now you’ll get detailed error messages. That doesn’t mean you’ll see the yellow screen of death. The end-user experience is the same. What you get with the detailed error messages is the ability to see those error messages in the management portal. The detailed error messages and logs get written to an FTP site, which you can access once you’ve configured a user name. You’ll find the link for that on the Dashboard page of the portal, on the right side and down a bit:

image

After you do that, your username and FTP URL will both show up in the section below the “quick glance.” Click on the FTP URL and you can view the detailed errors, one html file per error. The full IIS logs for your site are there as well, so you can download and analyze them at your leisure.

The detailed error message for this problem isn’t very helpful, though:

image 

If only there were a way to see the stack trace…

ELMAH To The Rescue

There’s a great package called Elmah that provides handlers that you can install into your web application. These handlers record exceptions that your application encounters, logs them, and also makes them available for your review directly within your web site. This is not an Azure-specific package, but it will work just fine with your Azure web site.

Go ahead and install the Elmah NuGet package. Since we’re using an MVC site, you can install the Elmah.MVC package, which will automatically install the base Elmah package as well. You can either use the “Manage NuGet Packages” option you get when right-clicking the project in Visual Studio Solution Explorer, or you can do “Install-Package Elmah.MVC” in the Package Manager Console.

Once that’s done, you can republish you application to Azure. If you visit your /account/login URL again, it will still fail. Then you can visit /elmah on your site. This will tell you “You do not have permission to view this directory or page.” This is good – you don’t want random Internet users to be able to read your error logs! To enable you to read the errors right now, though, let’s change the web.config. At the end, just before the </configuration> end tag, add a section like this:

  <elmah>
      <security allowRemoteAccess="1" />
  </elmah>

Now you can republish to Azure. Once you’ve done that, you should be able to go to yourappname.azurewebsites.com/elmah, and see something like this:

image

Try /account/login again, then go back to /elmah. Now you’ll see an entry for the exception you just experienced. Click on it, and you’ll see that yellow screen of death you’ve been missing!

image

When we scroll over to the right a bit, we finally see the problem: System.InvalidOperationException: The ASP.NET Simple Membership database could not be initialized. For more information, please see http://go.microsoft.com/fwlink/?LinkId=256588

---> System.Data.ProviderIncompatibleException: An error occurred while getting provider information from the database. This can be caused by Entity Framework using an incorrect connection string. Check the inner exceptions for details and ensure that the connection string is correct. ---> System.Data.ProviderIncompatibleException: The provider did not return a ProviderManifestToken string.

---> System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 52 - Unable to locate a Local Database Runtime installation. Verify that SQL Server Express is properly installed and that the Local Database Runtime feature is enabled.)

---> System.ComponentModel.Win32Exception: The system cannot find the file specified

So, the reason we cannot access the login page is because we have not yet set up a database in which to store the login information! In the next episode, we’ll fix this problem and start actually building our application.

Important:

Right now, your web application will let anybody view your error information via the /elmah URL! Be sure to remove or comment out that <security allowRemoteAccess="1" /> . Once we have login working, we can configure it so that only administrators have access to that URL, but for now, it needs to be disabled!

No Comments