If like me, you have a “can’t live with it, can’t live without it” relationship with Crystal Reports and have made a significant investment in reporting with their tools, you might be digging around the VS2010 RC looking for Crystal.

CR has been embedded into Visual Basic and Visual Studio for many versions. My experience goes back as far as Visual Basic 4, but in fact it started in 1993 with VB 2!

But it’s not in VS2010 RC. Well, kinda not in there.

Crystal Report is included in the project item templates:

But when you select it, something odd happens. Rather than a designer, you will get this window:

So it’s still available as a free extension to VS, just not built in. It’s odd that Crystal isn’t listed in the Extensions gallery that you can access through the VS2010 Extension Manager (on the Tools menu) or online at www.visualstudiogallery.com.

There’s an extensive blog post on the SAP website about Crystal Reports for Visual Studio 2010 which also lists new features, including a WPF report viewer.

I haven’t tried any of them out yet. What I’m most interested in is the design time experience with Entity Framework graphs. In VS2008, neither CR nor MS Reports recognizes navigation properties. A quick look at MS Reports (rdlc) in VS2010 suggests that this hasn’t changed. I’ll have to dig further at some point.

Remember… the data service is an item template, not a project template….and that it’s been renamed to WCF Data Services.

After you create a project (I usually use an empty web app to host the service), you can find the template in the Web section.

Or just use the handy search feature in the items dialog

Hooray! Turns out it was a bug ("unintended breaking change) and it’s getting fixed for RTM! 🙂 [see Connect submission and Microsoft’s response] Great catch George!

This is an edge case that I had not noticed, but was brought to my attention this morning in an email from Dave Russell who pointed me to this forum thread: EF4 Include method returns different results than EF1 Include

I had to test it myself because that’s the way I am.

Here is a model with the same set up : a many-to-many relationship between Person & Brewery defined using a join entity (FavoriteBrewery) and Brewery has a one-to-many relationship with Beer.

Putting a Stake in the Ground with .NET 3.5

This is the .NET 3.5 version of the model with no foreign keys.

If I query for all people

var list = context.People.ToList();

I get back 137 people.

If I query for all people who have any FavoriteBreweries:

list = context.People.Where(p => p.FavoriteBreweries.Any()).ToList();

I see there are only 3 people who have favorite breweries

Now let’s start eager loading.

list = context.People.Include("FavoriteBreweries").ToList();

This gives me all 137 people, with those favorite breweries attached to 3 of the people. (I checked by querying the ObjectStateManager for entries that are FavoriteBrewery types.)

Next, I eager load the Brewery objects along with those FavoriteBrewery join entities.

list = context.People.Include("FavoriteBreweries.Brewery").ToList();

I still  have 3 FavoriteBreweries join entities. (There are only two breweries in my sample database.)

Person 1 — FB — Brewery1

Person 2 — FB — Brewery2

Person 5 — FB — Brewery1

Now I ask for the beers that are made by the breweries

list = context.People.Include("FavoriteBreweries.Brewery.Beers").ToList();

In the lame little sample database, Brewery1 has 2 beers and Brewery2 has 0 beers.

I still get the same # of Favorite Breweries

Person 1 — FB — Brewery1 …Beer Count=2

Person 2 — FB — Brewery2 …Beer Count =0

Person 5 — FB — Brewery1 … Beer Count=2

Testing the same loading in .NET 4

In .NET 4, there has been a LOT of work done on the query generation. .NET 3.5 used a LOT of outer joins which was really messy. Much of this has been replaced with inner joins. But the outer join allowed the previous query to bring back the Favorite Breweries and Breweries even when the Breweries had no beers.

Using  a new version of the model that now includes foreign keys:

And running the same tests in .NET 4.0 where I”m getting the benefit of the new query processing, the query results change.

It is only when I eager load beers (where I know I have an empty collection for one of the breweries).

Here are the results:

Person 1 — FB — Brewery1 …Beer Count=2

Person 5 — FB — Brewery1 … Beer Count=2

The inner join prevented the database from discovering Brewery2.

I tested the same type of eager loading but this time using a many to many that does not include a join entity.

The results for an eager load that grabbed People.Include(“StoreLocations.Registers”) did not pick up the Stores with no registers.

This is definitely different than what we have learned to expect from querying. I would only expect the stores to be filtered out if I had explicitly added logic into my query to only retrieve stores with registers.

It’s a breaking change that, because it’s an edge case, I don’t expect to be modified by RC so you need to be aware of it.

I’ll probably just point to this blog post from my book rather than walking through the whole thing again.

Thanks Dave for pointing out the forum and to George Fitch who started the forum thread: “good catch!”.

Thanks to Danny Simmons‘ comment below clarifying that the provides that support EF3.5 will still work for EF4 "just without new provider affecting features like model first."

As far as I can tell, and confirmed by Fabio Pandolfo (@fabiopand on twitter) who is also on the hunt, DevArt’s Oracle provider might be the only 3rd party provider that is currently somewhat supporting EF4, though they are publically claiming Beta 2 support, not VS2010RC.  If you read this thread on their forums, you’ll see why I qualify that with “somewhat”.

If you have any clues about the status of other EF providers and their support for EF4, leave a comment here.

When Entity Framework finally brought in support for Lazy Loading, there were still complaints. The lazy loading in EF4 is context based, not property based as defined by some of the other ORMs. (I’m not sure which ones or how many.)

I was thinking about this today and realized that EF does, in fact, support property level lazy loading.

There are three essential types of entities in EF4 –

1. EntityObjects
2. POCOs that lean on dynamic proxies at runtime
3. POCOs that depend on EF’s snapshot notification

The POCOs that use dynamic proxies can do so only when every single property is marked virtual. Then they benefit from the same notification behavior at runtime as do EntityObjects and they benefit from lazy loading.

Simple POCOs that do not use dynamic proxies can still benefit from lazy loading. As long as the relationship property is marked virtual and additionally, properties that point to collections have to be a collection type that implements ICollection, the property will be loaded on demand (when the context’s lazy loading is enabled).

In this last case (the simple POCOs), you can pick and choose which of the relationship properties are able to lazy load. Then with the context set to LazyLoadingEnabled=true, lazy loading will occur, but only for the properties you have specified.

Now, I’m not sure how this compares to those other ORMs whose users criticized the context-level lazy loading, but it feels like it might be a lot closer then they realized. And I’m absolutely interested in finding out if I’m on the right track or completely off base (in which case I can only ask: “be gentle” 🙂 ).

In the process of updating my book, I have to recheck every statement and every line of code. A lot has changed. It’s as though I were writing the whole thing from scratch.

Here’s a small but notable change that I found.

In .NET 3.5 you cannot Load an EntityReference for an Added entity even when the entity has the critical piece of information — the EntityReference.EntityKey of the item to be loaded. It will fail with an exception.

In .NET 4, it works. You can set the foreign key property or the EntityReference.EntityKey and then load that related entity either explicitly or via lazy loading.

I’m pretty sure this is a result of the improvements made to the query generation. .NET 3.5 had a convoluted way of loading entity reference data. Now it’s more straightforward. However, I have only tested it with FKs.