The MIX build of RIA services has a bug that has been fixed since. But you might experience it as I did this morning and go around in circles for a while. This blog post is to help you avoid wasting that time.

I normally create my model is in its own project and hadn’t seen this problem until this morning.

If you add a model into a RIA Services project (e.g., the web project created from the Silverlight Business Application template), you must build the project before you create a new Domain Service Class with the wizard.

If the project wasn’t built in advance, then you will see the model, but not the entities:

What I did then was Cancel and build the project. But it was too late. The entities would not show up after this when I tried to create a new Domain Service class. The only way to get them to show at this point is to close and reopen Visual Studio.

It’s a bug and has been fixed post-Mix, but until then, remember to build after you add in the model file.

Hopefully you won’t spend as much time as I did trying to understand the problem. Thanks to Jeff Handley and Ron Cain from the RIA Services team who finally identified the problem and confirmed that it’s been eradicated.

Eager loading with Entity Framework depends on the special ObjectQuery.Include method. We’ve had that from Day 1 (first version of ef).

Now we use ObjectSets in EF4 which inherit from ObjectQuery (thereby inheriting Include) and also implement IObjectSet.

IObjectSet allows us to break the queries apart from ObjectQuery and ObjectContext so we can write persistent ignorant, testable code.

But IObjectSet doesn’t come with the Include method and you have to create an extension method to continue using it.

This is not new. Lots of people have blogged about it before including myself. Here’s a post I wrote about using Include with IObjectSets: http://thedatafarm.wpengine.com/blog/data-access/agile-entity-framework-4-repository-part-5-iobjectset/

This extension method works great when the IObjectSet is the one for your true EF query, therefore an ObjectSet which inherits from ObjectQuery and can leverage the Include.

But what happens when you are testing a method that contains an eager loaded query with Include and you are using a mock context, not the real EF ObjectContext?

The Include method will get ignored.

For example, you may have a method such as:

public List<Customer> GetCustomerWithOrders(int customerId)
{
   return context.Customer.Include(“Orders”)
                   .Where(c=>c.Id==customerId).ToList();
}

In *real* EF, “context.Customer” is an ObjectSet, but if you are using a mock context, then it’s an IObjectSet with no Include.

All you’ll get back after running through the extension method is the Customer — with no orders. But at least the method won’t crash and burn.

But what if the method does something like this:

public string BuildEmailForCustomerWithOrders(int customerId)
{
   var cust=  context.Customer.Include(“Orders”).FirstOrDefault(c=>c.Id==customerId);
   if (cust.Orders>0)
    return “Dear” + cust.Name + “, Thanks for your order”
   else
    return “Dear” +cust.Name+ “, Screw you for not placing any orders”;
}

You might then have a test to be sure that good customers get a nice email and bad customers get the nasty email.

With the mocks, you can’t test that because Orders will always be 0.

Here’s an easy solution….just create a special mock context that is used anywhere you need to test methods that contain Includes.

And instead of it’s Customers property returning customers, the Customers property should construct a customer with some orders in its Orders property and return that.

Long story to get to a very simple solution – which may be obvious to pro testers – but is not necessarily to us newbies.

I already have a bunch of mocks…good data mocks to test valid validations…bad data mocks to test invalid validations, etc. So creating a mock so that my methods that happen to contain Include queries can still be tested was a no-brainer (once I was confident there was no way (and really, no need) to generically emulate the Include behavior).

UPON REFLECTION, I DECIDED THAT THIS POST WAS PRETTY MISGUIDED (must have been one of those days…).

So, for safety , I have removed it completely.

You *can* use T4 to customize the code generated for EntityObjects but if you begin with the T4 EntityObject template and replace .NET 4.0 specific logic with old style. FOr example ObjectSet & CreateObjectSet needs to be replaced by ObjectQuery and CreateQuery.

When I have some time, I will update this post to show how to do it.

Two new videos that I have created for Visual Studio 2010 have just been published to Pluralsight On-Demand.

If you don’t have a Pluralsight subscription (yet), these videos are available as part of POD’s free guest pass along with lots of other great content.

The new vids are “Exploring the Classes Generated from an Entity Data Model” and “Consuming an Entity Data Model from a Separate .NET Project”.

They’ll be available on the MSDN Data Developer center as well (msdn.microsoft.com/data) in the very near future.