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