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 https://github.com/dotnet/sdk/issues/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

[baronfel]

Additional use cases that came up during discussion with @danroth27 that we need to consider here:

• Blazor WASM
• Dev Server Proxy for current Web SDK projects
• SPA Proxy for the new SPA project esproj-based support

In all of these cases running a particular project also requires starting/coordinating some number of other projects/processes. MSBuild doesn't have great support for this kind of lifecycle management (correct me if I'm wrong @rainersigwald), so spawning these kind of daemonized processes could be complex to orchestrate - you can't just Exec task them in a Target because that Target won't complete.

So a full solution should cover:

• single-project scope allowing for executing/invoking some number of preliminary processes, or
• some pre-run target for the current project that must be run successfully in order for the RunCommand/RunArguments to be executed
• clean-up of any spawned processes when the running application is closed

Perhaps some kind of protocol is relevant here - the CLI could call some kind of target that would return MSBuild ITaskItems that described what processes to run, targets to run, etc, then the CLI could orchestrate

• spawning and tracking those processes,
• calling those prerequisite targets
• launching the current project
• cleaning up those spawned processes

[baronfel]

Alternatives here might be to go the route that Android-on-Rust has and make a separate .NET Tool that MAUI users might use that could do whatever orchestration you needed: dotnet maui run instead of dotnet run. That raises questions about how MAUI users would acquire that tool - we might need to investigate Workloads providing .NET Tools for example - but would free individual teams to satisfy whatever use cases they needed without being dependent on the core SDK. However, that could weaken the nice SDK-driven workflow that we've gotten users to buy into over the lifetime of .NET.

[baronfel]

Quick GitHub search query for folks that have overridden/actually used the Run target is here.

I'm broadly seeing two categories:

• Run targets that clean/rebuild/pack the project
• Run targets that build + push the build asset to some other location like Android/MAUI/etc are asking for here

[baronfel]

One other thing to consider - VS/VSCode/CLI also use Launch Profiles to impact how the application is run. Anything we do here might impact them and we need to take that into account.

[danroth27]

@javiercn

[baronfel]

Closing this as we implemented it in #42155!