Skip to content

Troubleshooting Entity Framework Connection Strings

In an application which uses the Entity Framework, you may see the following error at runtime:

MetadataException: Unable to load the specified metadata resource

The cause of this error is a missing or malformed Entity Framework connection string. In particular, the cause of this error is the metadata parameter of the connection string. Let’s examine this more closely.

Which Config File?

Before you begin troubleshooting, make sure you are looking at the correct file.

Connection strings are loaded from the configuration file for the executing assembly, which may not be the assembly which contains your Entity Framework model. So if you have a data assembly containing an Entity Framework model and a web assembly containing a web application which references the data assembly, then the Entity Framework connection string needs to be in the Web.config file for the web assembly. The data assembly can have its own connection string, if you like (this is convenient, as it will be used by the Entity Framework designer), but it will not be used by the web application at runtime.

Metadata

MSDN documents EF connection strings generally. But the cause of the error above is specifically the metadata parameter. This parameter tells the Entity Framework where to find your EDMX at runtime. When your application is compiled, the EDMX is split into three parts: CSDL, MSL, and SSDL. For the purposes of this post, you don’t need to think about what they mean right now; it’s enough to know that you need all three of them at runtime.

The EDMX can be supplied to the application as embedded resources or files on disk. The default is embedded resources, so we’ll focus on that case.

The metadata parameter for an application with an Entity Framework model called Model.edmx in an assembly called Simple Mvc.Data.dll might look like this:

<connectionStrings>
	<add name="MyEntities" connectionString="metadata=
            res://Simple Mvc.Data.dll/Model.csdl|
            res://Simple Mvc.Data.dll/Model.ssdl|
            res://Simple Mvc.Data.dll/Model.msl;provider= <!-- ... -->

So you can see there is one reference for each of the three parts of the EDMX that we need at runtime. They all work in the same way, so let’s examine just the first more closely. The CSDL reference looks like this:

            res://Simple Mvc.Data.dll/Model.csdl

It specifies three things:

  1. We’re loading the CSDL from a resource. That’s the "res://" part.
  2. The name of the assembly which contains the resource, "Simple Mvc.Data.dll". If your assembly is strong named, you can specify a strong name, in all its verbose glory, here.
  3. The name of the resource itself, "Model.csdl". Do not confuse this with the EDMX or model name. In this case they happen to be the same, except for the extension, but that’s not always true!

Let’s examine #2 and 3 more closely.

Assembly name

It’s really common to omit the assembly name in a connect string, and use * instead, like this:

<connectionStrings>
	<add name="MyEntities" connectionString="metadata=
            res://*/Model.csdl|
            res://*/Model.ssdl|
            res://*/Model.msl;provider= <!-- ... -->

This means that instead of loading the resource from one specific assembly, the EF will scan all loaded assemblies at runtime. Two obvious downsides to this are that it takes a bit of time to do this, and the assembly might not be loaded yet. The second case is one reason you might get the error at the start of this post. So specifying the assembly explicitly is always a good idea, I think.

Resource names

Remember how I said that the resource name isn’t necessarily the same as the model name? Here’s a real-life example of that. I opened one of our production assemblies in Reflector, and found this:

There’s actually a good reason that those resources have such bizarre names, but it’s a digression and not relevant to this post. The point is that after you’re sure the assembly name is right, the next step in solving the error at the top of this post is to double-check the resource names.

A simpler resource name will look like this:

Remember the "simpler" metadata where I used * instead of the assembly name? You can go even simpler. This metadata, perhaps surprisingly, actually works (with caveats):

<connectionStrings>
	<add name="MyEntities" connectionString="metadata=
            res://*/;provider= <!-- ... -->

This is the "throw everything against the wall and see what sticks" approach to a connect string. It will probably fail if your resources don’t happen to have the same name as your model, or if the assembly doesn’t happen to be loaded. But it (in simpler cases, anyway) frees the programmer from having to think about what any of this stuff means, so it’s a popular solution.

{ 65 } Comments

  1. Mauro | August 21, 2010 at 4:43 pm | Permalink

    Thanks, a good guide for that very non descriptive error.
    "Unable to load the specified metadata resource"

    Thanks agains

  2. Bryce | September 6, 2010 at 4:39 am | Permalink

    This error was driving me up the wall. I think I have it fixed now. Some things I know so well and other items like this I’m lost

  3. Matthias Liebeck | September 18, 2010 at 1:50 pm | Permalink

    Nice post. You should work on your SEO to achieve a higher google ranking. I was unable to find this entry with google. Your link on stackoverflow brought me here

  4. Marius Mans | October 5, 2010 at 1:06 am | Permalink

    Greate, Greate, Great !!!! After 3 hours of searching, this is the solution that explains the problem. FIXED.

  5. Dean | November 17, 2010 at 7:35 pm | Permalink

    You are a man among men! I couldn’t get my test harness to work until your post made me realise my testing app.config was out of date. Thank you very much!

  6. Jamie | December 6, 2010 at 9:01 pm | Permalink

    Great blog post - I was going crazy with this error. Very helpful indeed.

  7. John | December 16, 2010 at 6:42 pm | Permalink

    Wonderfully lucid ! Thank you !

  8. Narek | March 5, 2011 at 5:51 am | Permalink

    Thank you very much, great help!

  9. Brad | March 9, 2011 at 6:24 pm | Permalink

    Any suggestions for getting a connection string to work for an OData service when the EF entities are in a second assembly? Using VS 2010 and .NET 4 I can make the service work when the entitites are declared in the web app offering the service but get the following error when attempting to access the service when entities are declared in a second project.

    "The server encountered an error processing the request. See server logs for more details."

    Unfortunately no logs when running out of VS. I’ve tried both the * and explicit assembly reference. One thing I haven’t test yet is moving my entities to the root folder in the shared assembly. Currently they are in a subfolder in the project assembly and in their own namespace - Application.Project.EntitiesName.

  10. naspinski | March 25, 2011 at 5:44 pm | Permalink

    First of all, GREAT post, this has been a great help. I think I am on the right track, everything works on my local machine and on my dev machine as long as I transfer the file manually. If I use Nant to build the files, I still get the evil error. Everything is still strongly named (checked with the ’sn -T’ tool) and it looks identical, but will not work - I have the full names in the connectionstring and everything. I am not sure if you use Nant or not or maybe might know what else is going on, but any help right now would be appreciated! Thanks again.

  11. naspinski | March 28, 2011 at 10:36 am | Permalink

    You are right, Nant is not compiling the resources at all - they are just not there in reflector. At least I can narrow it down to figuring out how to get the resources and the signing to work together (can seem to get them both to work separately, but not together). Thanks again for the help! Do you happen to know anything about Nant and this problem? :)

  12. naspinski | March 28, 2011 at 11:23 am | Permalink

    You definitely got me on the right track, thank you so much!

  13. jp2code | May 24, 2011 at 3:54 pm | Permalink

    How do I specify a Password parameter?

  14. mohaaron | May 27, 2011 at 5:15 pm | Permalink

    What do I do when the Resources directory is missing when looking at the assembly in Reflector?

  15. Vinod | June 28, 2011 at 9:04 am | Permalink

    You have no idea how much this post helped me! Thanks a million!

  16. sam | July 11, 2011 at 9:04 pm | Permalink

    Thanks. I was about to throw my laptop out of window. And going to fight with my wife. You saved both.

  17. codemonkey | July 13, 2011 at 9:05 pm | Permalink

    I was getting:

    System.IO.FileNotFoundException : Unable to resolve assembly ‘MyAssemblyName.dll’

    I found that i had to remove the ".dll" from the assembly name if I want to specify it explicitly in the connection string. Hope this helps anyone else with that problem.

    Great article, very clear on a potentially confusing topic!

  18. Zhirong | September 4, 2011 at 4:04 am | Permalink

    Really helpful! I finally start running my code with your explanation. thank you:)

  19. nik shornikov | September 16, 2011 at 5:53 pm | Permalink

    second the comment about SEO, but more importantly, I wish more people would slow down and share what they know

  20. AlexxxTremer | September 20, 2011 at 10:13 am | Permalink

    Thanks, this helps me a lot!

  21. XXX | October 17, 2011 at 7:59 am | Permalink

    Thanks, this helps me a lot!

  22. Mohammad Owidat | October 18, 2011 at 2:01 am | Permalink

    this helps me a lot!

    My problem was that I’m having 2 connection strings, and both was formatted using * instead assembly name in a connect string.

    Thanks and Regards,
    Mohammad Owidat

  23. rob | November 4, 2011 at 1:00 pm | Permalink

    Thanks Craig - its a big help.

  24. mclabman | November 14, 2011 at 3:47 am | Permalink

    "Simple Mvc.Data.dll" - cause cant resolve assembly exception. Remove ".dll"
    Must be res://Simple Mvc.Data/Model.csdl

  25. Preethi | November 23, 2011 at 4:07 am | Permalink

    Hi,
    I have gone through your post but and tried all possible solutions that are given here..I’m dealing with this error from 2 days and still have no idea how to resolve it… still i get the same error ."System.Data.MetadataException: Unable to load the specified metadata resource."

    Any help will be appreciated..
    Regards,
    Preethi

  26. Nitin | December 26, 2011 at 2:35 am | Permalink

    Great article!!!! it helped to resolve the issue on which i wasted 3-4 hours.

  27. Shahnawaz Khan | December 28, 2011 at 2:20 am | Permalink

    Nice article, I’ve the exact situation and yes this article helps me to resolve this, however I like the IDEA of placing the assembly name instead of ‘*’ which may take long time to resolve if we’ve lot of assembly.

    I added assembly name as you suggested as is, but I’ve error stating that can’t load that assembly, I then removed the .dll extension and it works!

    Thanks!
    Shahnawaz

  28. CrazyCraka | January 30, 2012 at 7:59 pm | Permalink

    Thank you very much. Great article that very descriptive. Exactly what I needed.

  29. Aurelio | February 17, 2012 at 7:53 am | Permalink

    Very useful stuff. Thanks a lot!

  30. E | February 22, 2012 at 10:05 am | Permalink

    Thanks Craig Stuntz for this truly helpful post. You may have saved me half a day! What did the trick was changing my //*/ to //AssemblyName/ (and also double-checking my assembly name and default namespace). Though not new at this, I was stumped–thinking maybe that the problem was EF 4.3 or VS itself. I was all over the web and thank goodness found your post (through StackOverflow). Now, I bookmarked you directly! So many thanks!

  31. Beki | March 2, 2012 at 12:54 am | Permalink

    Thank You very much for the explanation. It really helped me solving my problem.

  32. Mcafee | March 2, 2012 at 3:43 am | Permalink

    great post, i was searching for two hours already!!

  33. Ryan Russon | March 5, 2012 at 3:59 pm | Permalink

    Thanks for tackling this problem! One other helpful reference for seekers is here:
    http://colinmackay.co.uk/blog/2011/07/23/entity-framework-unable-to-load-the-specified-metadata-resource/ Colin’s site made me realize there was a really simple way to get the EF connection string right again –just update from DB and copy it from the Model properties setting!

  34. spons | April 14, 2012 at 9:11 am | Permalink

    Tank you very much This helped me a lot! Finally a good explanation

  35. Jphn | June 18, 2012 at 4:12 pm | Permalink

    Thanks for the great article. If you could remove the ".dll" reference in your post, it would avoid a lot of confusion for those making use of it, b/c the .dll leads to system.io exception.

  36. Chris Roberts | June 20, 2012 at 3:15 am | Permalink

    Fantastic. Thank you! This error message had me pulling my hair out… Googling like crazy and poking around in my *.config files. But the line: "Connection strings are loaded from the configuration file for the executing assembly" made it all so clear! Thanks!

  37. Tom | June 26, 2012 at 8:13 am | Permalink

    Great post! Really helped me find the cause of this error message in my code.

  38. Mike Breault | August 23, 2012 at 9:26 am | Permalink

    Just what I needed. Thank you!

  39. Heisenburg | August 24, 2012 at 1:41 am | Permalink

    I can’t believe how f’n painful they have made this.

  40. druse | September 5, 2012 at 7:36 am | Permalink

    Thumbs up man,

    This just saved us a lot of headaches…

  41. Raf | September 12, 2012 at 6:37 pm | Permalink

    awesome write up. big help, thanks!

  42. Chris Keeble | September 14, 2012 at 8:57 am | Permalink

    Thanks, Craig. This really helped us with a major project namespace change today.

    For others with multiple project solutions, remember that your metadata connection string may be found in multiple app.config files depending on the structure of your project. Check them all!

    Chris

  43. Davy | September 28, 2012 at 12:58 pm | Permalink

    You’re the man!

  44. aelena | September 28, 2012 at 2:07 pm | Permalink

    The idea to decompile saved me. thanks so much. What I don’t know is how I ended up with different names inside the .dll and in the config files

    other times never faced this shit error

  45. Tommie Nygren | October 25, 2012 at 2:48 am | Permalink

    I think you should update the post to include the information from comment 21 and 31 to it - that solved this issue for me, whereas using /* without the model file names made it look like it worked - but it didn’t.

    Thanks to everyone.

  46. ThomasA | December 28, 2012 at 2:57 pm | Permalink

    If it were feasible to put this post behind a paywall and say, "This will solve your "MetadataException: Unable to load the specified metadata resource" issue, but first you have to pay $10", you’d be a millionaire.

    I encountered it on Azure and would have never figured it out without this article. Three days of pain to learn that I need to append one word to the csdl, msl, ssdl.

  47. John | January 20, 2013 at 3:12 am | Permalink

    Hi, thanks for sharing this.

    I’ve hit the Unable to load the specified metadata resource when deploying applications to an Azure Web Role - you’ve saved me a lot of time!

  48. Dave | January 24, 2013 at 3:22 pm | Permalink

    Thank you for this. It helped me.

  49. Stephen Chung | February 6, 2013 at 11:56 am | Permalink

    This blog pointed to the way to solved my problem. Thanks a great deal! Saved me a lot of time!

    Microsoft should REALLY work on their error messages…

  50. andrei | February 10, 2013 at 9:12 am | Permalink

    anyone that makes sense out of the junk that microsoft throws in my face deserves my utmost respect.

    thanks for the explanations. a lot.

  51. Shailesh | April 9, 2013 at 8:03 am | Permalink

    Thanks … Very helpful. I had to dig a lot before I reached here.

    Resolved!

  52. El Matador | May 7, 2013 at 3:03 pm | Permalink

    To solve my problem I deleted the connection string and refreshed the model from database and it re added the correct connection string.

    Great post!

  53. DAVID | May 27, 2013 at 12:46 am | Permalink

    SUPER

  54. Jan | July 30, 2013 at 11:08 am | Permalink

    You saved my day, thanks!

  55. Json | August 11, 2013 at 9:11 am | Permalink

    Great article, thanks Craig.
    And thanks to codemonkey for the bit about dropping the .dll name for some folks…that got it working.

  56. Abhijeet girase | August 13, 2013 at 5:15 pm | Permalink

    Great article..Thanks God I found it ….2010 08 13 this article posted and 2013 08 13 I am using it ….08 13 is my birthday….

  57. Joe Herr | August 30, 2013 at 12:46 pm | Permalink

    Thanks and thanks to codemonkey for the tip about removing ".dll" from the metadata string. That got me working.

    I had actually figured this out previously about a year ago but ended up not using the code so I had to rediscover the joys of entity connection strings.

  58. chandimal | September 11, 2013 at 4:29 am | Permalink

    Thanks this is great article .. really solve my problem

  59. Tim | September 19, 2013 at 3:35 am | Permalink

    Thanks- your post was the breakthru I needed to hit my next deployment slot.

  60. Igor | September 30, 2013 at 4:49 pm | Permalink

    Thanks, this helps me a lot!

  61. Brad Wood | October 9, 2013 at 9:15 am | Permalink

    mclabman:
    "Simple Mvc.Data.dll" - cause cant resolve assembly exception. Remove ".dll"
    Must be res://Simple Mvc.Data/Model.csdl

    I also had to remove ".dll" but what in the *hell* is "Simple"? I just used the name of the .dll without the extension?

  62. Shawn | April 19, 2014 at 3:57 pm | Permalink

    Fantastic post mate - if only all exceptions were documented this well on MSDN. Instead we have boilerplate text which simply makes the issues behind the exceptions even more obscure and opaque. Microsoft would be lucky to have you on their programmer writer staff!

  63. chlebta | April 23, 2014 at 5:23 am | Permalink

    I can’t get the right format of connecting string
    This my connection string :

    insteand of /*/ i tried (mvcapplication5, mvcapplication5.dll, EntityFRamework.dll, entityFramework … ) and many other thing but always same probleme

  64. Shihab | July 11, 2014 at 9:20 pm | Permalink

    Thanks a lot for such a helpful post.

  65. Joe Herr | July 24, 2014 at 1:41 pm | Permalink

    This helps. Every few months I have to monkey around with the connections strings and inevitably I have some issue with the metadata.

{ 7 } Trackbacks

  1. [...] Well, if your goal is to make this “bulletproof,” this won’t work. The string you call modelName is not actually the model name, but the resource name. In your case it coincidently happens to be the same as the model name, but that isn’t always true. [...]

  2. [...] was automatically generated for me, so why would it fail?  After lots of googling, I found this page on Craig Stuntz’s blog that has some very handy troubleshooting tips.  He lists several possibilities as to why the [...]

  3. [...] http://blogs.teamb.com/craigstuntz/2010/08/13/38628/ This entry was posted in all. Bookmark the permalink. [...]

  4. [...] Stuntz has put-up a useful blog post related to this topic and how to Troubleshooting Entity Framework Connection Strings which might be useful in case you are getting the same error [...]

  5. [...] some dynamic loading going on and got mislead looking at MEF. Then a lucky hit on Google brought up Craig Suntz’s blogand explained what my issue was. It is down to Entity Framework connection [...]

  6. [...] to close the connection with $conn.close()other links to how if  I figured this out: http://blogs.teamb.com/craigstuntz/2010/08/13/38628/http://alvinjiang.blogspot.com/2010/10/adonet-entity-framework-tips-what-is.html [...]

  7. [...] to close the connection with $conn.close()other links to how if  I figured this out: http://blogs.teamb.com/craigstuntz/2010/08/13/38628/http://alvinjiang.blogspot.com/2010/10/adonet-entity-framework-tips-what-is.html [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *

Bad Behavior has blocked 713 access attempts in the last 7 days.

Close