|
|
1
4
我发现为每个环境提供几个配置文件效果很好。即:
然后,我使用web.config或app.config中的内置configSource属性链接到此的“主”版本,例如
然后,我将使用构建过程或部署过程将环境的正确配置复制到web.config所期望的名称。 每个环境都有明确的标签和控制,不需要杂乱的占位符。 |
|
|
2
2
一种方法是维护3个不同的配置文件,并在部署时通过MSBuild选择它们。
通过使用MSBuild任务,您可以重命名特定的配置文件并将其推送到适当的位置。 这仍然有点麻烦,但它还有一个额外的优势,那就是朝着 one step build . |
|
|
3
1
在Visual Studio的下一个版本中,这一特性已被宣布为一项新功能。 也许你可以在预构建脚本中完成它;根据configurationname env变量替换配置文件。 |
|
|
4
1
还有一种选择:切换到将应用程序配置存储在数据库中。我将类型值保存在数据库中,以便更集中地管理这些设置。然后,我的配置文件有一个专门用于config的连接字符串,它只有两个键:一个唯一的应用程序ID值和配置版本(即“dev”、“test”等)。然后,我只需将正确的配置文件部署到正确的环境中。 这可能不是你想要的;它是一种便于管理配置数据的替代方案。 |
|
|
5
1
我对冼的回答有一个问题,那就是如果你添加一个新的配置设置/端点,你必须记住在多个文件中执行。如果您忘记这样做,那么只有在部署到受影响的环境时才会发现(这并不好)。 相反,你可以有一个主配置,并在构建/部署时使用regex/xmlpoke(nant)/[你最喜欢的文本操纵器]来处理文件,为每个环境插入正确的值,将所有环境的设置保存在另一个文件中(但至关重要的是,所有环境都放在一起)。 然后你只需要维护一个配置文件和一个环境设置文件——我认为从长远来看,这会使维护更容易、更清晰。 |
|
|
6
0
我们使用几种不同的方法。 环境。MachineName.config(适用于用户)
#如果调试DEBUG.config #如果测试TEST.config #如果PROD PROD.config
不过,这可能会变得乏味。 |
|
|
user755806 · 从Rest服务返回JSON响应? 7 年前 |