Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

How to make dotnet run invoke an MSBuild target? #31253

Closed
jonathanpeppers opened this issue Mar 16, 2023 · 13 comments · May be fixed by dotnet/android#9470
Closed

How to make dotnet run invoke an MSBuild target? #31253

jonathanpeppers opened this issue Mar 16, 2023 · 13 comments · May be fixed by dotnet/android#9470
Assignees
@baronfel
Labels
Area-CLI
Milestone
9.0.1xx

Comments

@jonathanpeppers
Copy link
Member

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.
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-CLI untriaged Request triage from a team member labels Mar 16, 2023
@rolfbjarne
Copy link
Member

See also #18436.

@baronfel baronfel added needs team triage Requires a full team discussion and removed untriaged Request triage from a team member labels Mar 17, 2023
@marcpopMSFT marcpopMSFT added this to the 8.0.1xx milestone Mar 22, 2023
@marcpopMSFT marcpopMSFT removed the needs team triage Requires a full team discussion label Mar 22, 2023
@marcpopMSFT
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor

KalleOlaviNiemitalo commented Mar 22, 2023 •
edited
Loading

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
Copy link
Contributor

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?

@baronfel baronfel mentioned this issue Jun 28, 2023
Closed
@jonathanpeppers
Copy link
Member Author

Didn’t know this one had meme potential:

image

@maddymontaquila maddymontaquila mentioned this issue Jul 13, 2023
Closed
@maddymontaquila
Copy link
Member

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

@marcpopMSFT marcpopMSFT modified the milestones: 8.0.1xx, 8.0.2xx Sep 15, 2023
@baronfel
Copy link
Member

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 baronfel self-assigned this Sep 28, 2023
@baronfel
Copy link
Member

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 baronfel mentioned this issue Sep 28, 2023
Closed
@baronfel
Copy link
Member

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
Copy link
Member

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
Copy link
Member

@javiercn

@baronfel baronfel modified the milestones: 8.0.2xx, 8.0.4xx May 29, 2024
@jonathanpeppers jonathanpeppers mentioned this issue Jul 15, 2024
Closed
@baronfel
Copy link
Member

Closing this as we implemented it in #42155!

@baronfel baronfel removed this from the 8.0.4xx milestone Sep 30, 2024
@baronfel baronfel added this to the 9.0.1xx milestone Sep 30, 2024
jonathanpeppers added a commit to dotnet/android that referenced this issue Oct 30, 2024
@jonathanpeppers
[Xamarin.Android.Build.Tasks] implement dotnet run with an MSBuild …
8836846 
…target

Context: dotnet/sdk#42155
Context: dotnet/sdk#42240
Fixes: dotnet/sdk#31253

The .NET SDK has introduced a new `ComputeRunArguments` MSBuild target
that allows you to set `$(RunCommand)` and `$(RunArguments)` in a more
dynamic way.

So, on Android:

* `ComputeRunArguments` depends on `Install`, so the app is deployed,
  the `<FastDeploy/>` MSBuild target runs, etc.

* `$(RunCommand)` is a path to `adb`

* `$(RunArguments)` is an `shell am start` command to launch the main
  activity.

The new implementation also allows us to use the `-p` parameter with
`dotnet run`, such as:

    dotnet run -bl -p:AdbTarget=-d

This will pass `-d` to `adb`, which allows you to select an attached
device if an emulator is running.

Previously, we had no way to pass `-p` arguments to `dotnet run`.
@jonathanpeppers jonathanpeppers mentioned this issue Oct 30, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@baronfel baronfel

Labels
Area-CLI
Projects
None yet
Milestone
9.0.1xx
Development

Successfully merging a pull request may close this issue.

[Xamarin.Android.Build.Tasks] implement dotnet run with an MSBuild target dotnet/android
8 participants
@rolfbjarne @baronfel @jonathanpeppers @danroth27 @rainersigwald @maddymontaquila @marcpopMSFT @KalleOlaviNiemitalo