15

I upgraded a netcore1.1 project to the new VS2017/csproj.

In my test projects only, it added:

<PropertyGroup>
  <GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles>
</PropertyGroup>

I did some digging to discover that it generates these files in the bin directory:

  • ProjectName.Tests.runtimeconfig.json
  • ProjectName.Tests.runtimeconfig.dev.json

What is this setting and these files, and why do I need them?

Why were they only generated for my test projects?

grokky
  • 8,537
  • 20
  • 62
  • 96

1 Answers1

15

These are specific to .NET Core projects and specify

  • Which runtime and version to use. Typically Microsoft.NETCore.App. The "host framework resolver" looks for a matching folder inside the shared folder (e.g. C:\Program Files\dotnet\shared\Microsoft.NETCore.App\1.1.2). This is important since multiple runtimes can be installed side-by-side and the host needs to know which one to use when you run dotnet myapp.dll.
  • Additional options for the runtime. The most prominent is probably the garbage collection setting that switches between "desktop" and "server" mode. When you set <ServerGarbageCollection>true</ServerGarbageCollection> int he csproj file, this will cause a value in the runtimeconfig.json to be set. (This property is defaulted to true for web projects)
  • Additional options for the host. additionalProbingPath for example is set to your local NuGet cache which contains the restored packages. You may have noticed that referencing a NuGet package does not cause its dll files to be copied to the output directory (by default). The host uses the additional probing path to look for packages / dlls referenced to in this location (actually it is a two-step lookup: deps.json tells the host which packages to use and this property tells where to look for this package). Since this is only used for development and shouldn't end up in the published output (since this would mean relying on a NuGet cache on the target), this settings is put into a runtimeconfig.dev.json.

"Classic" .NET Framework projects also had a concept of letting the application set some runtime settings. This was accomplished by having an .exe.config file (which would be built from an App.config file in a project if present). You can think of runtimeconfig.json as "the new .exe.config" but the only have a few overlapping concerns.

Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217
  • Is it okay that some of my projects have it and some don't? From your answer it seems that this is an important setting that should always be set? (Strangely though, I've never used it before and never had problems?) – grokky May 25 '17 at 10:10
  • These files are specific to .NET Core projects. – Martin Ullrich May 25 '17 at 10:15
  • 5
    The runtimeconfig files need to be generated for any project that is "runnable". By default, an EXE project is "runnable", so the GenerateRuntimeConfigurationFiles property is defaulted to `true` when you have `OutputType=Exe`. However, for test projects there is no `OutputType=Test` property to know that this is a test project. But test projects are "runnable", so they need runtimeconfig files generated. So the migration tool sets this property on test projects so they get generated. – Eric Erhardt May 25 '17 at 21:14
  • @EricErhardt That is good info, probably should be a separate answer... I deleted all those properties, but all my tests still work. Strange? – grokky May 27 '17 at 09:45
  • Also the dotnet cli xunit template doesn't include it – Jaanus Varus Jul 06 '17 at 08:52