Updated 2/16/2009: This issue was fixed before 3.5sp1 was released. So you should not have this problem if you are using the RTM bits. If you are seeing an exception when using an EF model with embedded resources in a unit test, then your problem might be that you are using the default constructor for the context which expects to find the connection string in app.config but your unit test project is looking in a different place for the app.config than your main program. Make sure that you either pass the connection string to the context constructor explicitly or that you copy your connection string to all the relevant app.config/web.config locations.
Apparently somebody out there took a look at my last blog posting and tried creating something with the EF that has its metadata embedded in resources. Unfortunately they discovered an unpleasantness which pops up when you try this with VS’s unit testing because of a collision between using unmanaged code to orchestrate the process (which VS does for its unit tests) and the way we automatically search for metadata resources when you use the simple “res://*/” mechanism described in my last post.
You can see the full discussion in the forum thread on this topic. The symptom which signals this problem is an exception which looks like this:
System.ArgumentException: The default entity container name ‘CommonEntities’ is not valid. The required mapping and metadata information could not be found.
Parameter name: defaultContainerName.
The work around for now is to explicitly list the separate metadata files with fully-qualified-assembly names and resource identifiers. Sadly, that means you have to change the metadata portion of your connection string from “res://*/” to something like “res://ClassLibrary1, Version=22.214.171.124, Culture=neutral, PublicKeyToken=null/ClassLibrary1.commonentities.csdl |res://ClassLibrary1, Version=126.96.36.199, Culture=neutral, PublicKeyToken=null/ClassLibrary1.commonentities.ssdl|res://ClassLibrary1, Version=188.8.131.52, Culture=neutral, PublicKeyToken=null/ClassLibrary1.commonentities.msl”.
As Srikanth mentioned in the forum thread, unfortunately our unit tests didn’t catch this because our unit testing harness is all managed. We’re looking into ways to improve this situation–hopefully we’ll be able to find a fix for a future CTP.