.NET 配置 (app.config/web.config/settings.settings) [英] .NET Configuration (app.config/web.config/settings.settings)

查看:33
本文介绍了.NET 配置 (app.config/web.config/settings.settings)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个 .NET 应用程序,它具有用于调试和发布版本的不同配置文件.例如.调试 app.config 文件指向一个开发 SQL Server 已启用调试和发布目标点到实时 SQL Server.还有其他设置,其中一些在调试/发布中有所不同.

I have a .NET application which has different configuration files for Debug and Release builds. E.g. the debug app.config file points to a development SQL Server which has debugging enabled and the release target points to the live SQL Server. There are also other settings, some of which are different in debug/release.

我目前使用两个单独的配置文件(debug.app.config 和 release.app.config).我在项目上有一个构建事件,它表示如果这是一个发布版本,则将 release.app.config 复制到 app.config,否则将 debug.app.config 复制到 app.config.

I currently use two separate configuration files (debug.app.config and release.app.config). I have a build event on the project which says if this is a release build then copy release.app.config to app.config, else copy debug.app.config to app.config.

问题是该应用程序似乎从 settings.settings 文件中获取其设置,因此我必须在 Visual Studio 中打开 settings.settings,然后它会提示我设置已更改,因此我接受更改并保存设置.设置,必须重建以使其使用正确的设置.

The problem is that the application seems to get its settings from the settings.settings file, so I have to open settings.settings in Visual Studio which then prompts me that the settings have changed so I accept the changes, save settings.settings and have to rebuild to make it use the correct settings.

有没有更好/推荐/首选的方法来达到类似的效果?或者同样,我是否完全错误地处理了这个问题,是否有更好的方法?

Is there a better/recommended/preferred method for achieving a similar effect? Or equally, have I approached this completely wrong and is there a better approach?

推荐答案

任何可能因环境而异的配置都应该存储在机器级别,而不是应用程序级别.(有关配置级别的更多信息.)

Any configuration that might differ across environments should be stored at the machine level, not the application level. (More info on configuration levels.)

这些是我通常存储在机器级别的配置元素的种类:

These are the kinds of configuration elements that I typically store at the machine level:

当每个环境(开发人员、集成、测试、阶段、现场)在 c:WindowsMicrosoft.NETFramework64v2.0.50727CONFIG 目录中有自己独特的设置时,然后您可以在不同环境之间推广您的应用程序代码,无需任何构建后修改.

When each environment (developer, integration, test, stage, live) has its own unique settings in the c:WindowsMicrosoft.NETFramework64v2.0.50727CONFIG directory, then you can promote your application code between environments without any post-build modifications.

显然,机器级 CONFIG 目录的内容在不同的存储库或与您的应用程序不同的文件夹结构中受到版本控制.您可以通过智能使用 configSource.

And obviously, the contents of the machine-level CONFIG directory get version-controlled in a different repository or a different folder structure from your app. You can make your .config files more source-control friendly through intelligent use of configSource.

我已经这样做了 7 年,在 25 多家不同公司的 200 多个 ASP.NET 应用程序上.(不是想吹嘘,只是想让你知道,我从未见过这种方法行不通的情况.)

I've been doing this for 7 years, on over 200 ASP.NET applications at 25+ different companies. (Not trying to brag, just want to let you know that I've never seen a situation where this approach doesn't work.)

这篇关于.NET 配置 (app.config/web.config/settings.settings)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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