Question

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

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

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

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

<?xml version="1.0" encoding="utf-8"?>
<PublishProfile xmlns="http://schemas.microsoft.com/2015/05/fabrictools">
  <!-- 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: <ClusterConnectionParameters ConnectionEndpoint="mycluster.westus.cloudapp.azure.com:19000" />

       Example showing parameters for a cluster that uses certificate security:
       <ClusterConnectionParameters ConnectionEndpoint="mycluster.westus.cloudapp.azure.com:19000"
                                    X509Credential="true"
                                    ServerCertThumbprint="0123456789012345678901234567890123456789"
                                    FindType="FindByThumbprint"
                                    FindValue="9876543210987654321098765432109876543210"
                                    StoreLocation="CurrentUser"
                                    StoreName="My" />

       Example showing parameters for a cluster that uses Azure Active Directory (AAD) security:
       <ClusterConnectionParameters ConnectionEndpoint="mycluster.westus.cloudapp.azure.com:19000"
                                    AzureActiveDirectory="true"
                                    ServerCertThumbprint="0123456789012345678901234567890123456789" />
  -->
  <ClusterConnectionParameters ConnectionEndpoint="dzimchuk.westeurope.cloudapp.azure.com:19000" AzureActiveDirectory="true" ServerCertThumbprint="F52285B5F344C8D3C0B7ADDE0B421F08CF38CB1A" />
  <ApplicationParameterFile Path="..\ApplicationParameters\Cloud.xml" />
  <UpgradeDeployment Mode="Monitored" Enabled="true">
    <Parameters FailureAction="Rollback" Force="True" />
  </UpgradeDeployment>
</PublishProfile>

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

另一个配置示例是：

<?xml version="1.0" encoding="utf-8" ?>
<Settings xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2011/01/fabric">

  <Section Name="Logging">
    <Parameter Name="IncludeScopes" Value="false" />
    <Parameter Name="LogLevel:Default" Value="Debug" />
    <Parameter Name="LogLevel:System" Value="Information" />
    <Parameter Name="LogLevel:Microsoft" Value="Information" />
  </Section>

  <Section Name="Authentication">
    <Parameter Name="AzureAd:B2C:Instance" Value="e.g https://login.microsoftonline.com/" />
    <Parameter Name="AzureAd:B2C:TenantId" Value="B2C tenant ID" />
    <Parameter Name="AzureAd:B2C:Audience" Value="B2C Application ID" />
    <Parameter Name="AzureAd:B2C:Policy" Value="" />
  </Section>

  <Section Name="ApplicationInsights">
    <Parameter Name="InstrumentationKey" Value="" />
  </Section>

  <Section Name="Redis">
    <Parameter Name="Configuration" Value="" />
    <Parameter Name="InstanceName" Value="BookFast.Booking_" />
  </Section>

  <Section Name="FacilityApi">
    <Parameter Name="ServiceUri" Value="fabric:/BookFast/FacilityService" />
    <Parameter Name="ServiceApiResource" Value="" />
  </Section>

  <Section Name="Test">
    <Parameter Name="FailRandom" Value="false" />
  </Section>

</Settings>

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

Answer 1

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

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

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

尝试一下SlowCheetah。说实话，我没有尝试使用Service Fabric。

Scott Hanselman：

人们想要将他们的app.configs或任何XML文件转换为他们的构建Tell me more
的一部分

OP：

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

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

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

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

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

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

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

问题在于：

构建过程可能需要相当长的时间
保证生成的文件完全匹配历史版本
此类转换后的文件受转换工具的支配，您是否可以证明该工具的未来版本不会出错或损坏您的文件？

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

服务结构中的配置转换？

1 个答案: