我想使用适用于发布也适用于调试的 Web.config 转换。
当我发布 Web 应用程序时，Visual Studio 会根据我的当前构建配置自动转换 Web.config。当我开始调试时，如何告诉 Visual Studio 做同样的事情？在调试开始时，它只使用默认的 Web.config 而不进行转换。
任何想法？
问问题
90608 次
5 回答
98
于 2010-10-22T05:13:29.840 回答
36
安德鲁走在正确的道路上。当您使用此功能时，这里是它的设计使用方式。
web.config 这是开发人员应该在本地使用的配置文件。理想情况下，您应该将其标准化。例如，您可以将 localhost 用于数据库字符串，等等。您应该努力使其在开发机器上工作而无需更改。
web.debug.config 这是在您将应用程序发布到开发登台环境时应用的转换。这将对目标环境所需的 web.config 进行更改。
web.release.config 这是当您将应用程序发布到“生产”环境时应用的转换。显然，根据您的应用程序/团队，您必须小心使用密码。
转换您当前正在运行的 web.config 的问题是转换可以对 web.config 执行破坏性操作。例如，它可以删除属性、删除元素等。
于 2010-10-14T04:47:34.423 回答
28
您可以只使用“默认”web.config 作为您的开发/调试版本，然后 web.release.config 当然会继续作为发布版本，因为它的转换是在您发布时应用的。
于 2010-10-13T09:34:37.627 回答
18
在您的调试配置中，添加一个构建后步骤，并使用它来替换/转换您的web.config
于 2010-10-13T09:30:31.377 回答
13
虽然我同意最简单的方法通常是最好的，但我可以很容易地想象在一段时间内您希望将 IDE 连接到测试数据库而不是开发数据库的情况。尽管您可以在默认的 web.config 文件中指定开发连接字符串，但最好有一个 Web.Test.config 文件，这样当您将构建配置交换为“Test”时，您会自动获得新设置仍在您的 IDE 中。
历史上的替代方案是为另一组注释掉一组连接字符串，但这些新的配置转换带来了最终将赌注置于这种丑陋做法的核心的希望。尽管一个用于开发的默认文件和一个用于发布的转换可能在大部分时间都有效，但在我看来，添加一个构建后的步骤来转换 web.config 文件是更完整的答案。
于 2010-10-13T11:12:59.067 回答