多个环境中的 Azure 云服务项目配置（.csdef 和 .cscfg）

目前我们有一个开发云服务（acme-dev-service）和一个生产云服务（acme-prod-service）。我们解决方案中当前的设置有一个名为 acme.application 的云服务项目，它使用 .cscfg 和 .csdef 文件的转换来将项目部署到两个环境（生产和开发）。我不喜欢这种转换方法，因为它对我来说有点像黑客。因此，经过一些研究后，您似乎可以拥有多个配置文件来解决一些问题，但我遇到了问题，因为只允许您使用一个服务定义。这对我们不起作用，因为生产环境需要额外的证书以及与我们的开发环境不同的 hostHeader 绑定。

所以看来我们真的无法摆脱使用转换。所以我想我的问题归结为我是否以错误的眼光看待Azure服务项目文件？我们真的应该将一个 Azure 项目映射到一项 Azure 云服务吗？我应该有一个用于生产的 Azure 项目和另一个用于开发的 Azure 项目吗？ 有一个更好的方法吗？或者在 Azure 中使用多个环境的最佳实践？

CSDefinition 文件是这里真正的关键。如果您有一个值需要在两个环境（开发/测试/阶段/生产等）之间有所不同，那么您实际上有三个选择：

1）部署前手动修改该值。呃……好吧……你有两个选择。

1) 进入 MS 构建过程并确定您选择的云配置（用于确定将使用哪个版本的 .cscfg 文件），然后让构建在构建之后和打包之前修改 .csdef（有时，文件在打包之前已被复制到不同的目录，这就是您要进行更改的位置）。这可能很棘手，尽管我已经看到过它的完成，甚至我自己在早期的 SDK 时代也这样做过。这是一篇博客文章，解释了他使用 WebConfigTransformRunner 来做到这一点的一个示例：http://fabriccontroller.net/blog/posts/apply-xdt-transforms-to-your-servicedefinition-csdef-file/ http://fabriccontroller.net/blog/posts/apply-xdt-transforms-to-your-servicedefinition-csdef-file/。我真的不认为这是你最好的选择，因为它是不透明的。目前还不清楚发生了什么，在你之后维护代码的人不会知道这个小宝石，并且会花很长时间试图弄清楚为什么他们放入 csdef 某处的某些值在发布到之后会以某种方式被覆盖不同的环境。

2）使用您提到的两种Azure Project方法。你可以在所选的构建工具中设置构建定义，以确定要构建和发布的 Azure 项目。我个人认为这是处理不同 .csdef 文件的最佳方法。它很简单，不需要修改 csproj 文件。我并不反对更改 csproj 文件，只是它的完成并不太明显，而且作为继承了此类事情的人来说，很难发现人们何时做这种事情，而且他们也不会告诉他们你关于它。