How to make `dotnet run` invoke an MSBuild target?

[jonathanpeppers]

Is your feature request related to a problem? Please describe.

In .NET 7, the ability to pass MSBuild properties was added to dotnet run.

Unfortunately, this does not work for .NET MAUI projects, as we actually need an MSBuild target to run in order to deploy and launch an application on a mobile device.

To get an idea of our implementation currently:

https://github.com/xamarin/xamarin-android/blob/0e4c29aabb2af023d3ff66f02d42c2b487575d85/src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.Application.targets#L15-L16

We set $(RunCommand) and $(RunArguments) to launch a new process that runs dotnet build -t:Run. At this point we don't know what MSBuild properties were passed to dotnet run, so we don't have a way to pass them along.

Describe the solution you'd like

If optional workloads could opt into a new setting like $(UseTargetForRun) (or choose a better name), it feels like the dotnet CLI should be able to invoke a Run target directly instead of using $(RunCommand) and $(RunArguments).

This would allow the MSBuild properties to pass through, and we aren't starting an unnecessary dotnet process.

Additional context

This is important for CLI scenarios for .NET MAUI.

[rolfbjarne]

See also #18436.

[marcpopMSFT]

The options are either to do as suggested which would result in msbuild launching the process or we could run an additional target that returns the Command and Arguments that others could depend on to trigger their own targets. CC @rainersigwald for an opinion on having msbuild launching the process and what impact there might be.

Hiding these behind a property makes sense to limit performance impact.

Moving to 8.0.1xx for now as we've gotten more requests for this.

[rainersigwald]

No objection to having MSBuild invoke the thing directly (that's what's happening in the current implementation anyway, just through an additional process).

[KalleOlaviNiemitalo]

Command & arguments seems a bit more extensible, in that the caller could run the command in a debugger or a syscall tracer, without needing each project to support those. Might need the ability for the project to specify environment variables for the process though.

[KalleOlaviNiemitalo]

In the command & arguments implementation, if the developer wants to run some MSBuild targets rather than a built executable, then they can return "dotnet msbuild $(MSBuildProjectFullPath) -t:sometarget" as the command & arguments. Although it's not clear to me how the arguments should be quoted then; are the arguments are going to be just one string, or each argument as an item?

[jonathanpeppers]

Didn’t know this one had meme potential:

[maddymontaquila]

This would really help both C#DK and MAUI in VS Code - simplifies quite a bit of the user experience if they choose to use CLI to build