The easiest way to create business applications for the Desktop and the Cloud
You have built a LightSwitch application and deployed it to an Azure Web Site and everything is working as expected. One day you receive a call that your application is not functioning as it should be. What should you do? In this article, I’ll show how you can debug your LightSwitch application when it is deployed to an Azure Web Site. If you are looking for information on how to debug your LightSwitch in non-Azure production site, you could refer to this article by Eric Erhardt: Diagnosing Problems in a Deployed 3-Tier LightSwitch Application. You can also read Tracing: Debugging Your LightSwitch Application in Production article by Michael Washington that covers tracing when your LightSwitch application is deployed as a web application.
Debugging a LightSwitch application that has been published to Azure requires more steps than the one published to IIS. In addition to turning on tracing for the application, you also need to turn on application diagnostics in Azure management portal and select the type of the storage for the diagnostics data. I’ll show you the steps by examining a problem in a published LightSwitch application that is hosted in an Azure Web Site.
Assume you have built an application that tracks the employee’s history in the company, which department the employee worked for, and the duration in each department. Then you’ve published it to an Azure Web Site and everything looks good.
One day you received a phone call from the site admin saying that the application is not working. It is failing to load with the below error and asked you to look into it to figure out the problem:
To investigate this issue, you first need to turn on application diagnostics in Azure. You go to Azure management portal https://manage.windowsazure.com and access the website that is hosting the application, then you select “configure” tab and go to application diagnostics setting.
Microsoft Azure gives you 3 choices on how to collect the diagnostics data, file system, table storage and BLOB storage. For details information on each one, you can refer to this article: Enable diagnostic logging for Azure Web Sites. For our example, I’ll use table storage. Go ahead and turn on application logging (Table Storage), then select “Error” for the logging level from the dropdown list as shown below.
Click on the “manage table storage” button to create a Windows Azure table that will store the diagnostics data of your application. You could specify the name of the table or leave the default name. Save your changes.
Now that you’ve turned on Diagnostics in Microsoft Azure Web Site, the next step is to turn on tracing for your LightSwitch application. Microsoft Azure Web Sites allow you to update your application web configuration settings easily by adding a setting to the app settings section in the manage tab page. With this option, you don’t need to access the server and update the web configuration file to enable tracing, the Azure web site will use the value(s) in this section to override the value(s) of the web configuration file. Go ahead and add 2 settings, “Microsoft.LightSwitch.Trace.Enabled” with a value “true” and “Microsoft.LightSwitch.Trace.Level” with “Error” as a value and then save your changes.
Now it’s time to collect the diagnostics data and figure out the cause of the problem. Visual Studio provides access to a subset of the site management functions and configuration settings available in the management portal. For more information about troubleshooting Azure Web Sites in Visual Studio see: Troubleshooting Azure Web Sites in Visual Studio.
Back to our example. Open Visual Studio and go to server explorer, expand the Windows Azure node. Since you chose to save the diagnostics data in Azure table, expand Storage and select the table from the storage you created to view the data:
The table shows that an error has been reported with the following message:
[Microsoft.LightSwitch.DataService][Application:Error][LightSwitchServiceApplication.ApplicationData:Employees] An exception has occurred: Microsoft.LightSwitch.DataServiceOperationException: The underlying provider failed on Open. ---> System.Data.EntityException: The underlying provider failed on Open. ---> System.Data.SqlClient.SqlException: Login failed for user 'amrtest'.
This indicates that the user could not access the underlying database. A quick comparison between the user credentials that the application stores in the web configuration file, and the credentials of the Azure database indicates that the application has the wrong credentials. So the solution for this issue is to update the application web configuration (web.config) to have the right credentials. Luckily, Azure Web Site management portal allows you to update the connection string of your application by adding a new connection string setting to the connection strings section. Go ahead and add a new connection for your application with the right credentials and then save your changes.
As I showed in this blog, enabling diagnostics for a LightSwitch application in Azure Web Sites involves turning on diagnostics in Azure Web Sites, specifying the storage type for the data being collected, and turning tracing on for the application in the web.config. I showed how the Azure management portal makes it easy for you to configure your application and change its settings without manually changing the web configuration file. Please let us know what you think by leaving a comment below. If you’re experiencing issues with your deployed app, please use the forum for troubleshooting.
Amr Altahlawi, Developer, LightSwitch Team
Any advice on how to profile SQL Server in Azure?
Another great article from the team! And very timely too. Just what I needed, when I needed it. I'm having trouble with an app that I've published using provider-hosting, instead of auto-hosting (seeing as we've now been forced, kicking & screaming, into this new hosting model), so I hope this will allow me to track down what's wrong with the app. It works fine when debugging on losthost, & when auto-hosted, just not when it's published as provider-hosted.
Umm, that's localhost, not losthost. Not being a web developer, I'm learning all this stuff as I go. Is it possible to get an article specifically written about debugging a SharePoint-enabled LightSwitch app that's been published with provider-hosting (to an Azure website), & added to a SharePoint site? I'm not sure where to even start.
Yann - have you seen this post regarding debugging? social.msdn.microsoft.com/.../lightswitch-sharepoint-app-debugging-http-error-4010-unauthorized - Basically enabling tracing is still the first and best thing to do here when it comes to debugging. I have a feeling you may already know this - so let me know if it doesn't help. - Matt Sampson
@JoshBooker - Try this for profiling - blogs.msdn.com/.../cloudtip-14-how-do-i-get-sql-profiler-info-from-sql-azure.aspx