服务结构中的配置转换？

当您通过Visual Studio创建一个空的Service Fabric应用程序时，项目模板将自动为您创建不同的配置文件，如Node1.XML，Node5.XML等。

我们更少关注节点数量而不是我们所针对的环境。

只有1个配置文件并从中创建转换，与Service Fabric建议相反吗？

例如，我们可能会有这样的事情：

  <!-- ClusterConnectionParameters allows you to specify the PowerShell parameters to use when connecting to the Service Fabric cluster. Valid parameters are any that are accepted by the Connect-ServiceFabricCluster cmdlet. For a remote cluster, you would need to specify the appropriate parameters for that specific cluster. For example:  Example showing parameters for a cluster that uses certificate security:  Example showing parameters for a cluster that uses Azure Active Directory (AAD) security:  -->       

作为构建过程的一部分，我们希望能够设置配置（调试/发布），并在此基础上更改配置。 是否有可能实现这一目标，还是会违背SF理念？

另一个配置示例是：

对于上述参数，我们如何维护不同环境的值？ 单独的文件是可行的，还是我们可以进行配置转换然后定位不同的构建配置？

Answer 1

只有1个配置文件并从中创建转换，与Service Fabric建议相反吗？

我不知道。 如果它适合您，您的团队很高兴那么这就是最重要的。 稍微不同的是，我通过名为SlowCheetah的第三方工具将App Config转换应用于WPF应用程序（这不是策略，默认情况下在技术上无法实现），并且它运行得相当好。

作为构建过程的一部分，我们希望能够设置配置（调试/发布），并在此基础上更改配置。 是否有可能实现这一目标，还是会违背SF理念？

试试SlowCheetah吧。 说实话，我还没有尝试使用Service Fabric。

Scott Hanselman：

人们想要将他们的app.configs或任何XML文件转换为他们构建的一部分告诉我更多

OP：

对于上述参数，我们如何维护不同环境的值？ 单独的文件是可行的，还是我们可以进行配置转换然后定位不同的构建配置？

配置变换 （CT）是一个备受争议的话题。

虽然我发现使用CT开发机器并说测试环境没有问题，但我建议不要将它们用于生产 。

原因是它们是构建过程的产物，而不是SCM管理的静态工件 。

“但Micky” ，我听到你说， “EXE和DLL是构建过程的产物” 。

真正。 但是，除了源代码编译结果的二进制文件之外别无选择。 您通常不会在.NET中以最广泛的术语“编译”配置文件，特别是IIS; WCF甚至Service Fabric都不是强制性的。

在构建过程的一部分时，如果您需要生产中当前版本的配置副本，或者需要从两个版本之前的某个客户站点中获取，则需要再次运行构建过程以获取生成的文件。

这个问题是：

1. 构建过程可能需要相当长的时间
2. 没有保证生成的文件与历史版本完全匹配
3. 这些转换后的文件受转换工具的支配 ，你能certificate该工具的未来版本不会出错或破坏你的文件吗？

我的建议是手动维护所有生产节点的配置文件