We are currently developing an LOB application and one of the screens in Silverlight shows about 20,000 records. When the (Silverlight) client made the domain service call it got back no data. This was because the database calls took a long time and returned many records. This led to problems with RIA services on 2 levels viz. timeouts (the time the call takes to return) and the number of objects returned.
To resolve this, I did the following:

Setting the timeout

To work around the default timeout of 30 secs for RIA services, we need to over-ride the the timeout of the binding for the endpoint at run-time.
This is a simple concept but tricky to implement. The idea is to create a partial class that will complement the DomainContext class auto-generated for the Silverlight client.

To get a handle on this, open the auto-generated file by RIA services during compilation, named [your project].g.cs in a hidden Generate Code folder. To view this, click the Project for your Silverlight client as specified in the RIA services link.

image

Click on the “Show All files” button icon in VS2010 and you will see it.

This file will contain the proxy Domain Context class generated for calling your Domain Service, amongst many other namespaces and classes in that file. Ensure you have the right namespace for this class (it could be confusing) which is essentially the namespace of your Domain Service.

Create a partial class for this Context.
Make a new file and add code similar to the following to it
(replace myns and MyDomainContext with yours, and the required timeout value which I have as 5 minutes)

namespace myns
{
    public sealed partial class MyDomainContext
    {
        partial void OnCreated()
        {
            if (!DesignerProperties.IsInDesignTool)
            {
                ((WebDomainClient<MyDomainContext.IMyDomainServiceContract>)this.DomainClient)
                    .ChannelFactory.Endpoint.Binding.SendTimeout = new TimeSpan(0, 5, 0);
            }
        }
    }
}

 

Add a reference to the web client of Domain Services

image

If the class you added does not compile, check the namespace and the Interface name (from the hidden file for that domain context constructor) and the reference.

Changing the number of objects returned

RIA Services limits the number of objects that can be returned, and this limit can be over-ridden by modifying the service behavior (not the client). This is done by modifying the web.config file to first specify a behavior node

The existence of the behavior node is specified in the services section

<services>
  <service name="myNS.myDomainService" behaviorConfiguration="myDomainService" />
</services>
The actual behavior node is specified in the behaviors node in the system.serviceModel section. Minimize the number of objects returned to suit your needs
<behaviors>
<serviceBehaviors>    
<behavior name="myDomainService">
  <serviceMetadata httpGetEnabled="true" />
    <serviceDebug includeExceptionDetailInFaults="true" />
     <dataContractSerializer maxItemsInObjectGraph="2147483647"/>
</behavior>
</serviceBehaviors>
</behaviors>
The above changes should hopefully work for you as well.

I had a problem creating a Silverlight 4 or a WCF RIA Services project in VS 2010, and  tried all possible installs and uninstalls but to no avail. I realized one needs to wait till April 15 for the official release of Silverlight 4, when all the tools will be updated.

So, in case you have a problem with opening or creating projects in Silverlight 4, don’t get frustrated trying to make things work; just wait till the official release, a few days from today.

This applies to WCF RIA Services as well as Silverlight tools.

I have a creaky old Win 2003 Server dev box that I wanted to deploy my RIA solution to. I could not do a build and publish on the box itself because I did not want to install the RIA services, etc. on there.

So I did a publish on my local environment, which produced a folder with the required aspx files and a bin folder with all the RIA Dlls (include data annotations and domain services) and a ClientBin folder for the Silverlight XAP client payload.

I copied the folder as-is to my web server and created a virtual folder and an Application (in IIS) for it.

But when I browsed to it, I got an error in my browser stating:
Message: Unhandled Error in Silverlight Application
Code: 2104   
Category: InitializeError      
Message: Could not download the Silverlight application. Check web server settings    

This is slightly misleading since you might think there is something wrong with your application, but in fact it happens because the web server is not serving the required payload properly. It is because your web server may not have the required MIME types for Silverlight configured.
To fix this problem, right-click on your application, and click the MIME types button in the HTTP-headers tab.
Add the following:
.xaml    application/xaml+xml
.xap    application/x-silverlight-app
.xbap    application/x-ms-xbap

Now, the web server should be able to serve all the required files for the Silverlight client to run.

I was merrily chugging along developing my app with RIA Services, and I started getting AG_E_PARSER_BAD_PROPERTY_VALUE errors. The error seemed like a XAML error and stated Bad Property Error and the line and column where it occurred. But it was the line where the DomainContext was specified, like so:

<riaControls:DomainDataSource.DomainContext>
    <App:fooDomainContext/>
</riaControls:DomainDataSource.DomainContext>

The error was being raised when the Domain Data Source was initializing, but it was cryptic and just had the line and column number.
To get better error details, move the Declarative XAML (above) to the code-behind, so it is like:

fooDomainContext dc = new fooDomainContext();
this.dds.DomainContext = dc;

Now, if there was a problem with Domain Context, you will get a more meaningful error message.

Another tip: If you get an error because an unknown method was being called on the Domain Context, remember the proxy code is auto-generated and the name of the query methods are created by convention, and so a method in your web service Domain Context getFoo() will be named getFooQuery() in the client code. 
If you cannot figure out what the name is, go to the Silverlight client project and click on “Show all Files” This will show hidden auto-generated files and the Domain Context proxy would be under the hidden folder “Generated Code” – foo.Web.g.cs, where foo.Web is your Web Service project. Open the hidden file, located the Domain Context class and see what methods it provides. Hopefully, you can locate the query method name.

Hope that helps…

Microsoft Silverlight and Adobe Flex are currently the 2 good options to make a rich client-web sevices app.

If you’re a .NET shop like us, you most likely have your web-services in C#. If you have a rich-client, it is most likely built in Flex/Flash. This is most likely market/business driven but also Flex has a decent model for building rich Internet clients consuming web-services and is platform independent (we’re not considering phones in this because Flex/Flash is no workie on many of them yet).

Although, Silverlight might take a while to reach a tipping point in the marketplace, the medium itself and related technologies have matured a lot and are quite compelling as a development platform, and would be my personal choice.
Silverlight definitely has the edge over Flex in terms of development, because it integrates tightly with the .NET IDE so you  have just one development platform and language which itself is a big win from a HR and team standpoint.

For development purposes, Microsoft has provided a framework called RIA (Rich Internet Application) Services that makes it easier to write a Silverlight Client that integrates with your web service.
I highly prefer the type integration it provides through library references instead of wsdl, which you would if developing with Flex.
Reflecting changes in web services (during development) seems to be a hassle with Flex Builder, if you regenerate from the wsdl and only need to copy over the new stuff if you want to do it selectively; I think a part of this hassle is our process/implementation.
A big hole in the strong typing via the proxy is that the proxy itself could be out of sync with the service, which does happen often during the development phase, and lead to runtime errors.

Apart from types being shared between the client and the server code, things like Validation rules are also shared, which is quite powerful.

This makes it a no-brainer to use Silverlight for Management Console/Support apps (because they are in-house and under your control) if you really want to go rich-client, while it might take some convincing of the business to use it for web apps, which honestly might be impossible as of now. 

Anyway, sticking to development, here is a quick overview of the various pieces involved in a RIA Services solution.

Project
You use the Project – New – Silverlight Application template (like you always have for Silverlight projects). Following this, you will see the New Silverlight Application dialog.
It is important to check the box “Enable .NET RIA Services” at the bottom of the screen (which will show up only if you have RIA Services installed)
So, you will end up with a Solution containing 2 projects, viz. the Silverlight client with the RIA link enabled and the Website Server project.

Data model
Define your data classes with the ADO Entity Framework designer

Service
This is the critical part, where you choose: Web Project – Add New Item – Domain Service class. Enter required details, which also let you choose Entities to manipulate, and you will end up with a class inheriting from the LinqToEntitiesDomainService of your Data Context class type.
The service class is decorated with: [EnableClientAccess()]  which exposes it to the client.
A Getxxx() method is generated to provide data.
Application logic should be added in/below the service class.

You can run the Project and see that the data entities are available in the client and server. This is an important distinction from writing a Flex client where there is no type sharing, and is a huge benefit for development.
This should not be confused with “no strong typing” – strong typing in Flex will be with proxy classes generated from the WSDL obtained by referencing your web service.

Client
As mentioned earlier, type sharing is achieved by generating proxy classes in hidden code when you build the Project. The proxy classes include your DataContext, Entities, etc.
You can then access data from the Service by using a generic LoadOperation class which is in the System.Windows.Ria.Data namespace.

I have purposely kept this post at a high-level to get you started. There are a lot of details which I will delve into in future posts.

Some good resources are:
http://www.nikhilk.net/NET-RIA-Services-Vision-Architecture.aspx

http://blogs.msdn.com/brada/archive/2009/03/19/what-is-net-ria-services.aspx

http://www.silverlightshow.net/items/Creating-applications-with-.NET-RIA-Service-Part-1-Introduction.aspx