等待!哪个配置文件? (实体框架连接字符串) [英] Wait! which config file? (Entity Framework Connection String)

查看:79
本文介绍了等待!哪个配置文件? (实体框架连接字符串)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

因此,我在单独的类库中创建了实体模型。我必须将连接字符串添加到该类库的 app.config 文件中。然后,在我的Web应用程序中为该项目添加了一个引用。我在Web应用程序的 web.config 中添加了相同的连接字符串,认为这是Entity Framework将从中读取连接字符串的位置。

So, I created my entity model in a separate class library. I had to add the connection string to the app.config file of that class library. Then I added a ref for that project in my web application. I added the same connection string in the web.config of my web application thinking this is where Entity Framework will be reading the connection string from.

在我部署Web应用程序之前,一切都很好。部署后,我在 web.config (而不是类库的 app.config )中更改连接字符串,然后我开始出现错误。经过研究后,我发现 web.config app.config 中的连接字符串必须匹配!

Everything was fine up until I deployed my web app. When I deployed I change the connection string in the web.config (not app.config of the class library) and I started getting errors. After doing some research I found out that the connection string in both web.config and app.config must match!!

这真是愚蠢!每次需要将Web应用程序部署到其他环境时,都必须返回并修改 app.config 文件中的连接字符串,然后重新编译类库项目,如此它可以获取刷新的连接字符串吗?

This is just dumb! Every time I need to deploy my web app to a different environment I must go back and modify the connection string in the app.config file and then recompile my class library project just so it can get the refreshed connection string?

有人找到了更好的方法吗?我的意思是,我不能只有想到将实体模型放在单独的程序集中的人。

Has anyone found a better way of doing this? I mean, I cant be only person who thought of putting the entity model in a seperate assembly.

可能的解决方案(如果您使用的是EF 4.1):
因为我们需要在类库项目中包含app.config的唯一原因是针对EF设计器。如果我们放弃设计器方法并使用Code-First(EF 4.1),则不需要为类库项目提供app.config文件。

Possible Solution (if you are using EF 4.1): Since the only reason why we need to have app.config inside a class library project is for the EF designer. If we ditch the designer approach and go with Code-First (EF 4.1) you will not need to have an app.config file for your class library project.

推荐答案

我们遇到了同样的情况。我已要求每个开发人员仅使用选择的第一个连接字符串来编译EF程序集。

We ran into the same situation. I've asked each developer to only ever compile the EF assembly with the first connection string selected.

通过这种方式,部署后,在web.config中只需要一个连接字符串。

This way, when deployed, only one connection string is needed in the web.config.

最终,如果每个开发机器和部署服务器在第一个(并且希望是唯一的)连接字符串(即,不是ConnectionString4)中都具有正确的连接信息(对于该机器),那么工作就很容易。

Eventually, if each development machine and deployment server has the correct connection information (for that machine) in the first (and hopefully only) connection string (i.e., not ConnectionString4), life is easy.

基本上,当默认连接字符串(最新选择)无法连接时,设计者会将额外的连接字符串添加到dev连接字符串中。

Basically, extra connection strings are added by the designer to the dev connection string when the default connection string (latest selected) can't connect.

此外,没有理由为将数据层放置到单独的程序集中而感到难过。有时这是可取的。

Also, there's no reason to feel bad about putting the data layer into a separate assembly. Sometimes this is preferable.

最后,确保包含连接字符串的配置文件未挂钩到源代码控制是非常重要的-连接字符串通常已本地化并且会导致 EF和LINQ to SQL中的 multi-connection-string-issue,如果每次您从源代码管理更新项目时,它总是被错误的值覆盖。

Finally, it's pretty important to make sure the config file that contains the connection string is not hooked to source control -- the connection string is often localized and will cause the "multi-connection-string-issue" in EF and LINQ to SQL if it keeps getting overwritten with bad values every time you update your project from source control.

这篇关于等待!哪个配置文件? (实体框架连接字符串)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆