你可以把连接字符串传递给EntityFramework，然后继续你的生活:

public partial class UtilityContext : DbContext
{
    static UtilityContext()
    {
        Database.SetInitializer<UtilityContext>(null);
    }

    public UtilityContext()
        : base("Data Source=SERVER;Initial Catalog=DATABASE;Persist Security Info=True;User ID=USERNAME;Password=PASSWORD;MultipleActiveResultSets=True")
    {
    }

    // DbSet, OnModelCreating, etc...
}

你是对的，这是因为类库(其中.edmx文件)不是你的启动/主项目。

您需要将连接字符串复制到主项目配置文件。

如果你的启动/主项目没有配置文件(就像在我的控制台应用程序的情况下)，只需添加一个(启动项目-添加新项->应用程序配置文件)。

更多相关信息可以在这里找到: MetadataException:无法加载指定的元数据资源

这也可能导致在调用代码中没有引用足够的dll引用。一个小小的笨拙的hack可以挽救你的一天。

我遵循DB First方法，并在DAL类库项目中创建了EDMX文件，这是对BAL类库的引用，而BAL类库又由WCF服务引用。

由于我在BAL中得到这个错误，我尝试了上面提到的方法从DAL项目的App.config复制配置细节，但没有解决。最终，在一个朋友的建议下，我只是添加了一个虚拟的EDMX文件到WCF项目(与相关的DB Connectivity等)，所以它导入了所有必要的东西，然后我只是删除了EDMX文件，它只是摆脱了一个干净的构建问题。

确保你的项目(使用DbContext)作为启动

OR

添加到app.config(或web.config)中设置为启动连接字符串的项目

OR

像这样调用命令

Update-Database -Script -ProjectName '<项目名称>' -StartupProjectName '<项目名称>' -ConnectionString '数据源=.;初始目录=<db名称>;集成安全性=True;MultipleActiveResultSets=True' -ConnectionProviderName 'System.Data.SqlClient'

然后再试一次

你可以把连接字符串传递给EntityFramework，然后继续你的生活:

public partial class UtilityContext : DbContext
{
    static UtilityContext()
    {
        Database.SetInitializer<UtilityContext>(null);
    }

    public UtilityContext()
        : base("Data Source=SERVER;Initial Catalog=DATABASE;Persist Security Info=True;User ID=USERNAME;Password=PASSWORD;MultipleActiveResultSets=True")
    {
    }

    // DbSet, OnModelCreating, etc...
}

确保你已经在启动项目的ROOT web.config中放置了连接字符串。

I know I'm kinda stating the obvious here, but it happened to me too - though I already HAD the connection string in my MVC project's Web.Config (the .edmx file was placed at a different, class library project) and I couldn't figure out why I keep getting an exception... Long story short, I copied the connection string to the Views\Web.Config by mistake, in a strange combination of tiredness and not-scrolling-to-the-bottom-of-the-solution-explorer scenario. Yeah, these things happen to veteran developers as well :)