因此，当我们开始Azure迁移时，我们将web.config设置迁移到Azure配置.cscfg文件。
虽然这很有效，并且在测试环境中非常有用，因为我可以快速破解配置，但这在生产中似乎相当危险......因为我可以快速破解配置。
更正式地说，这意味着任何有权访问Azure管理控制台的人都可以轻松地对生产Azure实例进行不受控制的更改。
这让我觉得非常糟糕。
实际上，除了标准诊断字符串配置之外，.cscfg文件背后是否存在任何实用程序，等等？
答案 0 :(得分：7)
我们喜欢测试中.cscfg文件的灵活性，我们不希望测试与生产的代码库略有不同，因为我们认为我们的测试环境应该是生产环境的精确复制品...减去一些配置差异。
与此同时，我们对一些开发人员意外删除错误的部署或更改错误的.cscfg文件/值感到妄想。为了解决这个问题，我们创建了两个订阅，一个用于测试，一个用于生产。我们为所有开发人员提供访问测试订阅的权限，但只有负责部署的人才能访问生产订阅。
部署工程师确切地知道他们在生产环境中能做什么和不能做什么（重新启动/重新映像实例，删除部署等）。他们知道生产中要触及的唯一.cscfg值是“Instances count”属性（我们的构建服务器设置所有其他生产.cscfg值）。
到目前为止，这种设置对我们来说非常有效。
答案 1 :(得分：0)
取决于您的安全＆amp;合规性政策，您可能希望拥有一个自定义应用设置解决方案来容纳Azure存储或SQL Azure中的所有应用设置...
没有额外的“推荐”，但是让应用程序设置可用于无需重新部署的更改非常有用......
为了便于在Visual Studio中的环境之间切换，请查看我最近发布的博客文章@ http://www.paraleap.com/blog/post/Managing-environments-in-a-distributed-Azure-or-other-cloud-based-NET-solution.aspx
答案 2 :(得分：0)
您仍然可以在Azure中使用web.config来获取您希望保持不可配置的配置。我们将两者结合起来......
在这种情况下不可配置，意味着您需要重新部署才能更改它们......
答案 3 :(得分：0)
只需限制对Azure管理控制台的访问权限，就可以真正使用整个问题。如果有多个人需要能够部署，您只需创建要使用的证书，而不是授予他们访问Azure管理控制台的权限。
实际上，当我们部署到生产环境时，我们的构建环境会重新配置配置文件。这基本上消除了进入管理UI的需要，并且配置总是一样。