I have a solution with two relevant projects. The first builds My.exe, and the second builds a class library MyModel.dll that contains only my EF model.
I'm getting a MetadataException
in my Model's VS-generated ObjectContext
ctor. I've read through Troubleshooting Entity Framework Connection Strings, but I still haven't been able to narrow down my problem.
The offending constructor code:
public MyEntities() :
base(@"name=MyEntities", "MyEntities") // MetadataException here
{
this.ContextOptions.LazyLoadingEnabled = true;
OnContextCreated();
}
Metadata Artifact Processing is set to EmbedInOutputAssembly
. When I open MyModel.dll in Reflector, I see:
I've tried setting Build Action for my app.config to None
and Content
, and neither makes a difference. The config file contains:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<connectionStrings>
<add name="MyEntities"
connectionString="metadata=
res://*/DataAccessLayer.MyModel.csdl|
res://*/DataAccessLayer.MyModel.ssdl|
res://*/DataAccessLayer.MyModel.msl;
provider=Devart.Data.PostgreSql;
provider connection string="
User Id=MY_USER;
Password=MY_PASS;
Host=127.0.0.1;
Database=MY_DB;
Persist Security Info=True""
providerName="System.Data.EntityClient" />
</connectionStrings>
</configuration>
I've tried replacing the resource prefix res://*/
with both res://MyModel.dll/
and res://MyModel/
, leaving the rest intact (because it matches the resources in MyModel.dll), but neither solved the problem. My class library is strong-named.
Both my executable and class library projects contain references to System.Data.Entity
and Devart.Data.PostgreSql
, and My.dll is being built to the same location as My.exe.
I stepped into .NET source code, and by examining the arguments & local variables of internal EF calls, found the resource assembly name was still set to *
.
It turns out a bug in my application code set the model's default connection string before calling the ObjectContext
ctor. It was pulled from a Settings.settings file, which hadn't been recently sync'd with the latest, correct app.config.
Some reflections on our discussion in the comments:
The correct assembly name in app.config is MyModel
rather than MyModel.dll
(as shown in Craig's article.) Using MyModel.dll
produces an exception in the EF code.
Calling the ctor as base(@"name=MyEntities")
instead of base(@"name=MyEntities", "MyEntities")
actually produced a new exception in ObjectContext.GetEntitySetName()
I updated Settings.settings to be in sync with app.config, and everything is now working.