There are a number of times when a LightSwitch application works perfectly on a developer’s machine, but as soon as it has been deployed to an Internet Information Services (IIS) machine, it no longer works. Problems can range from IIS not being configured correctly to the database connection string being incorrect. Or an assembly might not have gotten deployed to the IIS machine. I would like to share a few debugging techniques that I regularly use in order to help system administrators diagnose problems in their deployed applications. For more information on how to configure your web server and how to deploy a LightSwitch application, see Beth Massi’s deployment guide.
Before I continue, I’m going to set your expectations correctly. There definitely isn’t a silver bullet that is going to solve any and all problems you will hit when deploying your application. However, what I’m going to provide is a list of steps you can use to diagnose the most common problems we’ve encountered. These steps are the first thing I use when someone stops by my desk and says “I’m having a problem with my application”. If (and when) these steps aren’t able to help you diagnose your problem, they will at least provide you with some good information to take to the forums where others may be able to assist you.
The Dreaded Red X
In the LightSwitch world, the dreaded red X is analogous to the Red Ring of Death on an Xbox 360. OK, so a red X in LightSwitch isn’t as catastrophic. You don’t have to send your app away for a month to get it repaired. But it is a major indication of a problem in your application. When your application fails to load data successfully, the screen will display a red X and the tool tip will say “Unable to load data. Please check your network connection and try loading again.”
These red X’s really mean that an exception was thrown by executing the query.
So what do you do?
A little known secret about LightSwitch is that the server has a Diagnostics subsystem integrated with ASP.NET tracing. LightSwitch’s Diagnostics subsystem is a lot more powerful than just telling you what exception was thrown when issuing a query. You can use it to trace through the actions that were requested of the server, and what steps the server took in response to each action. So even if things seem to be working, you can get more information about what your application was actually doing.
Diagnostics is disabled by default when you create a new LightSwitch application. This is for both performance and security reasons. The performance reason is kind of self-explanatory. Even simple tracing on the server will lower its throughput. The security reasons are because any registered user of your application can get to the diagnostics log when it is enabled and when you enable remote machines to see the diagnostics.
There are 5 app settings that control the behavior of the Diagnostics subsystem:
|Microsoft.LightSwitch.Trace.Enabled||true, false||Enables diagnostic tracing on the server. Default is false.|
|Microsoft.LightSwitch.Trace.LocalOnly||true, false||When set to false, allows machines other than IIS server to retrieve diagnostic information. Default is true.|
|Microsoft.LightSwitch.Trace.Level||None, Error, Warning, Information, Verbose||Defines the level of trace information to be logged. The values are in increasing order, i.e. Warning writes more log entries than Error. Default is Information.|
|Microsoft.LightSwitch.Trace.Sensitive||true, false||Enables “sensitive” information to be written to the diagnostic log. Sensitive means actual data values, such as addresses, balances, etc. Default is false.|
|Microsoft.LightSwitch.Trace.Categories||Microsoft.LightSwitch, unlimited other values||The semi-colon separated list of categories that will be enabled at the specified trace level. Default is Microsoft.LightSwitch. Extensions may declare more, or you can declare new ones in your own app.|
There are two ways to enable LightSwitch Diagnostics.
Before you publish your app, change the settings in your Web.config.
To change the Web.config, switch your Solution Explorer to “File View”.
Then click on the “Show All Files” tool bar button.
Under the “ServerGenerated” project you will find the “Web.config” file, which you can edit the settings under “configuration/appSettings”.
After you publish your app, change the Application Settings in IIS Manager.
Open IIS Manager and find your web site on the left side. On the right, double click on the “Application Settings” icon under the “ASP.NET” heading.
You will see the Microsoft.LightSwitch.Trace.* settings which can be edited to your desired settings.
Retrieving Diagnostic Information
Once you have enabled diagnostics, you can now inspect the information that is being logged in your application. Remember, any request before tracing was enabled won’t show up in the trace information. So you may need to reload your app in order to get the trace logs populated. ASP.NET provides a web site you can load to view the trace log. The URL of the web site is: <Path To LightSwitch App>/trace.axd. So in my Contoso app above the URL is http://MyServer/Contoso/trace.axd. Navigating to this site shows me the following:
As you can see, LightSwitch made 4 service requests when it was loading my application. The first is a call to “GetAuthenticationInfo”. This is used to see if Access Control was set to None, Windows, or Forms. If it is Forms, LightSwitch displays a Log In screen before displaying the application. The second is the call we are interested in: “Customers_All”. This call executes the Customers query. The last 2 are service calls to get whether the current user can Insert, Update, and Delete certain entity types. In my app this was for the Customer and Order types.
Since I know that the “Customers_All” call is the one causing me problems, I click on its “View Details” link to drill into that call. And here I am greeted with a big red message:
I see an exception has occurred “Login failed for user” and the name of the account my IIS Web Application is running under. This tells me that my application tried using the current account to log into the SQL Server database. However, that account isn’t set up as a user on my database. I forgot to change my connection string when I deployed. It was working fine on my development machine because it was running under my account. But once I deployed, it is now running as a different account that doesn’t have privileges to access the database. Changing the connection string to use valid credentials fixes this issue.
I have just walked you through how to diagnose a very common issue: the database credentials no longer work once the application is deployed out into the wild. However, doing the steps outlined above can help diagnose almost all red X issues popping up in your application. You may not immediately see the problem, like we did above, but it will give you information to build up your knowledge on what is going wrong. Using the Diagnostics subsystem is a trick that every LightSwitch developer should have up their sleeve.
Please be aware that tracing, especially remote tracing, should only be used when debugging and deploying your application. When you move your application into production, be sure to set Microsoft.LightSwitch.Trace.LocalOnly to ‘true’ in your application. Also, in production, tracing should only be enabled if you really need it.
Load operation failed for query ‘GetAuthenticationInfo’. The remote server returned an error: NotFound.
So if the red X error described above is ‘dreaded’, the “GetAuthenticationInfo” error message can probably be described as ‘execrated’. (Don’t worry; I had to look it up in a thesaurus.) Many hours inside and outside of Microsoft have been spent trying to debug this error. The problem is, there isn’t just one issue that causes this error. There are seemingly endless issues that cause this error. The reason is explained above. ‘GetAuthenticationInfo’ is the very first service request that LightSwitch is trying to make when your app loads. Thus, if there is any configuration issue with your IIS machine, web app, virtual directory, etc. this error is going to be displayed. Unfortunately, using the diagnostics tracing outlined above isn’t going to help in this situation. More than likely, the service call isn’t even getting into LightSwitch code. As such, our diagnostics isn’t able to log information, since it isn’t getting that far.
So in order to diagnose the problem here, we will use another tool, Fiddler. Fiddler is a tool that every web developer and IT administrator should have at their disposal. It logs all web traffic between your computer and the IIS web server. It will do the tracing that the LightSwitch diagnostics can’t do. Download Fiddler and start the program on your client machine. Then try to load your LightSwitch application again. You should see web requests and responses in Fiddler.
When you start Fiddler, you will see the requests on the left side. To look at the information being exchanged, click on the “Inspectors” tab at the top, and select the inspector for both the request at top and response at bottom. My 3rd request, which was for ‘GetAuthenticationInfo’, returned a ‘500 – Internal Server Error’ response. The text inside shows what the server responded with. Here is says
An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".
This error message tells us that an error occurred, but the server doesn’t want to display the details of the error. So we need to configure the server to tell us the error. To do this, you can modify your Web.config to add the “customErrors” section it says to add and then re-publish your application. Or you can modify the settings in IIS Manager. In IIS Manager, navigate to your Web Application on the left side. On the right, under "ASP.NET”, double-click on “.NET Error Pages”.
On the far right side, under the “Actions” group, click on “Edit Feature Settings…”
In the Edit Error Pages Settings, select either “Off” if your client is on another machine, or “Remote Only” if you are using the IIS machine as the client.
Now that custom errors are turned off, hit your application again and look at the Fiddler trace. You should still get a “500 – Internal Server Error” message, but the response should give you better information on what the internal server error was. Now I get:
As you can see, the error message is “Unrecognized attribute ‘targetFramework’”. Doing a quick Bing search on that error message tells me that I need to make sure the App Pool that is serving my site is set to the 4.0 framework. So to fix this error, I right click my “Contoso” Web Application in IIS Manager and select “Manage Application” –> “Advanced Settings”. This allows me to change my Application Pool from “Classic .NET AppPool” to the correct “ASP.NET v4.0”. After doing that, I reload my application and everything is working again. (Note: When using LightSwitch deployment, the Application Pool will be set correctly. However in my case someone else accidently changed it.)
As I’ve said, these two diagnosis techniques may not solve every issue you can run into after deploying your LightSwitch application. But they are great first steps that can be taken to help you determine what the error you are running into is. And hopefully with that information you will be able to fix the problem yourself, go to Bing and search on the issue, or go to the LightSwitch Forums and use that information to get a faster resolution.