How to Deploy RIA Services-based Application

Configuring the Deployment Server

You have your application ready and it works great on your development machine. Now you want to deploy it to a server and share the awesomeness …

The first thing you will need is a server with .NET 4 RC installed. If the server has RIA services installed as well, even better.

In House Servers:
If you are setting up an in house server, you can download .NET 4 RC from here.

To install RIA Service RC on your server, download the MSI locally from here and then run it as such -
msiexec /i RIAServices.msi /SERVER=true

More details on this option are in Deepesh’s blog here.

BIN Deployment:
If you have access to a .NET 4 RC server but do not have permissions to install RIA Services on it, you can choose to carry the RIA Services bits in the Web Applications BIN folder

If you are using the Visual Studio Build->Publish option to deploy your application, make sure the following three assemblies under the Web Application->References have been marked as Copy Local = True

If you are copying the bits over manually to your deployment server, copy the above three assemblies to the Web Applications BIN folder right next to your [WebAppName].dll

Deploying LINQtoSQL Applications:

Starting with RIA Services RC, the RIA Services LINQtoSQL Provider has been moved to the RIA Services Toolkit.

If you have are deploying an application that uses L2S you will need to either manually deploy the Microsoft.ServiceModel.DomainServices.LinqToSql assembly in your servers GlobalAssemblyCache or make sure it is copied to the Web Apps BIN folder.

Azure Support:

Since RIA Services RC bits only support .NET 4 while Azure currently only support .NET 3.5, it is not possible to deploy a RIA Services RC application to Azure

Configuring IIS

RIA Services supports IIS6/IIS7 deployments

However WCF (and by association RIA Services) has a limitation that it does not support MultipleAuthenticationSchemas enabled in IIS

So if you are using Forms Authentication in your application (if you built your application using the Business Application template, Forms Auth is the default there) you need to make sure that for the IIS VirtualRoot that hosts your WebApp Forms Auth is enabled. Forms Auth + Anonymous will also work fine but Forms Auth + Integrated Auth is not supported

Similarly if you are using Windows Authentication in your application (for a default Web Application no Authentication Mode is specified in the Web Config and the default Authentication Mode  is Windows) you need to make sure that for your WebApp only Integrated Auth enabled

If you do not have access to your servers IIS settings (most hosters will give you an option to choose the Authentication Mode for your Web Application) you will need to work with your Server Administrator to get those changed

Deploying the Application

Once you have the deployment server set up, RIA Services installed or Bin Deployed and IIS configured, deploying the application is as simple as copying the bits over

A typical Web Application hosting a Silverlight Application will look something like this:

The ClientBin folder contains the .xap, while the Bin folder contains the [WebAppName].dll + any bin copied assemblies

If you do not see the Silverlight Application being downloaded successfully when you browse to your web site, it is most likely because your ASP.NET server or  IIS have not been configured correctly. However if you can download the Silverlight Application fine but your calls to the DomainService are failing, then it is a RIA Services deployment issue.

Troubleshooting Deployment Issues

The flow chart below shows the various platform involved in data or error information successfully making it down from a DomainService to the Silverlight Client


Exceptions thrown at the DomainServices layer make it down to the Silverlight client and if unhandled show up as client exceptions

If the Web App’s web.config has Custom Errors enabled (the default is Off), then the exceptions will typically contain enough information to help the user debug the exception

<customErrors mode=”On”/>

Since the application worked fine in the development environment and is failing on deployment, the failure typically has to do with the Server environment not being setup correctly. For example, connection string mismatch between development and deployment environments is a common cause of failures


Unfortunately any exception thrown in the RIA Service Host or anywhere lower in the pipeline (WCF/ASP.NET/IIS) all show up in Silverlight as 404/NotFound.Option #1 – To get to the actual error information an Http diagnostic tool is need. Fiddler is a popular option. It gives you access to the to the Http response body where the actual error information is available.

Option #2 – Not being able to get the error information in Silverlight is a limitation of the Silverlight’s Browser Networking Stack which RIA Services uses internally.

Another option to get to the error info for debugging is to temporarily get your application to use the Silverlight Client Networking Stack. To do so, all you need to do is add the following line of code to your SL Application. It will force all http web request to go via the Client Networking Stack and thus make the error code available on the Client.

WebRequest.RegisterPrefix(“http://”,   WebRequestCreator.ClientHttp);

In case you were wondering – There are certain limitations to using Client networking stack (especially around authentication support) and hence RIA services does not use it as its default networking stack.

If using Fiddler or the Client stack you are still seeing a 404 response, then that really is the error code the server is returning. We then need to move to the next stage of troubleshooting.

Browsing to the .SVC

For every DomainService, a WCF Service is created at runtime using the ASP.NET feature of Virtual Path Providers. Since it is a virtual file you will not see a physical .svc in your deployed project, but it will exist at runtime. Being able to browse to the .SVC can be key to debugging RIA Services deployment issues

For a given DomainService the path to its .SVC can be determined using the following convention:

[BaseURI] + [DomainServiceNameWithNamespace].svc with all “.” in the DomainServiceFullName replaced by “-
So HRApp.Web.OrganizationService deployed the domain will be exposed as –

If everything is setup correctly you will see a default WCF Service page, else you will see an error message telling you what is wrong.

If you get a 404 on browsing to the .SVC, the DomainService was not setup correctly

One common cause for this issue is missing sections in the Web config.

At development time when a DomainService is added to a project using the DomainService Wizard, the right Web Config entries are automatically made by the Wizard. However these entries sometimes get lost at deployment time, especially if the Web Config has to manually be merged for deployment

Below are the Web Config sections need by RIA Services:

        <modules runAllManagedModulesForAllRequests="true">
            <add name="DomainServiceModule" preCondition="managedHandler"
System.ServiceModel.DomainServices.Hosting, Version=,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
        <validation validateIntegratedModeConfiguration="false" />
            <add name="DomainServiceModule"
System.ServiceModel.DomainServices.Hosting, Version=,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
        <compilation debug="true" targetFramework="4.0" />
        <serviceHostingEnvironment aspNetCompatibilityEnabled="true"
            multipleSiteBindingsEnabled="true" />

If browsing to the .SVC succeeds just fine but communicating with the Domain Service from within the Silverlight Application returns a 404 response code, then most likely your DomainSerivce at runtime is running into an exception in the WCF stack. In the data/error Flow diagram at the beginning of this section We represent these exceptions with the dark blue box.

WCF Exceptions

Hitting exceptions in the WCF stack is rare for RIA Services applications.

One known cause is that you might be hitting the default WCF quota for Maximum number of nodes in a de-serialized graph – ‘Maximum number of items that can be serialized or deserialized in an object graph is 65536′. If you are indeed inadvertently sending large amounts of data consider constraining it

Another cause could be that RIA Services is running into an exception trying to (de)serialize your Object Graph, though this is very uncommon

The only option to get to the bottom of these sort of issues is to enable WCF tracing in your Web Site.

Comments are closed.


Cheap Reseller Hosting

Best Blog Hosting Provider

Best European ASP.NET 4.0 Hosting Provider