Export (0) Print
Expand All

Troubleshooting the Deployment of a RIA Services Solution

WCF RIA Services

[WCF RIA Services Version 1 Service Pack 2 is compatible with either .NET framework 4 or .NET Framework 4.5, and with either Silverlight 4 or Silverlight 5.]

Troubleshooting a WCF RIA Services solution presents a unique challenge because an exception can occur at one of many different layers. You need to understand how these different layers report errors to effectively troubleshoot your application. This topic introduces these layers and provides some techniques for troubleshooting your RIA Services applications when an exception occurs. Also, many of the issues you may encounter in deploying a RIA Services have been anticipated in the new deployment guide, for details see A Guide to Deploying RIA Services Solutions.

In a RIA Services application, exceptions flow in the following order from the lowest originating layer to the client:

  1. Domain Service

  2. RIA Services Service Host

  3. WCF

  4. ASP.NET

  5. IIS

  6. Silverlight Application

Exceptions flow from layers

By default, the customErrors element of a Web.config file is set to RemoteOnly, which means a remote client will not receive the detailed ASP.NET error information. To debug your application, set customErrors to Off so that you can see the detailed ASP.NET error from the client.

Note Note

Do not make your application publicly available with customErrors set to Off as the error message may expose sensitive information to users.

All exceptions originating from within a domain service are sent to the Silverlight client with an error status code of 200. All exceptions thrown at the WCF layer or lower are sent to the Silverlight client with a status code of 404. You can run the Fiddler HTTP debugger to see the actual error.

Directly browsing to the .svc file for your domain service is often a helpful step to see whether the WCF service is available. However, determining the path to the .svc file is not simple because the .svc does not exist in your solution. You can browse directly to the domain service in a Web browser by using the following pattern:

http://[host]/[modified class name for domain service].svc

You determine the modified class name by using the fully qualified class name and substituting a dash (-) for every period (.). So a domain service that is named:

ExampleApplication.Web.CustomerDomainService

has a .svc file named:

ExampleApplication-Web-CustomerDomainService.svc

If this file is hosted on localhost, you browse directly to the file by navigating to:

http://localhost/ExampleApplication-Web-CustomerDomainService.svc

If the service is available, you will see a Web page with information about services and how to test a service. If the service is not available, you will see an error page that may have information which will help you determine the problem. If you receive an error, the exception probably originated at the RIA Services Service Host layer.

When an unrecoverable error occurs during the processing of a DomainService operation, the OnError method is called. You can override this method to inspect errors before they are sent to client.

You troubleshoot exceptions at the WCF layer just like you would troubleshoot any WCF service. For more information about diagnostic tracing for WCF services, see Tracing.

An exception that originates at the WCF layer will not show up in Fiddler. You can troubleshoot a service exception by attempting to browse to the .svc file. If you can browse to the .svc file without an error, but the service fails at run time, then the exception may originate at the WCF layer.

For exceptions thrown at the ASP.NET and IIS layers, information from your RIA Services application is not included in the stack. You may see exceptions at this level for situations such as:

  • The Web.config file does not have the correct HttpModule element for the version of IIS you are using.

  • WCF is not activated on your Web server.

Show:
© 2014 Microsoft