我有一个场景,需要在我的应用程序的web.config文件中更改数据库/连接字符串,具体取决于应用程序当前所在的位置。也就是说,我的Dev Web服务器应该连接到我的Dev数据库。这同样适用于我的测试和生产环境。通过一些研究,似乎web.config transformations正是我所寻找的,但有一个潜在的问题。
我工作的公司使用自制方法来部署生产应用程序。它的作用是将文件(用户选择或计算的差异)从测试环境复制到Prod环境。使用web.config转换仍然有效吗?
如果我要部署到Test,然后使用我们的工具“部署”到Prod,web.config文件的测试版本将被复制到右边?这假设在构建期间应用了转换。
我想可以将Prod版本部署到Test,然后在Prod部署之后用适当的版本替换它,但这看起来很混乱。我在改造的方式上有误吗?什么是这个奇怪问题的聪明解决方案?
答案 0 :(得分:3)
使用web.config转换是否仍然有效?
不,在Visual Studio或MSBuild中使用“发布”功能时会执行转换。在给定环境中部署应用程序的预编译版本(假设您使用了发布功能)后,其他转换将丢失,并且不会部署到此环境中。因此,如果您使用一些自制工具从TEST复制到LIVE,您将无法利用这些转换。为此,您需要使用LIVE环境重新发布应用程序。
答案 1 :(得分:0)
@Jeff - 我一直在处理相同的情况,我们的问题是我们不想在每次从一个环境迁移到另一个环境时重新编译应用程序。这是Web转换的一个问题(重新编译代码!)。
我们打包了基本web.config以及MSI中的转换文件。所以我们打包了web.config,web.config.DEV,web.config.Prod等。然后在安装MSI之后,我更新了我们古老的部署脚本,以调用在PROD服务器上进行转换的MSBUILD脚本。
我的powershell脚本首先会找到以当前环境名称(.DEV,.PROD等)结尾的所有配置文件。然后它会找到默认文件,如果是web.config.dev,它会尝试查找web.config。在此之后,它会将这些参数传递给MSBUILD并进行转换。转换后,输出将保存在默认位置,稍后将复制回原始位置。
<UsingTask TaskName="TransformXml"
AssemblyFile="Microsoft.Web.Publishing.Tasks.dll"/>
<PropertyGroup>
<FilePath></FilePath>
<ConfigFileName></ConfigFileName>
<TransformFileName></TransformFileName>
<OutputFileName></OutputFileName>
<StackTraceEnabled>False</StackTraceEnabled>
</PropertyGroup>
<Target Name="Transform">
<Message Text="FilePath = $(FilePath)" />
<Message Text="ConfigFileName = $(ConfigFileName)" />
<Message Text="TransformFileName = $(TransformFileName)" />
<Message Text="OutputFileName = $(OutputFileName)" />
<TransformXml Source="$(FilePath)$(ConfigFileName)"
Transform="$(FilePath)$(TransformFileName)"
Destination="$(OutputFileName)"
StackTrace="$(StackTraceEnabled)" />
</Target>