Reason for runtimeconfig.dev.json in build output since .NET Core 3?

[vuplea]

An OutputType=Exe project build will create a runtimeconfig.dev.json which adds probing paths:

    "additionalProbingPaths": [
      "C:\\Users\\radu.oancea\\.dotnet\\store\\|arch|\\|tfm|",
      "C:\\Users\\radu.oancea\\.nuget\\packages"
    ]

Since all the dependencies should be near the AppHost, and the runtime probes in its directory first (e.g. I've used dotnet store first on my dependencies, but it still loaded them from the build folder), does runtimeconfig.dev.json have an effect?

[joeloff]

The configuration files isn't just for probing. It's intended to include other configuration options for your application. Probing paths are just one item that can be configured. The additional probing paths are likely a no-op.

Did you add an probing paths in your .csproj, e.g.

<AdditionalProbingPath Include="$(USERPROFILE)\.nuget\packages" />

[vuplea]

Thanks, @joeloff .
The above shown additionalProbingPaths are the default ones i.e. dotnet new console & dotnet build.

I wanted to make sure that the file has no effect by default.

• We do not plan to use CopyLocalLockFileAssemblies=false for developer builds as it had no discernible effect in build time when tested.
• We are planning to deploy build (not publish) output since it seems easier for us (at the moment 🌝). Deploying runtimeconfig.dev.json does not make sense so we will remove them though.
• We might even remove them post-build. If somehow (e.g. through a faulty PostBuild target we configure) we corrupt a developer build, it would be better to fail on missing assemblies in output.

For the SDK: maybe it would be better if additionalProbingPaths were empty by default?

[richlander]

From the .NET Core 3.0 blog post:

dotnet build now copies NuGet dependencies for your application from the NuGet cache to your build output folder during the build operation. Until this release,those dependencies were only copied as part of dotnet publish. This change allows you to xcopy your build output to different machines.

My understanding (which is also the rationale for the issue title) is that this product change significantly reduces or completely removes the need for this file. If that is the case, it would be great to no longer have it. We should have as few build artifacts as possible.

@vitek-karas?

[vitek-karas]

@richlander I completely agree - see #16818 - we're trying to remove it now.

[marcpopMSFT]

#17014