David DeWinter and I have come across a few new and annoying bugs since we installed the Visual Studio Service Pack 1 beta yesterday. The first and most annoying is detailed in a forum post in the MSDN Entity Framework forum. The Error List window now lists fake errors for all of our subtypes that are children of abstract entities with a message similar to “Entity types B, C, D are mapped to table A without discriminating conditions on all mappings to the table.” The project still builds and the errors can be ignored.
Another bug we found today relates to result column bindings for mapped sprocs on subtypes. We have the results from Insert sprocs mapped to properties on the entity, such the as the Id. These bindings don’t show up at all in the Mapping Details window, even though they exist in the MSL in the .edmx file. At first I thought the mapping wasn’t there, and tried to add one. After deselecting that entity and reselecting it the Mapping Details window showed no result column bindings. I opened the file in the XML editor and looked at the mapping for that insert sproc. There were several duplicate result column bindings there from my attempts to add it with the designer. We’ve reported this bug at Microsoft Connect.
The last problem we ran into is not actually a bug, but a change in behavior. Dave created a thread about it at the Entity Framework forum. We had created the following extension method relying on the EntityKey of an EntityReference:
/// Loads the specified <see cref=”EntityReference”/> if it is not loaded
/// and only if there is an actual reference to load.
/// <param name=”entityReference”>The entity reference </param>
public static void LoadIfNeeded(this EntityReference entityReference)
// The EntityKey will be null if there is no reference.
if (!entityReference.IsLoaded && entityReference.EntityKey != null)
We had a situation where an entity shares a 0..1 relationship with another entity. Calling Load() when that relationship was null caused an unnecessary database hit, which was exaggerated when called in a loop on several entities. We’ve since been able to remove the need for a LoadIfNeeded() method, but it is still nice to have an EntityKey on references for other uses.
We’ll likely run into a few more caveats with the new beta, but the fixes to previous bugs are always welcome. Hopefully it won’t be too long of a wait before another release. One thing that surprised me was how long it took to install the service pack, much longer than the install of the .NET Framework 3.5 SP1 beta.