维护的web.config文件 [英] maintaining web.config files

问题描述

我想知道别人如何保持自己的web.config文件中部署应​​用程序。 （假设没有自动部署机制 - 即出这个问题的范围）

I'm interested to know how others maintain their web.config files for deployed applications. (assuming no automated deployment mechanism - that is out of the scope of this question)

所以在开发过程中，一些开发商可能会利用web.config文件转换，构建/发布他们的项目（调试/发布，测试/现场配置），然后部署所有已出版的文物到Web服务器，并设置IIS。一些开发商可能会建立/发布他们的项目，部署文物出版到Web服务器，IIS设置，然后手动更新web.configs的特定环境（测试/现场等），他们正在部署之中。

So during development, some developers might make use of web.config transformations, build/publish their projects (debug/release, test/live configurations), then deploy all published artifacts to a web server and set up IIS. Some developers might build/publish their projects, deploy published artifacts to a web server, set up IIS, then manually update the web.configs for the specific environment (test/live, etc) they are deploying into.

在inital部署完成，该应用程序在生产中（无论是在现场还是在测试环境下），你怎么去维护的web.config文件，随着时间的推移，如果说一个数据库连接字符串或应用程序的设置主要需要改变？

Once inital deployment is done and the application is in production (either in a live or a test environment), how do you go about maintaining web.config files over time if say a database connection string or an app settings key needs changing?

你使用的web.config变换，使VS更改重新发布应用程序，那么整个应用程序，或者只是新的web.config文件复制到服务器？

Do you utilize web.config transforms, make your changes in VS re-publish the application, then copy the entire app or maybe just the new web.config to the server?

你只是手动更改的web.config文件在服务器上？

Do you just manually make changes the web.config on the server?

你的版本控制源代码控制在web.config中的变化，如果像连接字符串，应用程序键等（没有结构）变化？

Do you version control the web.config changes in source control if things like connection strings, app keys etc (not structure) change?

我想知道别人是怎么接近这一点。

I'm interested to know how others are approaching this.

目前，我们修改生产中的web.config文件。当我们实现新功能或错误修复，我们的版本控制这些变化，以及任何更改web.config中，如新的应用程序键等等。如果我们要部署应用程序，我们将备份的当前版本对生产的新版本服务器，删除所有文件例外配置文件，然​​后复制新版本没有配置文件复制到生产服务器，保留现有的配置。然后手动比较现有的配置，一个我们在源代码控制来解释变化的模式。

Currently we make changes to the web.config in production. As we implement new features or bug fixes, we version control those changes, and any changes to the web.config such as new app keys etc. If we have to deploy a new version of the application we will backup the current version on the production server, delete all files exception configuration files, then copy the new version without the config files to the production server, retaining the existing configuration. Then manually compare the existing configuration to the one we have in source control to account for changes in schema.

我们正在looing的修改，是因为我们希望有一个过程，是可再现，而且不容易出现人为错误。我不相信该解决方案是100％的web.config变换。即使您使用转换，它似乎仍然是有在部署需要进行一些人为干预，因为在制作配置文件可能是一个价值可能已经改变，没有在源头上控制了更新。如何为别人解决这个？

We're looing at revising this because we want a procedure that is reproducable, and not vulnerable to human error. I'm not convinced that the solution is 100% web.config transforms. Even if you use transforms, it still seems that there is some human intervention required in the deployment because potentially a value in the production config file could have changed and not have been updated in the source control. How are others tackling this?

推荐答案

我们使用的 web.config文件转换的与VS 2010

We use web.config transformations with VS 2010.

您可以指定一个主web.config文件，并使用变换来操纵它针对不同的环境（即更改数据库连接字符串）。当您部署/发布您的项目（S）这些转换会自动呈现。

You can specify one primary web.config file and use transforms to manipulate it for different environments (i.e. changing database connection strings). These transforms are automatically rendered when you deploy/publish your project(s).

这也取决于需要部署什么类型的变化。虽然通常情况下，我们的部署设置是只替换已更新的文件。因此，如果我们所有改变是web.config.production转变，那么这就是所有的已部署。

It also depends on what type of change needs to be deployed. Although typically, our deployment setting is to only replace files that have been updated. So if all we changed was the web.config.production transformation, then that's all that's deployed.

是的，我们把所有的web.config文件及其变换源代码控制之下，因为它们是依赖于它们的应用程序的一部分。

And yes, we do keep all web.config files and their transformations under source control as they are part of applications that rely on them.

还有，我们开到其他球队/开发者，但不允许他们改变web.config中的设置，以便它们的部署/发布设置跳过web.config文件中某些环境。虽然作为一般规则，我们不碰文件从服务器直接上。我们总是在本地更新文件，这样的改变可以通过源代码控制跟踪和正确部署。

There are also certain environments which we open to other teams/developers but don't allow them to change web.config settings so their deployment/publish settings skip the web.config file. Although as a general rule, we don't touch files out on the server directly. We always update files locally so that changes can be tracked via source control and deployed properly.

这篇关于维护的web.config文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！