服務結構中的配置轉換？

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文件轉換為他們構建的一部分告訴我更多

OP：

對於上述參數，我們如何維護不同環境的值？ 單獨的文件是可行的，還是我們可以進行配置轉換然后定位不同的構建配置？

配置變換 （CT）是一個備受爭議的話題。

雖然我發現使用CT開發機器並說測試環境沒有問題，但我建議不要將它們用於生產 。

原因是它們是構建過程的產物，而不是SCM管理的靜態工件 。

“但Micky” ，我聽到你說， “EXE和DLL是構建過程的產物” 。

真正。 但是除了源代碼編譯結果的二進制文件之外別無選擇。 您通常不會在.NET中以最廣泛的術語“編譯”配置文件，特別是IIS; WCF甚至Service Fabric都不是強制性的。

在構建過程的一部分時，如果您需要生產中當前版本的配置副本，或者對於兩個版本之前的某個客戶站點，則需要再次運行構建過程以獲取生成的文件。

這個問題是：

1. 構建過程可能需要相當長的時間
2. 沒有保證生成的文件與歷史版本完全匹配
3. 這些轉換后的文件受轉換工具的支配 ，你能證明該工具的未來版本不會出錯或破壞你的文件嗎？

我的建議是手動維護所有生產節點的配置文件