如何在.NET中针对不同环境使用不同的.settings文件？
.NET 允许您使用 .settings 文件来管理应用程序设置。我想以一种可以执行以下操作的方式单独存储生产、开发和测试设置：
EnvironmentSettings environmentSettings;
// get the current environment (Production, Development or Test)
ApplicationEnvironment Environment = (ApplicationEnvironment)
Enum.Parse(typeof(ApplicationEnvironment), Settings.Default.ApplicationEnvironment);
switch (Environment)
{
case ApplicationEnvironment.Production:
environmentSettings = Settings.Production;
break;
...
}
string reportOutputLocation = environmentSettings.ReportOutputLocation;
基本上，我想要两个单独的设置类：存储所选环境和非环境特定属性的常规设置类，以及 3称为EnvironmentSettings 的第二个类的静态实例。使用的实例应取决于常规 Settings 类中指定的环境。
有没有什么方法可以做到这一点，而不是在静态构造函数或其他东西中手动设置所有这些设置的值？如果我必须这样做，我宁愿只拥有一个大的 Settings 类，其中包含“DevOutputLocation”、“LiveOutputLocation”等属性。
我的项目中可以有多个 .settings 文件，但这只是创建了单独的类，而这些类并不彼此衍生。因此，我可以创建 DevelopmentSettings.settings、ProductionSettings.settings 和 TestSettings.settings 文件并赋予它们相同的属性，但是随后我需要到处使用一堆 switch 语句来确定要使用哪个类，因为它们不是从公共类派生的。
.NET allows you to use .settings files to manage application settings. I would like to store Production, Development and Test settings separately in a way that I can do something like this:
EnvironmentSettings environmentSettings;
// get the current environment (Production, Development or Test)
ApplicationEnvironment Environment = (ApplicationEnvironment)
Enum.Parse(typeof(ApplicationEnvironment), Settings.Default.ApplicationEnvironment);
switch (Environment)
{
case ApplicationEnvironment.Production:
environmentSettings = Settings.Production;
break;
...
}
string reportOutputLocation = environmentSettings.ReportOutputLocation;
Basically, I want two separate Settings classes: the general Settings class that stores the selected environment and non-environment specific properties, and 3 static instances of a second class called EnvironmentSettings. The instance used should depend on the environment specified in the general Settings class.
Is there any way to do this short of manually setting the values for all these settings in a static constructor or something? If I have to do that, I'd rather just have one big Settings class with properties like "DevOutputLocation", "LiveOutputLocation", etc.
I can have multiple .settings files in my project but that just creates separate classes that don't derive from each other. So I could make DevelopmentSettings.settings, ProductionSettings.settings and TestSettings.settings files and give them the same properties, but then I would need a bunch of switch statements everywhere to determine which class to use because they don't derive from a common class.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
一种想法是，在一系列静态值之间切换听起来像是一种相当令人担忧的做事方式。
我建议查找单例模式。此模式为您提供了一个在该类的所有引用之间共享的单个类实例，但是当它首次加载时，您可以执行正常的初始化位来检查您的环境并相应地设置值。
同样，您不会考虑设计一个接口并让每个类实现该接口，而不是使用开关来作用于不同的类吗？
One thought is that switching between a series of static values sounds like a rather fraught way of doing things.
I would suggest looking up the Singleton pattern. This pattern gives you a single class instance that is shared between all references to the class, but when it's first loaded you can do your normal initialisation bits to check your environment and set the values accordingly.
Equally, rather than using switches to act on different classes, wouldn't you be looking at designing one Interface, and having each class implement that interface?
我正在对 .config 文件使用这种方法，我相信它也会对您有所帮助。 只需查看 Scott Hanselman 的博客文章 和 这个问题。意识形态很简单，但效果很好。您所需要的只是：
带有设置的类的实例化代码将始终显示在默认设置中（每次构建后都会替换为所需的设置），因此这种方法需要最少的努力。
I am using this approach for .config files, I am sure that it will help you too. Just look on Scott Hanselman's blog post and this question. Ideology is simple like hell, but works pretty good. All you will need is:
Instantiation code for you class with settings will always look in default settings (which will be replaced after each build with the needed one), so this approach require minimal effort.
检查以确定您正在运行的环境会产生一些开销。如果您正在讨论 Web 环境，那么这可能意味着性能会受到重大影响。我建议创建三个单独的配置文件，并设置一个持续集成和部署系统，该系统可以根据环境处理命名并推出适当的设置文件。在您的情况下，您将拥有三个文件：Production.config、Development.config 和 Test.config。然后，集成服务器将根据环境为 web.config 或 app.config 创建该文件的副本。
至于每当进行配置更改时维护三个独立文件所涉及的任何额外维护，我们都会自动格式化文件并使用 WinMerge 之类的工具轻松查看差异并保持它们正确同步。这些类型的文件通常不需要进行太多更改，即使需要更改，通常也只是进行少量添加。
There is a bit of overhead involved in making a check to determine what environment you are running in. If you are talking a web environment then this could mean a significant performance hit. I would recommend creating three separate config files and setting up a continuous integration and deployment system that handles the naming and roll out of the proper settings file based on environment. In your case you would have three files, Production.config, Development.config, and Test.config. The integration server would then create a copy of this file for web.config or app.config based on the environment.
As far as any additional maintenance involved with maintaining three separate files whenever a configuration change is made, we keep the files auto-formatted and use something like WinMerge to easily see differences and keep them in proper sync. These type of files typically do not require many changes and when they do they are usually minor additions.
我目前正在做类似于 pdavis 提到的解决方案的事情。但为了简化多个配置文件，我使用 T4 模板来创建特定于环境的配置文件。这样就有一个 web.tt 文件来处理默认 web.config 文件的生成。每个环境都有自己的模板文件（qa.tt、生产.tt 等），该文件继承自 web.tt 并包含任何特定于环境的覆盖。对 Web 配置的任何更改 - 新的应用程序设置、配置设置等都会通过重新生成模板自动传播到所有区域特定的配置文件，并且您不必担心使用 diff 工具保持文件同步。
I currently do something similar to the solution mentioned by pdavis. But to simplifying multiple config files I use a T4 templates to create the environment specific config files. That way there is one web.tt file that handles the generation of the default web.config file. Each environment has its own template file (qa.tt, production.tt, etc) that inherits from web.tt and contains any environment specific overrides. Any changes to web config - new app settings, configuration settings, etc. are automatically propagated to all region specific config files by regenerating the templates, and you don't have to worry about keeping files in sync using a diff tool.
只是一个想法，但它可能会起作用...
您将需要 N+2 个设置文件（N
不同的构建； 2名硕士）与
包含相同的键。
清除“自定义工具”属性
对于除了一位大师之外的所有人（所以
大师只生成一个）。
修改每个版本的预构建脚本，以将适当的设置文件内容复制到构建主文件中。
修改每个版本的预构建脚本，以将适当的设置文件
修改构建后脚本以将辅助主文件内容复制回原始主文件。
修改构建后
注意：如果您可以在构建前和构建后脚本中使用源代码控制提供程序，则不需要辅助主控 - 您只需在构建前签出并在构建后撤消签出即可。但是，这可能会在持续集成环境中导致问题，因为锁定的文件将导致构建失败。
我也从来没有这样做过；尽管有时我希望有一种更预先的方法在 VS 中做这样的事情。
Just an idea but it may work...
You'll need N+2 settings files (N
different builds; 2 masters) with
containing the same keys.
Clear out the "Custom Tool" property
for all of them but one of the masters (so
only one the master generates).
Modify the pre-build script for each release to copy the appropriate settings file contents into the build-master file.
Modify the post-build script to copy the secondary master file contents back in to the original master file.
Note: If you can work with your source control provider in the pre- and post-build scripts, you don't need a secondary master -- you can just check out in the pre-build and undo check out in the post-build. However, this may cause issues in a continuous integration environment since a locked file would require the build to fail.
I've also never done this; though there are times I wished there was a more up-front way of doing something like this in VS.
只是关于基于 .NET 环境的配置文件的一些额外信息，无需专门使用上述实现：
企业库自 V3.0 起就有此功能：
摘要< /a>
Visual Studio 2010 也将具有此功能。它称为配置转换
Just some extra info on .NET environment based config files without using your above implementation specifically:
The Enterprise Library has this feature since V3.0:
Summary
Visual Studio 2010 will have this feature also. Its called Config Transformation