目前，我们拥有开发云服务（acme-dev-service）和生产云服务（acme-prod-service）。我们在解决方案中的当前设置有一个名为acme.application的云服务项目，该项目使用.cscfg和.csdef文件的转换，将项目部署到两个环境（生产和开发）。我不喜欢转换方法，因为它对我来说感觉有点像黑客。所以在做了一些研究之后，似乎你可以有多个配置文件来解决一些问题，但是我遇到了问题因为你只允许一个服务定义。这对我们不起作用，因为生产环境需要额外的证书以及与我们的开发环境不同的hostHeader绑定。
所以我们似乎无法摆脱使用转换。所以我想我的问题归结为我在错误的光线下查看Azure服务项目文件？我们真的应该将一个Azure项目映射到一个Azure云服务吗？我应该有一个用于生产的Azure项目和第二个用于开发的Azure项目吗？ 有一个更好的方法吗？或者是在Azure中使用多个环境的最佳实践？
CSDefinition文件是真正的踢球者。如果你有一个值，你需要在两个环境（开发/测试/阶段/生产等）之间有所不同，那么你真的有三个选择：
1）在部署之前手动修改该值。呃....好吧....你有两个选择。
1）点击MS Build过程并确定您选择了哪个云配置（用于确定将使用哪个版本的.cscfg文件）然后让构建在构建之后和打包之前修改.csdef（有一段时间，文件在打包之前被复制到另一个目录，这是您想要进行更改的地方）。这可能很棘手，虽然我已经看到它已经完成，甚至在早期的SDK时代也是如此。这是一篇博客文章，解释了他使用WebConfigTransformRunner执行此操作的一个示例： http://fabriccontroller.net/blog/posts/apply-xdt-transforms-to-your-servicedefinition-csdef-file/。我真的不认为这是你最好的选择，因为它是不透明的。现在发生的事情并不明显，而且在你维护代码之后出现的人不会知道这个小宝石，并会花费永远的努力去弄清楚为什么他们在某个地方放入csdef的某些价值在他们发布之后会以某种方式被覆盖不同的环境。
2）使用您提到的两种Azure Project方法。您可以在所选的构建工具中设置构建定义，以确定要构建和发布的Azure项目。我个人认为这是处理不同.csdef文件的最佳方式。它是直接的，不需要修改csproj文件。我并不反对csproj文件更改，它只是没有过于明显它已经完成，并且作为一个继承了这样的东西的人说话，当人们做那种事情并且他们无法告诉时，这并不容易找到你呢。
CSDefinition文件是真正的踢球者。如果你有一个值，你需要在两个环境（开发/测试/阶段/生产等）之间有所不同，那么你真的有三个选择：
1）在部署之前手动修改该值。呃....好吧....你有两个选择。
1）点击MS Build过程并确定您选择了哪个云配置（用于确定将使用哪个版本的.cscfg文件）然后让构建在构建之后和打包之前修改.csdef（有一段时间，文件在打包之前被复制到另一个目录，这是您想要进行更改的地方）。这可能很棘手，虽然我已经看到它已经完成，甚至在早期的SDK时代也是如此。这是一篇博客文章，解释了他使用WebConfigTransformRunner执行此操作的一个示例： http://fabriccontroller.net/blog/posts/apply-xdt-transforms-to-your-servicedefinition-csdef-file/。我真的不认为这是你最好的选择，因为它是不透明的。现在发生的事情并不明显，而且在你维护代码之后出现的人不会知道这个小宝石，并会花费永远的努力去弄清楚为什么他们在某个地方放入csdef的某些价值在他们发布之后会以某种方式被覆盖不同的环境。
2）使用您提到的两种Azure Project方法。您可以在所选的构建工具中设置构建定义，以确定要构建和发布的Azure项目。我个人认为这是处理不同.csdef文件的最佳方式。它是直接的，不需要修改csproj文件。我并不反对csproj文件更改，它只是没有过于明显它已经完成，并且作为一个继承了这样的东西的人说话，当人们做那种事情并且他们无法告诉时，这并不容易找到你呢。