Resolve ObjectContext to specific container

Oct 16, 2010 at 2:39 AM

I am trying to resolve System.Data.Objects.ObjectContext to a derived class generated by Entity Framework. I am getting generic error saying that the "The given assembly name or codebase was invalid". I have added another custom base and derived class in the same project to see if somehow the path is incorrect and that works just fine.

<type type="System.Data.Objects.ObjectContext, System.Data.Entity" mapTo="DataLibrary.MyEntitiesContainer, DataLibrary"><!-- throws error -->

+        $exception    {"The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)":null}    System.Exception {System.IO.FileLoadException}

<type type="DataLibrary.MyBaseClass, DataLibrary" mapTo="DataLibrary.MyDerivedClass, DataLibrary"> <!-- works fine -->

What is going wrong here?

MyEntitiesContainer class is auto generated context class by ADO.NET Self-Tracking Entity Generator template.

namespace DataLibrary
{
    public partial class MyEntitiesContainer : ObjectContext
    {

    }
 }

Oct 16, 2010 at 5:57 AM

Try enabling fusion logs and run the Fusion Log Viewer to see what assembly is failing to load from what directory.

 

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

Oct 16, 2010 at 6:26 PM
Edited Oct 17, 2010 at 4:00 AM

I tried that but it doesn't show anything. Do the projects need to build differently? This is being done in between a wcf project and a class library that includes EF classes. The WCF test client is being used to test this.

Oct 18, 2010 at 12:14 AM

If it doesn't show anything, it might mean that fusion log isn't enabled.  Have you checked the registry keys that needs to be modified/added which is mentioned in the first link I posted? 

 

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

Oct 18, 2010 at 9:29 PM
Edited Oct 18, 2010 at 9:46 PM

Yes, I have checked all the entries. I have narrowed it down to

type="System.Data.Objects.ObjectContext, System.Data.Entity

I noticed that in GAC the version of this is 3.5.0.0 while the reference I have added from the project has version of v4.0.30319. Could that be the reason?

The runtime configuration works just fine.

            Container.RegisterType<System.Data.Objects.ObjectContext, WcfService1.MyNWModelContainer>(new InjectionConstructor());
            MyEntities = Container.Resolve<ObjectContext>();

However, this doesn't

      <register type="System.Data.Objects.ObjectContext, System.Data.Entity" mapTo="WcfService1.MyNWModelContainer, WcfService1">
        <constructor>
        </constructor>
      </register>

Oct 18, 2010 at 10:39 PM
Here is the error log that I was able to capture using Fusion Log. It started to show some entries after I changed the log location to custom.

*** Assembly Binder Log Entry (10/18/2010 @ 2:36:33 PM) *** The operation failed. Bind result: hr = 0x80070002. The system cannot find the file specified. Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll Running under executable C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\WCFTestClient.exe --- A detailed error log follows. === Pre-bind state information === LOG: User = xxxx\yyyy
LOG: DisplayName = Microsoft.VisualStudio.Diagnostics.ServiceModelSink, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a (Fully-specified) LOG: Appbase = file:///C:/Program Files/Microsoft Visual Studio 10.0/Common7/IDE/ LOG: Initial PrivatePath = NULL LOG: Dynamic Base = NULL LOG: Cache Base = NULL LOG: AppName = WCFTestClient.exe Calling assembly : (Unknown). === LOG: Start binding of native image Microsoft.VisualStudio.Diagnostics.ServiceModelSink, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. WRN: No matching native image found.
Oct 19, 2010 at 1:22 AM

Try fully qualifying the name of the System.Data.Objects.ObjectContext type by adding the version, culture and publickeytoken attributes.  Check also the Copy Local property of that reference.  If it's set to True then it is trying to load that assembly from GAC.

You may want to post this in other forums as this doesn't seem to be a problem related to Unity.

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

Oct 19, 2010 at 2:10 AM

I have tried all combination of the type string, it makes no difference. It has to do something with Unity and its Configuration as the runtime config works while the designtime config doesn't.

The runtime configuration works just fine.

            Container.RegisterType<System.Data.Objects.ObjectContext, WcfService1.MyNWModelContainer>(new InjectionConstructor());
            MyEntities = Container.Resolve<ObjectContext>();

However, this doesn't work

      <register type="System.Data.Objects.ObjectContext, System.Data.Entity" mapTo="WcfService1.MyNWModelContainer, WcfService1">
        <constructor>
        </constructor>
      </register>

I have created a brand new VS2010 WCF application with nothing else in it except a very simple two table NW EDM. I can reproduce the same issue in that application also. Why would Unity not load "System.Data.Objects.ObjectContext, System.Data.Entity"?

Oct 19, 2010 at 3:29 AM

Unity doesn't do the assembly loading, the CLR does that.  Anyway, I was able to repro your error and fully qualifying the assembly name fixed it.

<register type="System.Data.Objects.ObjectContext, System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

By the way, .NET Framework 4's GAC is located in %windir%\Microsoft.NET\assembly.

 

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

Oct 19, 2010 at 5:42 PM

Oh, I tried that but mixed up some other code in between and since the error message is same, I did not realize that it is not the System.Data.Entity but the other one that was causing it. I wasted one full day just for this :(

Thanks so much Sarah for all the help, especially for creating the project and confirming that the fully qualified name works.