I recently ran into this same error again while moving my EDMX file to a new location in the solution. Apparently, there are a couple of different namespaces when dealing with EDMX files. There is the namespace you enter via the wizard when creating the initial EDMX file (N1), another that appears in the SSDL which looks something like this (N2):
<Schema Namespace="..." ..
Then there's the namespace of the generated code which may (optionally) be specified in the designer (N3), and finally there are the hidden namespaces of the resources that are compiled in to your final assembly (N4).
From what I can tell, namespace N2 is only really relevant inside the SSDL. I believe this namespace starts off as N1 - the one you initially enter in the wizard.
Similarly, namespace N3 is only relevant in the way C# namespaces usually are.
Here's the problematic part. Category N4 namespaces are a function of the directory in which your EDMX resides (relative to your project directory). You might think, So what? It turns out those namespaces are also referenced in your App.config file! Specifically, look for a part like this:
connectionString="metadata=res://*/Database.Master.csdl|...
That portion reading "Database.Master.csdl" is the name of your CSDL resource. If those resource names get out of sync, you'll receive an error like the one above, or perhaps:
The specified default EntityContainer name '[name]' could not be found in the mapping and metadata information.
The simple solution is to alter your App.config to specify the correct resource name for each part of your EF mapping (CSDL, SSDL, and MSL). If you're not sure exactly what those names are, check out your compiled assembly's resources in ILSpy or dotPeek.
Ok, i guess i've got it. I reduced the second model (the one that brakes the project) to the following:
Class1.cs
using System.Data.Objects.DataClasses;
[assembly: EdmSchemaAttribute()]
Bang! The well known exception appears.
As in so many cases, reading the documentation helps:
Mapping POCO entities is not supported if any mapping attributes are applied to custom data classes, including EdmSchemaAttribute at the assembly level.
Sure, i do not literally add mapping attributes to CUSTOM data classes but that doesn't matter for the EdmSchemaAttribute since that one lives on the assembly level.
Adding the second non-POCO model causes code generation resulting in a class that contains (at least) the EdmSchemaAttribute and that is not supported.
What i've learned: Don't mix POCO and non-POCO models in one assembly.
Best Answer
For anyone else dealing with the error, I think it's worth mentioning some scenarios that I've found that cause this (extremely unhelpful) error:
There might be other causes as well.
HTH