MetadataException: Unable to load the specified metadata resource

This means that the application is unable to load the EDMX. There are several things which can cause this.

• You might have changed the MetadataArtifactProcessing property of the model to Copy to Output Directory.
• The connection string could be wrong. I know you say you haven't changed it, but if you have changed other things (say, the name of an assembly), it could still be wrong.
• You might be using a post-compile task to embed the EDMX in the assembly, which is no longer working for some reason.

In short, there is not really enough detail in your question to give an accurate answer, but hopefully these ideas should get you on the right track.

Update: I've written a blog post with more complete steps for troubleshooting.

• The connectionstring, despite my efforts to compare it with a content-compare utility last time, was wrong. - J. Steen
• It was the connectionstring for me too. When you have Integration Tests that also need connectionsting in its own App.config, things may go out of sync when you update your edmx. - Ray Fan
• OK, I fixed it by simply setting "Embed"; compiling, then reseting it to the other one. That solved my problem. - Shimmy
• Had the same problem, tried your solution, wanted to give +1, realised I already did it in the past. I don't even remember having this problem before ;). This time in my case it was correct connection string in Class Library with edmx and wrong in web application when it was used. - Episodex
• Awesome guide. For me, I'd copied another connection string which used res://*/Database.MyModel2..., when I REALLY wanted res://*/MyModel1... (Database is a folder inside my Integration Tests project) - emragins

This little change help with this problem.

I have Solution with 3 project.

connectionString="metadata=res://*/Model.Project.csdl|res://*/Model.Project.ssdl|res://*/Model.Project.msl;

change to

connectionString="metadata=res://*/;

• It fixed it for me, but what the heck does it mean? - Lance Fisher
• @Lance: I explain this in detail in this blog post - Craig Stuntz
• @jocull: No, it won't work in many cases, and will be slow in others. Read my blog post to understand why. - Craig Stuntz
• Moved my .edmx to Model folder and forgot to update the connection string. Great pointer. Thanks. Would have taken me hours to figure out. - muruge
• You sir have saved a poor Microsoft employee from a very pissed off consumer. - The Muffin Man

You can get this exception when the Edmx is in one project and you are using it from another.

The reason is Res://*/ is a uri which points to resources in the CURRENT assembly. If the Edm is defined in a different assembly from the code which is using it, res://*/ is not going to work because the resource cannot be found.

Instead of specifying ‘*’, you need to provide the full name of the assembly instead (including public key token). Eg:

res://YourDataAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=abcdefabcedf/YourEdmxFileName.csdl|res://...

A better way to construct connection strings is with EntityConnectionStringBuilder:

public static string GetSqlCeConnectionString(string fileName)
{
    var csBuilder = new EntityConnectionStringBuilder();

    csBuilder.Provider = "System.Data.SqlServerCe.3.5";
    csBuilder.ProviderConnectionString = string.Format("Data Source={0};", fileName);

    csBuilder.Metadata = string.Format("res://{0}/YourEdmxFileName.csdl|res://{0}/YourEdmxFileName.ssdl|res://{0}/YourEdmxFileName.msl", 
        typeof(YourObjectContextType).Assembly.FullName);

    return csBuilder.ToString();
}

public static string GetSqlConnectionString(string serverName, string databaseName)
{
    SqlConnectionStringBuilder providerCs = new SqlConnectionStringBuilder();

    providerCs.DataSource = serverName;
    providerCs.InitialCatalog = databaseName;
    providerCs.IntegratedSecurity = true;

    var csBuilder = new EntityConnectionStringBuilder();

    csBuilder.Provider = "System.Data.SqlClient";
    csBuilder.ProviderConnectionString = providerCs.ToString();

    csBuilder.Metadata = string.Format("res://{0}/YourEdmxFileName.csdl|res://{0}/YourEdmxFileName.ssdl|res://{0}/YourEdmxFileName.msl",
        typeof(YourObjectContextType).Assembly.FullName);

    return csBuilder.ToString();
}

If you still encounter the exception, open the assembly in reflector and check the filenames for your .csdl, .ssdl and .msl files. When the resources have different names to the ones specified in the metadata value, it’s not going to work.

• Please consider that "YourEdmxFileName" must be the qualified name e.g. "YourNamespace.YourEdmxFileName", if you use namespaces in your assembly. However, you must remove the part of the namespace that equals to the name of your assembly. - Marcel
• MSDN says the second paragraph is wrong. "When you use wildcard (*), the Entity Framework has to look through all the assemblies for resources with the correct name." - Craig Stuntz
• I'm pretty sure that the namespace is not relevant, but the embedded file path is. So even if you inspect the *.Designer.cs file of the associated edmx file and notice that the auto-generated class namespace is MyCompany...whatever, it's not what you should use. Instead the path is assemblyname, solution folder(s) names/file name. For example: "metadata=res://*/EntityModels.<filename>.csdl|" + "res://*/EntityModels.<filename>.ssdl|" + "res://*/EntityModels.<filename>.msl;" - Daniel
• @Daniel, that's mostly correct, but note that the namespace and the embedded file path are sometimes the same. You have to look with Reflector (or free alternative to that) to be sure. - Craig Stuntz
• it looks like it works using only the assembly name, without version, publickeytoken, etc. Like: res://MyAssembly/folder.<filename>.csdl... - Ivan Ferrer Villa

I had a similar error. I had recreated the project (long story), and pulled everything over from the old project. I hadn't realized that my model had been in a directory called 'Model' before, and was now in a directory called 'Models'. Once I changed the connection in my Web.Config from this:

<add name="RecipeManagerEntities" connectionString="metadata=res://*/Model.Recipe.csdl 

to this:

<add name="RecipeManagerEntities" connectionString="metadata=res://*/Models.Recipe.csdl

Everything worked (changed Model to Models). Note that I had to change this three places in this string.

• I moved my Entity Framework model from Model to DAL. But then when I wrote a test (a week later) in the test project to test the Linq predicatebuilder. I got this error. I corrected the test projects App.config with how it looked in the main project's web.config - as you said in three places. So your simple answere got me on track. - Patrik Lindström
• Yes thanks - check your filename(s). Somehow I had the old name. - PeterX
• Is there a difference between the two?! - Erwin Rooijakkers
• @ErwinRooijakkers Model vs ModelS - Marc
• @Marc thanks. :) - Erwin Rooijakkers

And a quick way to check the model name without Reflector.... look for the directory

...obj/{config output}/edmxResourcesToEmbed

and check that the .csdl, .msl, and .ssdl resource files are there. If they are in a sub-directory, the name of the sub-directory must be prepended to the model name.

For example, my three resource files are in a sub-directory Data, so my connection string had to be

metadata=res://*/Data.MyModel.csdl|res://*/Data.MyModel.ssdl|res://*/Data.MyModel.msl;

(versus metadata=res://*/MyModel.csdl|res://*/MyModel.ssdl|res://*/MyModel.msl;).

• This was EXACTLY my problem. Lost several hours on this. Thank you so much for this easy explanation - Fernando Carvalhosa
• Great answer, actually explains how to find what your string is. And shows that subfolders have '.' as delimiters and not '\' or '/'. - cjb110

I also had this problem and it was because the connectionstring in my web.config was slightly different than the one in the app.config of the assembly where my EDMX is located. No idea why it changed, but here are the two different versions.

App.config:

<add name="SCMSEntities" connectionString="metadata=res://*/Model.SMCSModel.csdl|res://*/Model.SMCSModel.ssdl|res://*/Model.SMCSModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=SANDIEGO\sql2008;initial catalog=SCMS;integrated security=True;multipleactiveresultsets=True;application name=EntityFramework&quot;" providerName="System.Data.EntityClient" />

Web.config:

<add name="SCMSEntities" connectionString="metadata=res://*/Model.SCMSModel.csdl|res://*/Model.SCMSModel.ssdl|res://*/Model.SCMSModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=SANDIEGO\sql2008;initial catalog=SCMS;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework&quot;" providerName="System.Data.EntityClient" />

What fixed it was simply copying the app.config string (notice the small difference at the end - instead of "App=EntityFramework" it wanted "application name=EntityFramework") into the web.config and problem was solved. :)

• Thanks, this was indeed my problem. I had 1 project that access DB with EF and another project WCF. After changing the name of the first project, the connectionString has been changed in the App.config of my first project. So i had to change the connectionString in the project WCF aswell in the web.config :) - Volkan
• From MSDN documentation about docs.microsoft.com/en-us/dotnet/framework/data/adonet/…: The .NET Framework data provider for SQL Server (SqlClient) supports many keywords from older APIs, but is generally more flexible and accepts synonyms for many of the common connection string keywords. Entity Framework connection strings do not share that flexibility, so you must use only the keywords it expects. - Suncat2000

This happened to me when I accidentally switched the Build Action of the edmx file (appears under Properties in the IDE) from 'EntityDeploy' to 'None'. EntityDeploy is what populates the metadata for you: see http://msdn.microsoft.com/en-us/library/cc982037.aspx

• This was my fix - I renamed my edmx to .old as I copied it and was trying a few things out, afterwards when I renamed it back the Build Action set it self to none and thus got this error, setting it back to EntityDeploy resolved my issue :) - eth0
• I had moved my EDMX file to another folder and had to change the build action to get the embedded resource names to be updated as well. Thanks! - David

I've just spent a happy 30 minutes with this. I'd renamed the entities object, renamed the entry in the config file, but there's more ... you have to change the reference to the csdl as well

very easy to miss - if you're renaming, make sure you get everything ....

I was able to resolve this in Visual Studio 2010, VB.net (ASP.NET) 4.0.

During the entity model wizard, you will be able to see the entity connection string. From there you can copy and paste into your connection string.

The only thing I was missing was the "App_Code." in the connections string.

entityBuilder.Metadata = "res://*/App_Code.Model.csdl|res://*/App_Code.Model.ssdl|res://*/App_Code.Model.msl"

• Unfortunately, the connecting string in wizard is not correct for app.config. @leqid suggested good way to fix path to the model. - Der_Meister

I had the same problem. I looked into my complied dll with reflector and have seen that the name of the resource was not right. I renamed and it looks fine now.

For my case, it is solved by changing the properties of edmx file.

1. Open the edmx file
2. Right click on any place of the EDMX designer
3. choose properties
4. update Property called "Metadata Artifact Processing" to "Embed in Output Assembly"

this solved the problem for me. The problem is, when the container try to find the meta data, it cant find it. so simply make it in the same assembly. this solution will not work if you have your edmx files in another assembly

• +1,000,000 this was the underlying issue for me today. Pains of reorganizing a products namespaces and consolidating assemblies. - Mike

I spent a whole day on this error

if you are working with n-tear architecture

or you tried to separate Models generated by EDMX form DataAccessLayer to DomainModelLayer

maybe you will get this error

1. First troubleshooting step is to make sure the Connection string in webconfig (UILayer)and appconfig (DataAccessLayer) are the same

2. Second which is Very important the connection string

   connectionString="metadata=res://*/Model.csdl|res://*/Model.ssdl|res://*/Model.msl;provid.....
   

   which is the problem

from where on earth I got Modelor whatever .csdl in my connection string where are they

here I our solution look at the picture

hope the help you

The ultimate solution (even after recreating the database on two other machines, as well as the EDMX and other sundries) was to not use the first edition of Entity Framework. Looking forward to evaluating it again in .NET 4.0.

After running into the same problem again and searching all over for an answer, I finally found someone who'd had the same problem. It appears that the connection string wasn't correctly generated by Visual Studio's wizard, and the link to the metadata resources was missing an important path.

v1.0 BUG?: Unable to load the specified metadata resource. Scripts != Models

Update 2013-01-16: Having transitioned to almost exclusively using EF Code First practices (even with existing databases) this problem is no longer an issue. For me, that was a viable solution to reducing the clutter from auto-generated code and configuration and increasing my own control over the product.

My issue and solution, the symptoms were the same "Unable to load the specified metadata resource" but the root cause was different. I had 2 projects in solution one was the EntityModel and the other the solution. I actually deleted and recreated the EDMX file in the EntityModel.

The solution was that I had to go back to the Web Application project and add this line into the config file. The new model had changed a few items which had to be duplicated in the "other" project's Web.Config file. The old configuration was no longer good.

     <add name="MyEntities"
     connectionString="metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;
                    provider=System.Data.SqlClient;
                    provider connection string=&quot;
                    data source=Q\DEV15;initial catalog=whatever;
                    user id=myuserid;password=mypassword;
                    multipleactiveresultsets=True;
                    application name=EntityFramework&quot;"
     providerName="System.Data.EntityClient" />

• the solution for me. thanks - Erçin Dedeoğlu

After hours of googling and trying to solve none of the solutions suggested worked. I have listed several solution here. I have also noted the one that worked for me. (I was using EF version 6.1.1, and SQL server 2014 - but an older DB)

1. Rebuilding the project and try again.
2. Close and open VS - I don't know how this works
3. make sure if you have placed the .EDMX file inside a Directory, make sure you include the Directories in your ConnectionString. for example mine is inside DAL folder. SO it looks like this: connectionString="metadata=res://*/DAL.nameModel.csdl|res://*/DAL.nameModel.ssdl|res://*/DAL.nameModel.msl;(these are files. to see them you can toggle Show All Files in solution explorer, under ~/obj/.. directory)

...and many more which I had tried [like: reverting the EntityFramework version to a later version(not sure about it)]

what worked for me:

from this article here, it helped me solve my problem. I just changed my ProviderManifestToken="2012" to ProviderManifestToken="2008" in the EDMX file. To do this:

Solution Explorer

1. Right click over file .edmx
2. Open with..
3. Editor XML
4. Change ProviderManifestToken="XXXX" with 2008

I hope that helps.

• I recently had this problem after making seemingly no changes. Tried restarting VS to no avail, but then it was fixed by cleaning and rebuilding. So, to others, if you made no changes and none of the rest of this seems relevant, then give a clean/rebuild a try. - Greg

In my case, this issue was related to renaming my model's edmx file... correcting the app.config connection string for the csdl/ssdl/msl files fixed my issue.

If you're using the EF 4.0 designer to generate your csdl/ssdl/msl, these 3 "files" will actually be stored within the model's main edmx file. In this case, the post by Waqas is pretty much on the mark. It's important to understand that "Model_Name" in his example will need to be changed to whatever the current name of your model's .edmx file (without the .edmx).

Also, if your edmx file is not at the root level of your project, you need to preface Model_Name with the relative path, e.g.

res://*/MyModel.WidgetModel.csdl|res://*/MyModel.WidgetModel.ssdl|res://*/MyModel.WidgetModel.msl

would specify the csdl/ssdl/msl xml is stored in the model file 'WidgetModel.edmx' which is stored in a folder named 'MyModel'.

I have written this helper class to create instances of ObjectContext objects when they are defined in a different project than the project using it. I parse the connection string in the config file and replace '*' by the full assembly name.

It is not perfect because it uses reflection to build the object, but it is the most generic way of doing it that I could find.

Hope it helps someone.

public static class EntityHelper<T> where T : ObjectContext
{
    public static T CreateInstance()
    {
        // get the connection string from config file
        string connectionString = ConfigurationManager.ConnectionStrings[typeof(T).Name].ConnectionString;

        // parse the connection string
        var csBuilder = new EntityConnectionStringBuilder(connectionString);

        // replace * by the full name of the containing assembly
        csBuilder.Metadata = csBuilder.Metadata.Replace(
            "res://*/",
            string.Format("res://{0}/", typeof(T).Assembly.FullName));

        // return the object
        return Activator.CreateInstance(typeof(T), csBuilder.ToString()) as T;
    }
}

For all of you SelftrackingEntities Users , if you have followed the Microsoft Walk-through and separated the Object context class into the wcf service project (by linking to the context .tt) so this answer is for you :

part of the shown answers in this post that includes code like :

... = string.Format("res://{0}/YourEdmxFileName.csdl|res://{0}/YourEdmxFileName.ssdl|res://{0}/YourEdmxFileName.msl", 
        typeof(YourObjectContextType).Assembly.FullName); 

WILL NOT WORK FOR YOU !! the reason is that YourObjectContextType.Assembly now resides in a different Assembley (inside the wcf project assembly) ,

So you should replace YourObjectContextType.Assembly.FullName with -->

ClassTypeThatResidesInEdmProject.Assembly.FullName 

have fun.

This happens to me when I do not clean solution before build new .edmx designer. So just don’t forget to clean solution before you build new .edmx designer. This helps me to skip lot more issues with this one. Bellow the navigation details provided incase you are new in visual studio.

Click->Build->Clean Solution

Then Click->Build->Rebuild Solution

Hope this helps. Thanks everyone

I was having problems with this same error message. My issue was resolved by closing and re-opening Visual Studio 2010.

Had same issue because I renamed an assembly.

I had to also rename it in AssemblyTitle and AssemblyProduct attributes in project Properties/AssemblyInfo.cs, and also deleting and re adding the reference to the edmx file.

Then it worked just fine.

With having same problem I re-created edmx from Database. Solves my problem.

• Unfortunately that addresses and treats the symptom, not the cause. - cbillowes

Exception is because compiler pointing to non existing Metadata so just Copy app.config connectionstring to Web.config ConnectionString

I also had the same problem and solution as per Rick, except that I was importing an existing .edmx to a new project, and while the base namespace didn't matter it was imported into a different subdirectory so I also had to update the connection string inside Web.Config in three places, to include the different subdirectory naming:

I had the same problem with a solution which contained projects in a Solution Folder, when they were moved to the Solution Root (in order to overcome a suspected bug with the Mvc3AppConverter due to project locations).

Although the solution compiled after all* project references were re-added as needed, the error was thrown when the website was fired up.

The EDMX is in one of the projects which was moved (the 'Data' project), but of course the lack of a reference to the Data project didn't cause a compile error, just a run-time error.

Simply adding the missing reference to the primary project resolved this problem, no need to edit the connection at all.

I hope this helps someone else.

A poor app.config or web.config file can do this.. I had copied the app.config connection string to my web.config in my UI and ended up entering:

<connectionStrings>
    <connectionStrings>
          <add name="name" connectionString="normalDetails"/>
    </connectionStrings>
</connectionStrings>

I simply hadn't referenced my class library that contained the EDMX file.

• This really helped my particular circumstances, thanks @PeterX. - Moby's Stunt Double

If you are using the edmx from a different project, then in the connection string, change...

metadata=res://*/Data.DataModel.csdl

...to...

metadata=res://*/DataModel.csdl

My theory is that if you have more than one edmx file with same name (Model1 for example), it will give that exception. I've got same problem when I decided to name all my edmx files (sitting in different projects) as Model1 because I thought they should be independent.

Another cause for this exception is when you include a related table in an ObjectQuery, but type in the wrong navigation property name.

Example:

var query = (from x in myDbObjectContext.Table1.Include("FKTableSpelledWrong") select x);