The EntityContainer name must be unique. An EntityContainer with the name 'Entities' is already defined

Question

For a little background:

I have a DLL project with the following structure:

Rivworks.Model (project)  
  \Negotiation (folder)  
      Model.edmx (model from DB #1)  
  \NegotiationAutos (folder)  
      Model.edmx (model from DB #2)  

I have moved the connection strings from this project's app.config to the web.config file. They are not in the ConnectionString section. Rather, I have a static class that consumes part of the web.config and exposes them to my app as AppSettings.[settingName].

<FeedAutosEntities_connString>metadata=res://*/;provider=System.Data.SqlClient;provider connection string='Data Source=db4;Initial Catalog=RivFeeds;Persist Security Info=True;User ID=****;Password=&quot;****&quot;;MultipleActiveResultSets=True'</FeedAutosEntities_connString>
<RivWorkEntities_connString>metadata=res://*/NegotiationAutos.NegotiationAutos.csdl|res://*/NegotiationAutos.NegotiationAutos.ssdl|res://*/NegotiationAutos.NegotiationAutos.msl;provider=System.Data.SqlClient;provider connection string='Data Source=db2;Initial Catalog=RivFramework_Dev;Persist Security Info=True;User ID=****;Password=&quot;****&quot;;MultipleActiveResultSets=True'</RivWorkEntities_connString>

I have 2 classes, one for each Context and they look like this:

namespace RivWorks.Model
{
    public class RivWorksStore
    {
        private RivWorks.Model.Negotiation.Entities _dbNegotiation;

        public RivWorksStore(string connectionString, string metadata, string provider)
        {
            EntityConnectionStringBuilder entityBuilder = new EntityConnectionStringBuilder();
            entityBuilder.ConnectionString = connectionString;
            entityBuilder.Metadata = "res://*/";    // metadata;
            //entityBuilder.Provider = provider;
            _dbNegotiation = new RivWorks.Model.Negotiation.Entities(entityBuilder.ConnectionString);
        }

        public RivWorks.Model.Negotiation.Entities NegotiationEntities()
        {
            return _dbNegotiation;
        }
    }
}

namespace RivWorks.Model
{
    public class FeedStoreReadOnly
    {
        private RivWorks.Model.NegotiationAutos.Entities _dbFeed;

        public FeedStoreReadOnly(string connectionString, string metadata, string provider)
        {
            EntityConnectionStringBuilder entityBuilder = new EntityConnectionStringBuilder();
            entityBuilder.ConnectionString = connectionString;
            entityBuilder.Metadata = "res://*/";    // metadata;
            //entityBuilder.Provider = provider;
            _dbFeed = new RivWorks.Model.NegotiationAutos.Entities(entityBuilder.ConnectionString);
        }

        public RivWorks.Model.NegotiationAutos.Entities ReadOnlyEntities()
        {
            return _dbFeed;
        }
    }
}

You will note that the MetaData is being rewritten to a short version.

When I comment out that line in each class I get this error:

Unable to load the specified metadata resource.

When I leave that line in in each class I get this error:

Schema specified is not valid. Errors:

Negotiation.Model.csdl(3,4) : error 0019: The EntityContainer name must be unique. An EntityContainer with the name 'Entities' is already defined.

I know it is something simple, something obvious. Any suggestions welcome...

Solution 1

Your two EDMX files probably have the same entity container name. You need to change (at least) one of them.

In the GUI designer, open Model Browser. Look for a node that says "EntityContainer: Entities". Click it. In Properties, change Name to something else. Save and rebuild.

Solution 2

Hijacking this, since it is the top Google result for the error message.

In case anyone else encounters this while only using a single model/context: I once ran into this problem because the assembly containing the model/context was renamed and a copy with the previous name remained in the bin directory of the application. The solution was to delete the old assembly file.

Solution 3

I had the problem too but my solution was to clean the bin directory and then remove the connection string with the entity container name. Then I could rename my entities and put back the connection string.

Solution 4

I renamed my project but the old file was still in the bin folder. I just had to delete the old DLL from the bin folder.

Solution 5

I have found a way to save multiple containers with the same name (namespaced of course).

In EF5 and VS2012 you can set three different namespaces. First you can click on the edmx file in the solution browser and in the properties windows you can set the "Custom Tool Namespace", you can click on the *.Context.tt file right below the edmx and set another namespace there, and finally thanks to a lead from Mr Stuntz awesome answer I realized that by opening the edmx file and clicking in the white space you get another namespace field under Schema in the properties window.

Think we're done, not quite, I know you can see the Entity Container Name field and will try to change the name there but that doesn't seem to work, you get a little error that pops up. Ensure that all your edmx files have an individual namespace there. (I ensured I had a unique namespace in all three places)

Then go to your Model Browser and right click on EntityContainer: Entity to go to properties and change the name of your container(s). From that window with the namespace set everywhere I was able to get multiple contexts with the same name. I was dealing with things like blahcontext and blahcontextcontainer all of a sudden even though they were in different folders.

When you see that its a namespace problem. Or lack thereof.

View more solutions

Comments

[Keith Barrows]

yep - as simple as that. (still trying to understand the overall model of EF at the (usually hidden) class level.)

[Ayo I]

You may also need to open the EDMX file in notepad as Visual Studio may not properly pick up the change when you simply change the container name in the property pane.

[Chris]

I experienced the exact same issue after renaming my assembly . You need to manually delete the old files from the bin folder as a Visual Studio is no longer tracking them and performing a "Clean" will not remove them

[Daniel Kabzon]

Greate, thanks a lot. I've got the same assembly of different versions, one in the bin of Web Service (4.0.1.0) and another in the GAC (4.0.1.2). In the config file I define two use the GAC version (Custom Role Provider). I had the same error ultill the old version dll had been removed from the bin folder.

[tina Miller]

I also had to change the Model.tt file and change the namespace there. I'm not sure that changing the actual edmx namespace changes anything though...

[tina Miller]

Weird, if I don't set the namespace on the edmx (left click on edmx, not left click in white space), it stops generating half my POCOs. If I include it, I get an extra (empty) Model.cs class generated. If I change the namespace with left click in white space too, I get nothing but the Model.cs class. Ngngng

[tina Miller]

Eejit me: in the same folder, so the second one generated obviously squishes the first...

[ChrisO]

Just to clarify for others, the old assembly is located on the server side in the deploy location.

[Codes with Hammer]

In my case, I had one EDMX file that I dropped and re-added. I had to go through Model Browser => Properties to reestablish the container name.

[trousyt]

I was publishing to a web server and it doesn't delete old assemblies from the bin directory by default. This was exactly it.

[TheSoftwareJedi]

This needs bumped to the top of the page. Excellent answer, saved me a headache. I wish I could changetip ya.

[user230910]

Jip, came back here after a few months and saw my original upvote. Wish I could upvote again

[Mike Burger]

The 'performing a clean will not remove them' cannot be emphasized enough.

[Nick]

+1 This is the solution for me. Deleting bin contents on its own didn't solve it; the connection string part of this answer did the trick.

[Federinik]

This helped, should be integrated in jpo's answer!

[Admin]

This could happen both in VS2012 and still in VS2017

[Alex]

For me, this answer together with MrFlo answer did the trick.