configuration transforms in service fabric?

Question

When you create an empty Service Fabric application through Visual Studio, the project template will automatically create different configuration files for you such as Node1.XML, Node5.XML, etc.

We are much less concerned with the number of nodes than with which environment we are targeting.

Is it contrary to Service Fabric recommendations to have simply 1 configuration file and create transforms from it?

For example we might have something like this:

<?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>

As part of our build process, we would like to be able to set the configuration (Debug/Release) and based on this, the configuration would be changed. Is it possible to achieve this, or would it be contrary to the SF philosophy?

Another configuration example would be this:

<?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>

How would we maintain values for for different environments for the above parameters? Are separate files the way to go, or can we do config transforms and then target different build configurations?

Answer 1

Is it contrary to Service Fabric recommendations to have simply 1 configuration file and create transforms from it?

I'm not aware. If it works for you and your team is happy then that is all that matters. On a slightly different note, I applied App Config transforms to a WPF app (which wasn't a policy and wasn't technically achieveable by default) by a 3rd party tool called SlowCheetah and it worked rather well.

As part of our build process, we would like to be able to set the configuration (Debug/Release) and based on this, the configuration would be changed. Is it possible to achieve this, or would it be contrary to the SF philosophy?

Give SlowCheetah a try. To be honest I have not tried it with Service Fabric.

Scott Hanselman:

Folks want to transform their app.configs, or any XML file as part of their builds Tell me more

OP:

How would we maintain values for for different environments for the above parameters? Are separate files the way to go, or can we do config transforms and then target different build configurations?

Configuration Transforms (CT) are a bit of hotly-debated topic.

Whilst I see no problem using CT for dev machines and say test environments, I would advise not to use them for Production .

The reasoning is is that they are the product of a build process and not a static artifact managed by SCM .

"But Micky" , I hear you say, "EXEs and DLLs are the product of a build process" .

True. But there is no alternative to binaries which are the result of compilation of source code. You generally don't "compile" configuration files in the broadest terms in .NET, specifically IIS; WCF and even Service Fabric it is not mandatory.

When part of a build process, should you need a copy of the configuration for the current version in Production, or say for one of your customer's sites from two builds ago, you need to run the build process again in order to obtain the produced file.

The problem with this are:

1. The build process may take considerable time
2. There is zero guarentee that the produced file exactly matches the historical version
3. Such transformed files are at the mercy of the transform tool , can you prove that future versions of the tool won't fault or mangle your file?

My advice is to manually maintain configuation files for all your production nodes