When and why do I need the supportedRuntime element and sku attribute?

Question

In most (if not all) C# (and F# and VB) library and executable projects created in Visual Studio there is an automatically added app.config file that specifies runtime version and target framework moniker (TFM):

<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" />
. . .

Even absent the app.config file entirely, the compiler seems to always generate an assembly-level attribute, as ILDASM shows:

.custom instance void [mscorlib]System.Runtime.Versioning.TargetFrameworkAttribute::.ctor(string) = ( 01    // ....NETFramework
                                                                                                      ..    // ,Version=v4.6.1.
                                                                                      bytes snipped-> ..    // .T..FrameworkDis
                                                                                                      ..    // playName..NET Fr
                                                                                                      61  ) // amework 4.6.1

The .csproj file does specify the target frameworks, and my guess this is where the target is passed from on to the compiler during build.

The executable seems to run just fine without the <startup> section in the config file. The documentation explains what do the attributes mean, but, seeing them for many years, I never understood why they are needed in the configuration file. I mostly dealt with desktop applications for Windows, however.

This answer explicitly states that “making a program compiled to target .NET 4.0 behave like it runs on a higher version is not possible,” and I would be really surprised if, conversely, running a program on a lower version of the framework were also possible.

So, under what scenarios does the application developer need to specify the version and TFM of the runtime in the .config file of the application, and does it have to always duplicate information that is hardcoded into the binary by the compiler? The requirement seems counterintuitive at first sight.

---

UPDATE 2018-06-29: X-ref: I asked for a clarification of the documentation in the GitHub issue dotnet/docs#6234.

Answer 1

It's needed to declare which framework versions your application is actually compatible with. Suppose, we have an application that targets .NET Framework 4.7.2 and try to run it on the machine that have only .NET Framework 4.5 installed. If we add this app.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2"/></startup></configuration>

Windows will show a nice error message that asks to install needed framework version:

If we omit the app.config, Windows will try to run it and then application will crash first time it hits a feature specific to .NET Framework 4.7.2 and absent in installed framework version.

Note that documentation is misleading in saying that "This element should be used by all applications built with version 1.1 or later of the .NET Framework". It might be interpreted as "This element is required for application to run on .NET 1.1+", while in reality it only means that .NET 1.1 changed a syntax from previosly used in .NET 1.0 requiredRuntime syntax. More often then not supportedRuntime is NOT required for application to run, it's just for prettiness.

One common scenario when supportedRuntime is really needed for application to run is when we have application targeting .NET 2.x-3.x and try to run it on machine that have only 4.x (for example, Windows 10 have 4.6+ but does not have .NET 2.x-3.x installed by default). In this case, without supportedRuntime in app.config the application won't run at all, even though 4.x is mostly compatible with previous versions. Adding <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" /> will fix the issue.

---

So, to sum up, it does not duplicate the information in assembly metadata, but rather give Windows additional information on how to connect application with framework version it is compatible with, and what version to ask user to install if it's not present on target machine.