Deploying Application built using RIA Services RC
Update :: The official WCF RIA Services troubleshooting guide can now be found here.
Original Post::
Today at MIX ‘10 we announced the public availability of WCF RIA Services RC bits.
A few months back, at PDC ‘09 when we released our Beta bits we received strong feedback around making deployment of RIA Services applications easier and asking for more guidance around deployment scenarios.
With our latest RC bits we believe that we now do have an intuitive deployment story and I cover it in some depth in the blog post below.
In this blog I talk about Deployment Scenarios for RIA Services RC bits that only support Dev 10/.NET 4/SL 4.
I do realize a set of folks are still consuming RIA Services Beta bits that only support VS 2008/.NET 3.5/SL 3, primarily because those are ‘Go Live’ bits. For those folks I will be posting a separate blog soon focusing primarily on deployment using the Beta bits.
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.
Shared Hosters:
We have worked with our partner hosters and have the following hosters supporting both .NET 4 RC and RIA Services RC today …
NOTE - ASPHostCentral has a set of some blog posts here [1, 2, 3] to help you with you RIA Services Deployment as well.
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.
We are working closely with the Azure team to bring .NET 4 support 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.
I talk later about detecting whether IIS is configured correctly for your Web application.
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 everything is in place, browsing to the .aspx should download and launch the Silverlight Application.
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. In this blog I do not dwell on debugging Silverlight deployment issues, there is lot of good material available on that online.
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. Below I talk in more detail about trouble shooting such failures …
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.
CustomErrors:
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.
404/NotFound:
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("https://",
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. More details on the dynamic .SVC file creation can be found in my blog post here.
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 https://www.RIAServicesApps.com will be exposed as – https://www.RIAServicesApps.com/HRApp-Web-OrganizationService.svc
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 -
<configuration>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="DomainServiceModule" preCondition="managedHandler"
type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</modules>
<validation validateIntegratedModeConfiguration="false" />
</system.webServer>
<system.web>
<httpModules>
<add name="DomainServiceModule"
type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</httpModules>
<compilation debug="true" targetFramework="4.0" />
</system.web>
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"
multipleSiteBindingsEnabled="true" />
</system.serviceModel>
</configuration>
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 I 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.
In Conclusion
Hopefully the deployment and troubleshooting information above will help you successfully deploy your RIA Services Application. Please do you the comments section to provide feedback or for items not addressed by this blog post.