在开发期间管理多个应用配置文件

Question

我正在构建一个由几个不同客户使用的应用程序.每个客户都有相当数量的自定义业务逻辑,我已经巧妙地将其重构为一个在运行时加载的程序集.该程序集的名称以及许多其他客户特定的设置存储在应用程序的配置文件中.

现在,这是为了调试客户foo的应用程序我必须做的事情:

1. 转到项目目录中的文件系统并删除 app.config
2. 复制app.config.foo到app.config.foo - Copy.
3. 重命名app.config.foo - Copy为app.config.
4. 告诉Windows是的,我想更改文件的扩展名.
5. 切换回Visual Studio.
6. 打开Settings.settings我项目中的项目.
7. 如果我想使用已更改的新设置,请点击"是"13或14次,如果我想要使用已更改的新设置app.config.
8. 关闭Settings.settings.

好的!现在我准备调试了!

在我看来,打开的rigamarole Settings.settings是,或者应该是不必要的:我不需要Settings.cs重新生成默认值,因为我不使用它们.但这是我知道的唯一方法,让VS知道app.config文件已更改的事实,以便构建将其复制到输出目录.

必须有一种更简单的方法来做到这一点.它是什么？

Answer 1

您还可以让Visual Studio通过以下方式自动化Robert的方法:

1. 为每个客户端定义构建配置
2. 在post build事件中,只需将xcopy app.config.xxx添加到bin文件夹即可.其中XXX是VS中可访问的Build Config的名称.类似于:xcopy app.config.$(ConfigurationName)$(OutDir)/app.config

VS将在单独的文件夹中为您的客户端删除不同的版本,并使用正确的配置文件.bin/Client1/bin/Client2 /

Answer 2

有几个人建议使用多个 VS 配置，我认为这会起作用，只不过每次在配置之间切换时都需要我重新构建解决方案。

相反，我在做的时候看起来有点愚蠢，但我已经使用它近一年了，而且运行得非常顺利。app.config.XXX直接在我的项目中，我为每个客户创建一个单独的文件。实际app.config文件仅用于生成Settings.cs- 它具有所有正确的设置名称及其默认值。它永远不会被复制到构建目录。

然后我编写了一个小程序，让我选择一个客户，然后简单地浏览每个项目的目录，如果我选择客户 XXX，则复制app.config.XXX到bin\debug\myprogram.exe.config和bin\release\myprogram.exe.config。只要这个程序知道解决方案的根源在哪里（每当我分支代码时我都必须小心一点），它就像一个魅力。