locked
The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type 'EdmMetadata' RRS feed

  • Question

  • I've created an MVC3 app that uses EF 4.1/CodeFirst, and the MVC app works fine. I've added a WCF Data Service to the web, but when I attempt to access the service I get the following error:

    The server encountered an error processing the request. The exception message is 'Schema specified is not valid. Errors: The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type 'EdmMetadata'. Previously found CLR type 'System.Data.Entity.Infrastructure.EdmMetadata', newly found CLR type 'System.Data.Entity.Infrastructure.EdmMetadata'.'. See server logs for more details. The exception stack trace is:

    at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache(ObjectItemCollection objectItemCollection, Assembly assembly, Boolean loadReferencedAssemblies, EdmItemCollection edmItemCollection, Action`1 logLoadMessage) at System.Data.Metadata.Edm.ObjectItemCollection.ExplicitLoadFromAssembly(Assembly assembly, EdmItemCollection edmItemCollection, Action`1 logLoadMessage) at System.Data.Metadata.Edm.MetadataWorkspace.ExplicitLoadFromAssembly(Assembly assembly, ObjectItemCollection collection, Action`1 logLoadMessage) at System.Data.Services.Providers.ObjectContextServiceProvider.InitializeObjectItemCollection(ObjectContext objectContext, Assembly assembly) at System.Data.Services.Providers.ObjectContextServiceProvider.PopulateMetadata(IDictionary`2 knownTypes, IDictionary`2 childTypes, IDictionary`2 entitySets) at System.Data.Services.DataService`1.CreateProvider() at System.Data.Services.DataService`1.HandleRequest() at System.Data.Services.DataService`1.ProcessRequestForMessage(Stream messageBody) at SyncInvokeProcessRequestForMessage(Object , Object[] , Object[] ) at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs) at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc) at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)

    The POCO classes do have a few levels of inheritance, implemented in 'Table Per Hierarchy' form; not sure if that's a factor...

    From searching th Object Browser, I see that EdmMetadata exists in both System.Data.Entity & EntityFramework. I'm guessing that's the source of my problem, but I'm not sure why or what to do about it.

    Any suggestions?

    Sunday, September 18, 2011 8:35 PM

Answers

  • Ok, I tried a bunch of things, including uninstalling the June CTPs, repairing .NET4, running Windows Update and installing the Sept Windows Azure SDK.

    I got a variety of errors along the way, but eventually got one that implicated a publisher policy file. I renamed C:\Windows\Microsoft.NET\assembly\GAC_MSIL\policy.4.0.system.data.entity\v4.0_0.0.0.0__b77a5c561934e089\policy.4.0.system.data.entity.config to (...).old, and it worked! Bottom line: one of the June CTPs must have put the policy file in place, redirecting System.Data.Entity v4.0 to v4.2. Uninstalling didn't clean it up.

    A little cleanup on my DataService.svc.cs, and I'm now getting data back, complete with WIF protection. Now if I could just get the WP7 client to work...

    I really appreciate your timely responses and effort on this; I'd been beating my head against a wall on this for days (well, nights).

    Tuesday, September 20, 2011 1:21 AM

All replies

  • Hmmm, I had no idea that the EdmMetadata class was ever in System.Data.Entity.dll, but they have refactored their assemblies a bit, and it does sound like you are in some kind of EF assembly no-mans-land. EntityFramework.dll should have the correct Code First bits. The latest (good) version of EF 4.1 is available from NuGet here http://nuget.org/List/Packages/EntityFramework.

    Note that I have a working EF 4.1 Code First project with WCF Data Services (from my blog post), and I only have EdmMetadata in EntityFramework.dll.

    Glenn Gailey

     


    Please visit my blog

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, September 19, 2011 9:07 AM
  • So it sounds like I've got the wrong version of System.Data.Entity.dll...(I'd paste in the version number, but it's on my PC at home; will do it tonight).

    Could you tell me what version you're using and where to get it? Isn't it just one of the dll's shipped with .Net 4?

    I did a search on MSDN and couldn't find anything indicating that EdmMetadata was ever part of System.Data.Entity.dll, so I'm not sure where my copy came from. I've installed/uninstalled a couple CTPs, updates, and stuff over the last couple months as I started playing with this stuff, so I'm not sure what I've got anymore! Maybe I should reinstall .Net 4? What can of worms would that open up?

     

    Thanks,

    Brett.

    Monday, September 19, 2011 1:11 PM
  • OK, I am now able to repro your error. Let me try to figure out what's going on.

    Did you install EF4.1 from the NuGet package?


    Please visit my blog

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, September 19, 2011 4:31 PM
  • Originally, yes. In the process of troublshooting this problem, I uninstalled the NuGet package and installed from downloads page (and if memory serves, that's where I left it last night...) so I've had the problem both ways.

    Out of curiousity, what did you have to do to repro the issue?

    Monday, September 19, 2011 5:30 PM
  • I was actually using the Data Framework (DataFx) June 2011 CTP, which also installs a version of EF 4.2. This was working for me, but of course it's pre-release stuff. When I went back to using EF 4.1 and .NETFx4, I started to get your error.

    They are also refactoring the Entity Framework in this release before RTM, as mentioned in this blog post, so I wouldn't count on EF 4.2 being shipped in the DataFx RTM.

    I've pinged some folks on the team to help figure out why we are getting this error on an RTM configuration (EF4.1 and .NETFx4).


    Please visit my blog

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, September 19, 2011 6:46 PM
  • Ahhh... at one point recently I installed the June 2011 DataFx CTP (was hoping to avoid the whole 'ObjectContext' issue)... but found I couldn't deploy it to Azure, so I went back. I don't think I actually uninstalled the CTP; just stopped using it (again, many late hours and foggy memory... I'll have to confirm).

    So I'm thinking I need to uninstall the CTP, and possibly reinstall .Net 4? Is it that simple?

    Monday, September 19, 2011 7:10 PM
  • Ok, I tried a bunch of things, including uninstalling the June CTPs, repairing .NET4, running Windows Update and installing the Sept Windows Azure SDK.

    I got a variety of errors along the way, but eventually got one that implicated a publisher policy file. I renamed C:\Windows\Microsoft.NET\assembly\GAC_MSIL\policy.4.0.system.data.entity\v4.0_0.0.0.0__b77a5c561934e089\policy.4.0.system.data.entity.config to (...).old, and it worked! Bottom line: one of the June CTPs must have put the policy file in place, redirecting System.Data.Entity v4.0 to v4.2. Uninstalling didn't clean it up.

    A little cleanup on my DataService.svc.cs, and I'm now getting data back, complete with WIF protection. Now if I could just get the WP7 client to work...

    I really appreciate your timely responses and effort on this; I'd been beating my head against a wall on this for days (well, nights).

    Tuesday, September 20, 2011 1:21 AM
  • We really appreciate your help troubleshooting this issue with the June CTP. I will communicate this information to the team so that we don't end up doing something similar in the next CTP.

    What issues are you having consuming your feed using the OData client for Windows Phone?


    Please visit my blog

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, September 20, 2011 2:31 AM
  • I can't seem to add a service reference... I know I've seen an example before that accessed a data service and attached a token; need to go searching for it again.
     
    I CAN use WebClient to pass Authorization header, like so:
     
    WebClient client = new WebClient();
    client.Headers["Authorization"] = "OAuth " + _rstrStore.SecurityToken;
    client.DownloadStringCompleted += new DownloadStringCompletedEventHandler(client_DownloadStringCompleted);
    Uri svc = new Uri("http://127.0.0.1:81/services/dataservice.svc/BaseItems");
    client.DownloadStringAsync(svc);
    The service properly handles the SimpleWebToken, filters the data, and returns a valid response; but I'm unclear how to deserialize it. And I'd really rather be able to use a proper service client. Seems I came across something recently about generation of service client not working properly on WP7... can you point me in the right direction?
     
    Tuesday, September 20, 2011 3:00 AM
  • The Add Service Reference tool will probably only work correctly when you are using the new WP SDK 7.1 tools (for WP Mango). If you are creating a WP7 app, you will need to manually generate the reference using the datasvcutil.exe tool in the OData client libraries for WP7 (which include this codegen tool). You can see how to do this in the OData quickstart for WP7.

    To set headers using the OData client library, you simple handle the DataServiceContext.SendingRequest event, and in the handler, set the headers, like this:

    void _context_SendingRequest(object sender, SendingRequestEventArgs e)
            {
                e.RequestHeaders["Authorization"] = "OAuth " + _rstrStore.SecurityToken;
            }

    If you can, I really recommend using our client (which is supported for WP7--and ships in the 7.1 SDK).


    Please visit my blog

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, September 20, 2011 3:12 AM
  • I actually was using the 7.1 SDK and targeting 7.1... The last thing I did last night was kick off a reinstall of the SDK. This morning, I added a service reference without errors and was able to see the Context class, so I'm assuming that somewhere in all of this something else got messed up. I don't necessarily believe it was directly related to the June CTPs; as I said before, I've installed and removed a lot of stuff recently. I didn't have time to add the Authorization logic or run a test, since I had to get my youngest on the bus and get to my REAL job... but I look forward to testing it tonight when I get home. I'll let you know what happens...! Thanks, Brett.
    Tuesday, September 20, 2011 12:16 PM
  • I am now able to successfully call my service, complete with authentication! Data is returned and deserialized correctly. At this point, I think we can consider my original mapping problem solved, along with my client-side issue. I'll mark the proposed answer, above...

     

    I do have another question about exposing derived classes, but I think that really should be a new thread.

    Thanks...

    Tuesday, September 20, 2011 11:20 PM