WCF RIA Services EF 4.1 Scaffolding Support, WCF RIA Services Contrib, and NuGet

Two big announcements today. First, the old RiaServicesContrib.dll file has been replaced with RiaServicesContrib.EntityTools.dll and is now available as a NuGet package. The package name is RiaServicesContrib.EntityTools. Hope that is easy to remember.

The other news is that RIA Services Contrib has a new scaffolding system for EF 4.1.

Soon after WCF RIA Services support for EF 4.1 was released, Rudi Larno released a scaffolding system for building the DomainServices based on the EF model. Unfortunatly, Rudi doesn't have time to maintain what he built so I am taking it over for him. Today I added the scaffolding code to the RIA Services Contrib project on Codeplex and published it on NuGet.

The scaffold is not exactly the same as what Rudi was using. When you create a DomainService using the scaffold you may need to add a new using statement with the namespace where your POCO entities are. Also, I modified what is generated to match the snippet code supplied by Microsoft.

To install the scaffolder

1) In the Package Manager Console select the package that will contain the DomainService
2) Type Install-Package RIAServicesContrib.EntityFramework.Scaffolding and push enter

To use the scaffolding system, in the PackageManagerConsole type in the following command line:

Scaffold RiaContribEfDomainService <TEntity> <TDbContext> <TDomainService>

So, if you are adding the Customer entity from the OrderEntities DbContext and you are creating the OrderDomainService you would type

Scaffold RiaContribEfDomainService Customer OrderEntities OrderDomainService




WCF RIA Services support for EF 4.1 and Snippets

WCF RIA Services now has support for EF 4.1. Varun Puranik and Jeff Handley have details on their blogs about how to use it.

One of the really interesting things Varun provides is a snippet to help setup the DbDomainService since the Wizard will not be available until SP2 is released. After using the snippet I am not sure what we all did without it.

To help make it even better, I have made my own modifications and, since Varun released the original under MS-PL, I am adding the snippets to RIA Services Contrib. For now they are available at the bottom of this post.

I actually have six different snippets for both VB and CS covering both DbDomainService and LinqToEntitiesDomainService.

The six snippets are:

  • dbcrud : Code snippet for DbDomainService CRUD Methods
  • dbcrudt : Code snippet for DbDomainService CRUD Methods With Timestamp
  • dbnu : Code snippet for a DbDomainService Named Update Method
  • ltecrud : Code snippet for LinqToEntitiesDomainService CRUD Methods
  • ltecrudt : Code snippet for LinqToEntitiesDomainService CRUD Methods With Timestamp
  • ltenu : Code snippet for a LinqToEntitiesDomainService Named Update Method (3.78 kb) 



MEFing up RIA Services Part 2: Kyle's Turn

Last week Kyle McClellan from the WCF RIA Services team at Microsoft posted his own version of the Book Club sample. Not wanting Kyle to be left out, I decided to MEF up his code as well.

Here is the result: (3.27 mb)

I think Kyle is doing some really interesting things with this code, but I think I prefer how John's original code used ObservableCollections (which were really EntityLists) instead of how Kyle is casting everything to IEnumerable or ICollection. What I will be creating next is my version of the Book Club which will be a mix of John's code, Kyle's code, and some completely different concepts that I am working on.


The State of the Blog: Please Welcome HTML and JQuery to the Party

Since this blog first opened in June of 2009 it has been named The Elephant and the Silverlight. The name came from John Godfrey Saxe’s The Blind Men and the Elephant. At the time, WCF RIA Services was all about Silverlight and people were arguing about just what WCF RIA Services and Silverlight were. The name made sense at the time.

However, this blog has really always been about WCF RIA Services, Silverlight was just along for the ride. Here in 2011, WCF RIA services isn’t just about Silverlight anymore. With the release of RIA/JS, HTML is joining Silverlight as a fully functional client of WCF RIA Services. While I am still primarily a Silverlight programmer, I will be expanding my coverage and my community support efforts to include the HTML platform. So, the name of this blog is changing to just The RIA Services Blog to reflect the new platform agnostic approach I will be taking around here.

So, to the HTML JQuery programmers out there, welcome to my blog. Please cut me some slack, it will take me a little while to get fully up to speed on this whole JQuery thing but I am eager to learn.

To my fellow Silverlight developers, don’t worry I am not going anywhere. I still strongly believe in Silverlight and most of my development efforts will continue to be in the Silverlight space. I think there is an opportunity with RIA/JS for us Silverlight developers to show how easy it would be to create fallback HTML versions of our Silverlight applications so that we can get the best of both worlds. Silverlight for the platforms that support it, and HTML for the platforms that don’t. With tools like RIA/JS, maybe this dual approach will not mean actually writing the application twice.


MEFing up John Papa’s MVVM code from Firestarter

Back on December 2, 2010 John Papa gifted the community with an excellent example of proper Silverlight architecture and I have been recommending people watch the video, download John’s code, and follow the pattern to create their own applications.

Over the last couple of weeks I have started a new project at work and this time I have decided to follow the example I have given to others. This experience is showing some places where my own preferences diverge from John’s so I have decided to share my changes with the community. I am taking the experiences in my own project and porting them into John’s project. I am not going to dump all of my changes in at once, I am going to be making gradual changes across at least three blog posts. In this first post I will be integrating Marlon Grech’s MEFedMVVM library into John’s code. Over the new two blog posts I will be changing the DataServices to use ICollectionView instead of EntityList and in the third post I will be changing the design time DataServices to use the actual RIA Servics entities instead of separate design time entities. Kyle McClellan on the RIA Services team at Microsoft has come up with something better then what I was working on for parts 2 and 3. Check it out at I will be posting up a MEFed up version of Kyle's project.

MEFing up the code

Out with the old

I am going to be gutting John’s provider and locator code to replace them with MEFedMVVM replacements. This means that I first deleted the following classes:

  • Assets\ObjectResourceDictionary
  • DesignServices\DesignServiceConductor
  • Services\ServiceProvider
  • Services\ServiceProviderBase
  • ViewModels\ViewModelLocator

Then I removed the following line from the App.xaml

<ResourceDictionary Source="Assets/ObjectResourceDictionary.xaml"/>

MEFing up the views

Now I was ready to put MEFedMVVM into place. First I coped MEFedMVVM.SL.dll into the Lib directory of the project and added a reference. Then I needed to add MEF itself which is done by referencing System.ComponentModel.Composition

Next, BookView.xaml, CheckoutView.xaml, and EditBookWindow.xaml need the meffed namespace registered:



Then in BookView.xaml and EditBookWindow.xaml John’s original locator code was replaced with:


In CheckoutView.xaml the locator code was replaced with:


The use of SharedViewModel and NonSharedViewModel mirrors the original design that John used. BookView.xaml and EditBookWindow.xaml will share the same instance of the ViewModel while CheckOutView.xaml will get a new instance of its ViewModel every time it loads.

MEFing up the ViewModels

I registered the BookViewModel with MEF using the MEFedMVVM ExportViewModel attribute

    public class BookViewModel : ViewModel

then I decorated the constructor:

public BookViewModel(IPageConductor pageConductor,IBookDataService bookDataService)

CheckoutViewModel was edited the same way:

public class BookViewModel : ViewModel
public CheckoutViewModel(IPageConductor pageConductor,IBookDataService bookDataService)

MEFing up the DataServices and PageConductors

Last step was registering the DataServices and PageConductors. These were registered with MEF using MEFedMVVM’s RegisterService attribute which allows us to set a ServiceType of Runtime, DesignTime, or Both. By registering the DesignBookDataService and the DesignPageConductor as having a ServiceType of DesignTime we will get the same design time data support that John had in the original version.

[ExportService(ServiceType.DesignTime, typeof(IBookDataService))]
public class DesignBookDataService : IBookDataService
[ExportService(ServiceType.DesignTime, typeof(IPageConductor))]
public class DesignPageConductor : IPageConductor
[ExportService(ServiceType.Runtime, typeof(IBookDataService))]
public class BookDataService : IBookDataService
[ExportService(ServiceType.Runtime, typeof(IPageConductor))]
public class PageConductor : IPageConductor



I think the MEFedMVVM way of doing things is both simpler and more powerful than John’s original method. It greatly reduces the amount of classes needed and makes it much easier to add new Views, ViewModels, and DataServices to your solution. Here is the ZIP file containing the modified solution: (6.56 mb)


How to Project in WCF RIA Services While Staying IQueryable

Updated 2/4/2011 - The blog code showed a technique using the IncludeAttribute that turned out not to work. A new technique is now shown.

A common question on the forums has been how to use project into POCO objects which are derived from one or more server side entity objects while still being able to query client side against the fields that are not being projected. These discussions usually start with people trying to use the Invoke to load data or discovering that the Query methods do not allow complex objects to be passed in. I have come up with a solution that makes the projected POCO completely IQueryable without having to play games with the Invoke passing parameters to the Query method as XML.

First, I am going to start with the database and Model from John Papa’s MVVM example at Firestarter. We have three entities that look like this:

For performance reasons, we want to create a new POCO object named MemberCheckout which is a projection of these three tables. MemberCheckout has to be a strongly typed object as WCF RIA Services does not support anonymous typed.

public class MemberCheckout
    public int CheckoutID { get; set; }
    public string MemberName { get; set; }
    public DateTime CheckoutDate { get; set; }
    public string Title { get; set; }

We would then add a new Query to the DomainService to load MemberCheckout (the Dummy method will be explained later):

public IQueryable<MemberCheckout> GetMemberCheckouts()
    var query = from checkout in ObjectContext.Checkouts
                orderby checkout.CheckoutDate descending
                select (new MemberCheckout()  
                    CheckoutID = checkout.CheckoutID, 
                    Checkout = checkout, 
                    MemberName = checkout.Member.MemberName,
                    CheckoutDate = checkout.CheckoutDate, 
                    Title = checkout.Book.Title
    return query;
public IQueryable<Checkout> GetCheckoutsDummy()
    throw new NotSupportedException("Dummy loads cannot be called.")

The question is, how do we filter MemberCheckout on a value that is not in MemberCheckout itself? For example, what if I want to to query for MemberCheckout objects where a book was published on a particular day. The answer is, if we associate our MemberCheckout object back to the entities that it was projected from then we will be able to query against them. First, we need to modify the MemberCheckout POCO to have a link to the original model.
The original POCO already has the CheckoutID field as it was a natural key for the derived POCO. If the POCO does not already have a key that exists in the original model then you will need to add one. The new MemberCheckout will look like this:

public class MemberCheckout
    public int CheckoutID { get; set; }
    [Association("MemberCheckout_Checkout", "CheckoutID", "CheckoutID")]
    public Checkout Checkout { get; set; }
    public string MemberName { get; set; }
    public DateTime CheckoutDate { get; set; }
    public string Title { get; set; }

Notice that the only real change was the addition of the Checkout field and an AssociationAttribute. I usually recommend having an Association set on both sides of an association but that recommendation does not apply in this case.

Next is the tricky part, we also need to make sure that the related tables that we want to query have been generated client side. If the DomainService you are using already has query methods for the related tables you want to query against then nothing more should need to be done and you will not need the GetCheckoutsDummy method. However, if you do not have query methods for the related tables then you will need to add dummy ones that do not actually work but will cause the entitiy to be generated client side. In the original version of this blog I included an alternate method using an Include. That does not work and the POCO object should not have an Include on the association attribute unless you want the associated object to be sent to the client. If the entity loaded through the Dummy method has IncludeAttributes on associations that reach the other entities that you want to query against then only the single Dummy query will be needed. Otherwise, you will need multiple dummies. With all of that setup complete, we can now write queries client side that query against the full model. For example, I executed this load client side:

var qry = from m in Context.GetMemberCheckoutsQuery()
                      where m.Checkout.Book.PublishDate == new DateTime(2009, 2, 3)
                      select m;
Context.Load(qry, false).Completed += new EventHandler(TestLoad_Completed);

The result was a single entity and when I checked what was actually executing on the SQL Server I found that the query had correctly flowed all of the way back to the SQL Server.


Recording of WCF RIA Services Campfire

The recording of the WCF RIA Services Campfire is now available for download here. I suggest right clicking the link and doing a save as.

Thanks again to everyone who participated, and to my friends at Radical Thinking who are hosting the download.


After Silverlight Firestarter: WCF RIA Services Campfire

The Silverlight Firestarter is coming up on December 2nd and I have decided to create a new online event, the WCF RIA Services Campfire. The Campfire event will be on December 3rd at 10:00 CST (16:00 GMT).

What is the WCF RIA Services Campire? No slides, no planned demos, just an open forum to talk about WCF RIA Services. To allow this event to be worldwide, I am hosting it through Office Live Meeting. If you are unable to connect to Office Live Meeting's audio features, please let me know what alternate method you want to use. I can probably support adding people through other methods including Skype.

The best thing about events like MIX, Firestarter, and PDC is always the common room where conversations happen. With the campfire event, I am going to try and bring that experience to everyone even if we can't all get together in person.

You can register for the WCF RIA Services Campfire event at


The Future of Silverlight

There are a lot of questions being asked about where Silveright is going, and what is it for. Microsoft has been giving pretty straight answers on the future of Silverlight but there has been a lack of quality reporting on those answers. For example, when Steve Ballmer was recently asked about HTML 5 and Silverlight his answer was that Silverlight started off as a cross-browser, cross-technology [for making websites] but that it has been repurposed as a [cross-browser, cross-technology] platform for creating client applications. This was transformed by Network World into Ballmer saying that he "sees Silverlight as useful for adding multimedia to client apps" and they also put a description on the article saying that Ballmer was commenting on the "near death of Silverlight." It is no wonder that people are confused, perfectly good and straighforward answers are being transformed into meaningless FUD by the media.

With Ballmer's actual response (which you can see at the link above), the Gu's recent video with John Papa, and the Silverlight's teams on Future of Silverlight blog post, I think the answers from Microsoft have been very clear on where Silverlight is going. However, I know there is still some confusion and people want a simple answer. So, I am going to try and condense this down to a simple graphic:


By traditional application I mean line of business applications and other applications that in the past would have written using Windows Forms or WPF. I know some of my WPF friends will take exception to this, but WPF is simply not positioned to expand from the Windows PC onto other platforms where applications are needed.

By "Universal Web Applications" I mean web sites that are supposed to reach as large of an audience as possible. This covers the vast majority of the web and includes everything from shopping sites ( to corporate sites (

With the last category, Advanced Web Pages and Multimedia, I am covering sites that are giving up universal reach for supporting features and capabilitites that plain HTML5 simply can't offer. Here we cover NBC's Olympic coverage, NBC's NFL Football coverage, Netflix, and anything else where just the ability to display video is not enough. I hope that we will see more tooling from Microsoft in the future to make it easier to these types of web application to a plain HTML 5 experience for platforms that do not have a Silverlight client.

 Finally, let me close this out with some of my own commentary on the subject of Flash and Silverlight vs HTML 5. I think that it is important that Silverlight and Flash continue to break new ground. HTML 5 is currently adding features that Flash (and more recently Silverlight) pioneered. I think you can make a very persuasive argument that HTML 5 only exists because Flash was there first. Who knows what new abilities will be in HTML 6 that will be pioneered in current and future versions of Flash and Silverlight? The experience with the Java has taught us that innovation will not be allowed inside the standards process, at least not by Microsoft. It is better that Microsoft and Adobe have their own sandboxes outside of the "open standards" where that innovation can occur.

Month List