Stop adding a runtimeconfig.dev.json by default on built apps

[mateoatr]

Probing consumes a significant ammount of time at startup in the host. With changes introduced in dotnet/runtime#50671, we move away from expensive file-accessing calls made by the host's probing logic and make them conditional upon whether any additional probing paths were passed to hostpolicy. This improves performance of any dotnet ... command as well as the time to main.

Note that by default the SDK generates a <app>runtimeconfig.dev.json when building an app, which ends up adding additional probing paths which are not necessary (all dependencies are included in the app folder which is probed first, related: #15210) -- causing the host to probe more than necessary and missing on any performance gains achieved by the above PR.

/cc @vitek-karas @brianrob

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[vitek-karas]

@dsplaisted @wli3 What do you think?

The intent is to introduce a new MSBuild property which would be off by default and which would determine if the .runtimeconfig.dev.json should be generated or not.

[dsplaisted]

Yes, I think we should turn of the runtimeconfig.dev.json by default. I think we still need it prior to 3.x where we wouldn't copy referenced NuGet DLLs to the output folder. Also we may still need it if we are using the runtime package store for this line: "C:\\Users\\daplaist\\.dotnet\\store\\|arch|\\|tfm|",

[vitek-karas]

@dsplaisted If I understand the "package store" correctly, that line is only needed if I used dotnet store locally and want to test my apps against it, right? We will not produce this into a published app ever. Also, there's no way to detect in the SDK today that the app will want to use package store, right?

The proposed changes should be for TFM .net6 and above only (the hosting changes will be there as well). I personally would not mind too much if using the package store locally would require modifying the csproj of the tested app, or manually adding the file there.

[dsplaisted]

@normj Do you know if the runtimeconfig.dev.json file is important for AWS lambda scenarios using the runtime package store?

[benvillalobos]

Sounds like we want to stop this from happening by default while having some flag if you need this to be generated.

[brianrob]

We also want to make sure that dotnet.runtimeconfig.dev.json doesn't get emitted. From a quick look at a binlog for the SDK build, it looks like fixing this issue and then consuming the new SDK should address this.

[benvillalobos]

Looks like it's already set to avoid creating the file if it's passed an empty ProjectRuntimeConfigDevFilePath.

GenerateRuntimeConfigurationFiles.cs

        protected override void ExecuteCore()
        {
            bool writeDevRuntimeConfig = !string.IsNullOrEmpty(RuntimeConfigDevPath);

Current thought is to add a condition to setting ProjectRuntimeConfigDevFilePath so that it fails to set that value unless the property is set.

The intent is to introduce a new MSBuild property which would be off by default and which would determine if the .runtimeconfig.dev.json should be generated or not.

The first time I read this, I understood it as "create the property in the msbuild repo", but after looking at this for a bit I don't agree with that assumption. This should be defined in the SDK repo under some sdk.props file right?

[benvillalobos]

*.runtimeconfig.dev.json is generated at the same time as *.runtimeconfig.json, presumably we want to keep the latter?

[vitek-karas]

The first time I read this, I understood it as "create the property in the msbuild repo", but after looking at this for a bit I don't agree with that assumption. This should be defined in the SDK repo under some sdk.props file right?

Sorry for the confusion. I'm using the term "MSBuild property" as a way to describe that we define a property name in our props/targets which users can set to change the behavior (to avoid confusion with .NET API property). I definitely think that this should be simply defined in the SDK. I personally would prefer a "boolean-like" property, to get back the current behavior (having to specify a path makes it a bit cumbersome).

We do need to keep .runtimeconfig.json - absolutely.