.NET Framework Run-time Settings

.NET Framework applications can use "app.config" / "web.config" files to set various run-time settings. The performance related settings described below are particularly relevant to actionETL applications, see Configuring Apps by using Configuration Files for background details.

"app.config" and "web.config"

Windows command line/service/GUI applications use an "app.config" XML file to store the settings. When the application is compiled, the file is renamed to "MyApplication.exe.config", and resides in the same folder as the executable.

For web applications, the original configuration file is instead called "web.config".

Optimizing Memory Allocation

By default, .NET memory allocations are tuned for interactive applications where low latency (i.e. milliseconds) is desirable. actionETL programs that don't have a user interface or other low latency requirements are instead batch applications, and will (if they have high volume dataflows) almost always run quicker and consume fewer CPU resources by configuring the .NET garbage collector to work in server mode and in the foreground (non-concurrent). This is the recommended default configuration for all actionETL batch applications.

Configure this by adding the following gcServer and gcConcurrent settings to the *.config file:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.2" />
  </startup>
  <runtime>
    <gcConcurrent enabled="false"/>
    <gcServer enabled="true"/>
  </runtime>
</configuration>

One rarely significant but possible drawback is that the application can in some cases consume somewhat more memory, see Workstation and server garbage collection for in-depth information.

Again rarely significant, but if you are running at least .NET 4.6.2, you can further fine tune the memory allocation for multiple simultaneous workloads, see Middle Ground between Server and Workstation GC for details.

Connection Strings

AConfig Configuration Facility is the most common (and less verbose) way of storing connection strings (and other user settings).

On .NET Framework, you can however also store connection strings in "app.config" and "web.config", which can be useful e.g. when sharing connections strings with other applications that use these files. Here is an "app.config" example:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <connectionStrings>
    <add name="MySqlClientTester"
        providerName="MySql.Data.MySqlClient"
        connectionString="Server=test01;Database=MyDatabase;Uid=MyLogin;Pwd=MyPassword" />
    <add name="SqlClientTester"
         providerName="Microsoft.Data.SqlClient"
         connectionString="Trusted_Connection=true;Encrypt=true;TrustServerCertificate=true;database=MyDatabase;server=(local)" />
  </connectionStrings>
</configuration>

The application can then easily use the connection string when creating connection builders etc., using "*FromAppConfig" methods on AdbProvider:

// using actionETL;
// using actionETL.Adb;
// using actionETL.Adb.SqlClientExternal;
// using System.Configuration;

new WorkerSystem()
.Root(root =>
{
    var connectionBuilder = AdbSqlClientProvider.Get()
        .CreateConnectionBuilderFromAppConfig("SqlServer");

    // ...
})
.Start()
.ThrowOnFailure();
Note
  • Retrieving the providerName value is not needed, since that is inherent in and available from the AdbProvider instance used.
  • Using integrated security (see the "SqlClientTester" connection above) is almost always preferable over storing passwords in the file. If the latter is unavoidable, do pay particular attention to file permissions, and also consider encrypting the sensitive information, e.g. via Encrypting Configuration Information Using Protected Configuration (aimed at web applications, but also works for other project types).

See Also