因此，我在一个单独的类库中创建了实体模型。我不得不将连接字符串添加到该类库的app.config文件中。然后我在我的web应用程序中添加了该项目的引用。我在web应用程序的web.config中添加了相同的连接字符串，认为这是实体框架读取连接字符串的地方。
一切都很好，直到我部署了我的网络应用程序。当我部署时，我更改了web.config（而不是类库的app.config）中的连接字符串，开始出现错误。经过研究，我发现web.config和app.config中的连接字符串必须匹配！！
这太愚蠢了！每次我需要将我的web应用程序部署到不同的环境时，我都必须返回并修改app.config文件中的连接字符串，然后重新编译我的类库项目，这样它才能获得刷新的连接字符串？
有人找到更好的方法吗？我的意思是，我不可能是唯一一个想到把实体模型放在一个单独的程序集中的人。
可能的解决方案（如果使用EF 4.1）：因为我们需要在类库项目中包含app.config的唯一原因是EF设计器。如果我们放弃设计器方法，转而使用代码优先（EF 4.1），那么您的类库项目就不需要有app.config文件。
我们也遇到了同样的情况。我已经要求每个开发人员只在选择第一个连接字符串的情况下编译EF程序集。
这样，在部署时，web.config中只需要一个连接字符串。
最终，如果每个开发机器和部署服务器在第一个（希望也是唯一一个）连接字符串（即，不是ConnectionString4）中都有正确的连接信息（针对该机器），那么生活就很容易了。
基本上，当默认连接字符串（最近选择的）无法连接时，设计器会将额外的连接字符串添加到dev连接字符串中。
此外，没有理由对将数据层放入单独的程序集感到不好。有时这样做更可取。
最后，确保包含连接字符串的配置文件没有挂接到源代码管理非常重要——连接字符串通常是本地化的，如果每次从源代码管理更新项目时，它总是被错误的值覆盖，就会导致EF和LINQ to SQL中的"多连接字符串问题"。