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.

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

[One .NET] improve Install target performance in IDEs #5436

Closed
jonathanpeppers opened this issue Dec 17, 2020 · 1 comment
Closed

[One .NET] improve Install target performance in IDEs #5436

jonathanpeppers opened this issue Dec 17, 2020 · 1 comment
Assignees
Labels
Area: App+Library Build Issues when building Library projects or Application projects.
Milestone

Comments

@jonathanpeppers
Copy link
Member

jonathanpeppers commented Dec 17, 2020

.NET 6 needs an equivalent of: 76fb90e

This checks $(BuildingInsideVisualStudio) and skips several targets during SignAndroidPackage.

In .NET 6, the SignAndroidPackage target isn't used because dotnet build produces .apk files. So this shortcut doesn't work, we need an equivalent for Microsoft.Android.Sdk.BuildOrder.targets.

Currently testing .NET 6 with xamarin-android/master, I saw these times for an incremental build of "Hello World" inside VS Windows:

Build 0.890s
Install 0.683s

For comparison, I have seen a command-line build that runs both targets at once get the time:

> dotnet build -t:Run --no-restore
Time Elapsed 00:00:01.07

This was using %MSBUILDNOINPROCNODE%=1, as to replicate the in-memory MSBuild node in Visual Studio.

@jonathanpeppers jonathanpeppers added the Area: App+Library Build Issues when building Library projects or Application projects. label Dec 17, 2020
@jonathanpeppers jonathanpeppers added this to the One .NET milestone Dec 17, 2020
@jonathanpeppers jonathanpeppers self-assigned this Dec 17, 2020
@jonathanpeppers
Copy link
Member Author

I reviewed a .binlog inside the IDE, and this is actually not an issue.

The correct subset of targets are working in .NET 6:

SignAndroidPackageDependsOn = 
    BuildOnlySettings;
    _CreatePropertiesCache;
    ResolveReferences;
    PrepareResources;
    CreateSatelliteAssemblies;
    _CopyPackage;
    _Sign;

jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Jan 29, 2021
Related: dotnet#5436

In "legacy" Xamarin.Android, we have the following behavior:

1. The `Build` target does not produce an `.apk` or sign it.
2. Only `SignAndroidPackage` (or `Install`) would do this.

So if you hit F6, Ctrl+B, Command+B, etc. in Visual Studio, you don't
have to wait on a valid `.apk` file to be produced to get build
results. This is useful for incremental build performance -- and
developers' habit of hitting build all the time.

`dotnet build` has different behavior, because it should inherently
produce something that is runnable. `dotnet build` currently produces
an `.apk` file and signs it.

To match "legacy" Xamarin.Android's behavior in IDEs we could do
something different while in Visual Studio when
`$(BuildingInsideVisualStudio)` is set. This way we get the desired
behavior:

* `dotnet build` at the command-line produces a signed `.apk` file.
* IDEs will not produce an `.apk` on `Build`. However, when "deploy"
  occurs, the `Install` target will handle producing an `.apk` file as
  needed.

This allowed me to update the `PerformanceTest` that was adding
additional time under .NET 6 for producing `.apk` files. Our MSBuild
tests always set `$(BuildingInsideVisualStudio)` for testing.

I also updated the `[Retry]` attributes so the value was in one place.
jonpryor pushed a commit that referenced this issue Jan 29, 2021
Related: #5436

In "legacy" Xamarin.Android, we have the following behavior:

 1. The `Build` target does not produce an `.apk` or sign it.
 2. Only `SignAndroidPackage` (or `Install`) would do this.

If you hit F6, Ctrl+B, Command+B, etc. within Visual Studio, you don't
have to wait for a valid `.apk` file to be produced to get C#/etc.
build results.   This is useful for incremental build performance,
and for supporting developers' habit of hitting Build all the time.

`dotnet build` has different expectations: it should produce something
that is "runnable".  `dotnet build` currently produces an `.apk` file
and signs it.

To match "legacy" Xamarin.Android's behavior within IDEs, update the
`$(BuildDependsOn)` MSBuild property so that the targets invoked
depends on whether `$(BuildingInsideVisualStudio)`=True.
`$(BuildingInsideVisualStudio)` is normally only set by the IDE,
allowing us to provide different behavior for `dotnet build` vs.
IDE builds:

  * `dotnet build` at the command-line produces a signed `.apk` file.

  * IDEs will not produce an `.apk` on `Build`. However, when
    "deploy" occurs, the `Install` target will handle producing an
    `.apk` file as needed.

This allowed me to update the `PerformanceTest` tests which were
adding additional time under .NET 6 to allow for `.apk` creation.
(Our MSBuild tests always set `$(BuildingInsideVisualStudio)` for
testing, and thus the `.apk` won't be created, making for more
consistent and meaningful times.)

I also updated the `[Retry]` attributes so the value was in one place.
@ghost ghost locked as resolved and limited conversation to collaborators Jun 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Area: App+Library Build Issues when building Library projects or Application projects.
Projects
None yet
Development

No branches or pull requests

1 participant