Question

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:

• DataAccessLayer.MyModel.csdl
• DataAccessLayer.MyModel.msl
• DataAccessLayer.MyModel.ssdl

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=&quot;
                User Id=MY_USER;
                Password=MY_PASS;
                Host=127.0.0.1;
                Database=MY_DB;
                Persist Security Info=True&quot;"
         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.

Answer 1

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.