Add msbuild task to generate binary runtimeconfig format

[fanyang-mono]

Fixes #49235

[ghost]

Tagging subscribers to this area: @CoffeeFlux
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #49235

Author:	fanyang-mono
Assignees:	-
Labels:	area-AssemblyLoader-mono
Milestone:	-

[ViktorHofer]

What is this for? The runtimeconfig.json file is created by a task in the SDK, why would we do this here in dotnet/runtime?

[ViktorHofer]

What is this for? The runtimeconfig.json file is created by a task in the SDK, why would we do this here in dotnet/runtime?

[fanyang-mono]

What is this for? The runtimeconfig.json file is created by a task in the SDK, why would we do this here in dotnet/runtime?

This is needed for mobile targets to honor the settings from runtimeconfig.json file.

[CoffeeFlux]

Viktor this is for the mobile products, where we don't want to embed a json parser and pay the associated startup cost. The idea is to generate a file at publish time that is embedded in the APK and Mono can parse in easily. It should be transparent to users; they can just edit the json in their product like normal.

[jkotas]

The runtimeconfig.json file is created by a task in the SDK, why would we do this here in dotnet/runtime?

This is in the same category as other tasks under src\tasks. These tasks contain parts of mobile publishing pipeline logic that is tightly coupled with the runtime.

It is a valid question to ask whether all these tasks should live in SDK instead. If these tasks were in SDK, updating them would be much more painful. We are actually on that plan with crossgen task and it is pain to coordinate the updates. I think we may want to look into having the crossgen task on the same plan as these mobile tasks so that it easier to update (cc @dotnet/crossgen-contrib).

[ViktorHofer]

It is a valid question to ask whether all these tasks should live in SDK instead. If these tasks were in SDK, updating them would be much more painful.

Absolutely agree in regards to crossgen2 and even the linker. What about keeping the msbuild files (targets, tasks) for crossgen2 and the mobile tasks in dotnet/runtime and letting dotnet/sdk consume them (the same way the sdk consumes the linker package and its props/targets) so that they are sequenced into the SDK but live next to the component's sources?

In the example of linker:

1. Bundle props, targets and tasks as an msbuild sdk package: https://github.com/mono/linker/blob/main/src/ILLink.Tasks/. ILLink.Tasks is a nuget sdk package which contains props, targets and tasks. For linker most of the targets code still lives in dotnet/sdk but presumably that could be moved back into mono/linker. cc @sbomer
2. Consume that sdk package in dotnet/sdk via the msbuild sdk resolver: https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ILLink.props#L14. Note that this doesn't mean that the package is consumed via nuget. It is automagically added into the sdk folder (dotnet/sdk's GenerateLayout handles that).

[sbomer]

Agreed that this would make it much less painful to iterate on the build logic. The linker targets were moved to the SDK in the first place because:

• They depended details of the publish logic that kept changing in the SDK and breaking the linker setup. Now that the SDK explicitly depends on ILLink at a specific place, this may be more stable.
• The SDK had better testing infra for the end-to-end msbuild logic. I still think it's desirable to have tests for the MSBuild targets live in the same place as the targets.

Based on this, we decided at the time that the task would live in the linker repo, while most of the props/targets (the ones with actual logic, not just imports) would live in the sdk, but it has meant that updates to both needed to be done in multiple steps.

[fanyang-mono]

Lane https://github.com/dotnet/runtime/issues/42677 failed, due to the know issue #42677