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

Improve "first run" build & run time inside VS #8662

Closed
jonathanpeppers opened this issue Jan 22, 2024 · 4 comments
Closed

Improve "first run" build & run time inside VS #8662

jonathanpeppers opened this issue Jan 22, 2024 · 4 comments
Assignees
@jonathanpeppers
Labels
Area: App+Library Build Issues when building Library projects or Application projects. enhancement Proposed change to current functionality.
Milestone
.NET 9

Comments

@jonathanpeppers
Copy link
Member

Android application type

.NET Android (net7.0-android, net8.0-android, etc.)

Affected platform version

.NET 7,8,9

Description

When you build an Android project, we have logic that "finds" the property $(RuntimeIdentifier) for the attached device:

https://github.com/xamarin/monodroid/blob/867ef5e9ead84e407419e6a1f5d64a3d6583f6d5/tools/msbuild/Xamarin.Android.Common.Debugging.targets#L451-L475

If you have no device attached, it just builds all 4 $(RuntimeIdentifiers).

Problem

This can slow down the 1st time experience for MAUI on Android, as there would be no emulators running or Android devices attached. This builds 4 architectures for no reason.

Solution 1

The IDE passes $(RuntimeIdentifier) to builds. This could be problematic as right now project defaults are:

<RuntimeIdentifier></RuntimeIdentifier>
<RuntimeIdentifiers>android-arm;android-arm64;android-x86;android-x64</RuntimeIdentifiers>
<AppendRuntimeIdentifierToOutputPath>true</AppendRuntimeIdentifierToOutputPath>
<AppendRuntimeIdentifierToIntermediateOutputPath>true</AppendRuntimeIdentifierToIntermediateOutputPath>

This could have unforseen consequences, in trying to use RID for this. There are many general issues about RIDs in multi-targeted projects:

Solution 2

Invent a new property that would skip the <GetPrimaryCpu/> task and just set appropriate properties instead.

Steps to Reproduce

  1. File > New MAUI project
  2. Run in VS without an emulator running or device attached

Did you find any workaround?

No response

Relevant log output

No response
@jonathanpeppers jonathanpeppers added enhancement Proposed change to current functionality. Area: App+Library Build Issues when building Library projects or Application projects. labels Jan 22, 2024
@jonathanpeppers jonathanpeppers added this to the .NET 9 milestone Jan 22, 2024
@jonathanpeppers jonathanpeppers self-assigned this Jan 22, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added the needs-triage Issues that need to be assigned. label Jan 22, 2024
@jonathanpeppers jonathanpeppers changed the title Improve "first run" build & run time Improve "first run" build & run time inside VS Jan 22, 2024
@jpobst jpobst removed the needs-triage Issues that need to be assigned. label Jan 24, 2024
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Feb 12, 2024
@jonathanpeppers
[Xamarin.Android.Build.Tasks] remove $(AndroidSupportedAbis) from `…
afc9203 
…build.props`

Fixes: https://developercommunity.visualstudio.com/t/Visual-Studio-2022-Community-1785-ver/10577484
Related: dotnet#8662

I found the following build performance issue using a .NET Android
project template inside VS Windows:

1. Create a new .NET Android project

2. Open some `AndroidResource` `.xml` file in the Android designer

3. *Every* incremental build appears to rebuild everything!

`obj\Debug\net8.0-android\build.props` appears to be changing between
builds with the change:

```diff
--androidsupportedabis=armeabi-v7a;arm64-v8a;x86;x86_64
++androidsupportedabis=arm64-v8a
```

I narrowed this down to the designer running two targets,
`PrepareResources;_GenerateCompileInputs`:

https://github.com/xamarin/UITools/blob/7b167eae94ae018ab19344d6bfb45a925415e2a7/src/Xamarin.Designer.Android/Xamarin.AndroidDesigner/MSBuildConstants.cs#L32

In this example:

* The designer does *not* mark the build as a "design-time build" with
  `-p:DesignTimeBuild=true`. This would have used a design-time `build.props`.

* The designer does *not* pass in the selected Android device.

This code is *ancient*, so I suspect this has just always been an
issue? Perhaps, it only occurs in .NET 6+ projects and not
Xamarin.Android?

Because `$(AndroidSupportedAbis)` is not a "supported" thing in .NET
6+, let's just remove it?

Removing `$(AndroidSupportedAbis)` from this file manually does fix
the problem for me locally:

    C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.52\tools\Xamarin.Android.Common.targets

There is also a *second* `adb.props` file that triggers a subset of
things to rebuild if the selected Android device changes:

	<WriteLinesToFile
			File="$(_AdbPropertiesCache)"
			Lines="AdbTarget=$(AdbTarget);AdbOptions=$(AdbOptions)"

Usage of the new property, `$(RuntimeIdentifier)`, also changes
`$(IntermediateOutputPath)`, so I feel like we shouldn't need this
value in `build.props` in a .NET 6+ world.
@jonathanpeppers jonathanpeppers mentioned this issue Feb 12, 2024
Merged
dellis1972 pushed a commit that referenced this issue Feb 13, 2024
@jonathanpeppers
[Xamarin.Android.Build.Tasks] remove $(AndroidSupportedAbis) from `…
5472eec 
…build.props` (#8717)

Fixes: https://developercommunity.visualstudio.com/t/Visual-Studio-2022-Community-1785-ver/10577484
Related: #8662

I found the following build performance issue using a .NET Android
project template inside VS Windows:

1. Create a new .NET Android project

2. Open some `AndroidResource` `.xml` file in the Android designer

3. *Every* incremental build appears to rebuild everything!

`obj\Debug\net8.0-android\build.props` appears to be changing between
builds with the change:

```diff
--androidsupportedabis=armeabi-v7a;arm64-v8a;x86;x86_64
++androidsupportedabis=arm64-v8a
```

I narrowed this down to the designer running two targets,
`PrepareResources;_GenerateCompileInputs`:

https://github.com/xamarin/UITools/blob/7b167eae94ae018ab19344d6bfb45a925415e2a7/src/Xamarin.Designer.Android/Xamarin.AndroidDesigner/MSBuildConstants.cs#L32

In this example:

* The designer does *not* mark the build as a "design-time build" with
  `-p:DesignTimeBuild=true`. This would have used a design-time `build.props`.

* The designer does *not* pass in the selected Android device.

This code is *ancient*, so I suspect this has just always been an
issue? Perhaps, it only occurs in .NET 6+ projects and not
Xamarin.Android?

Because `$(AndroidSupportedAbis)` is not a "supported" thing in .NET
6+, let's just remove it?

Removing `$(AndroidSupportedAbis)` from this file manually does fix
the problem for me locally:

    C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.52\tools\Xamarin.Android.Common.targets

There is also a *second* `adb.props` file that triggers a subset of
things to rebuild if the selected Android device changes:

	<WriteLinesToFile
			File="$(_AdbPropertiesCache)"
			Lines="AdbTarget=$(AdbTarget);AdbOptions=$(AdbOptions)"

Usage of the new property, `$(RuntimeIdentifier)`, also changes
`$(IntermediateOutputPath)`, so I feel like we shouldn't need this
value in `build.props` in a .NET 6+ world.
jonathanpeppers added a commit that referenced this issue Mar 11, 2024
@jonathanpeppers
[Xamarin.Android.Build.Tasks] remove $(AndroidSupportedAbis) from `…
caf19b0 
…build.props` (#8717)

Fixes: https://developercommunity.visualstudio.com/t/Visual-Studio-2022-Community-1785-ver/10577484
Related: #8662

I found the following build performance issue using a .NET Android
project template inside VS Windows:

1. Create a new .NET Android project

2. Open some `AndroidResource` `.xml` file in the Android designer

3. *Every* incremental build appears to rebuild everything!

`obj\Debug\net8.0-android\build.props` appears to be changing between
builds with the change:

```diff
--androidsupportedabis=armeabi-v7a;arm64-v8a;x86;x86_64
++androidsupportedabis=arm64-v8a
```

I narrowed this down to the designer running two targets,
`PrepareResources;_GenerateCompileInputs`:

https://github.com/xamarin/UITools/blob/7b167eae94ae018ab19344d6bfb45a925415e2a7/src/Xamarin.Designer.Android/Xamarin.AndroidDesigner/MSBuildConstants.cs#L32

In this example:

* The designer does *not* mark the build as a "design-time build" with
  `-p:DesignTimeBuild=true`. This would have used a design-time `build.props`.

* The designer does *not* pass in the selected Android device.

This code is *ancient*, so I suspect this has just always been an
issue? Perhaps, it only occurs in .NET 6+ projects and not
Xamarin.Android?

Because `$(AndroidSupportedAbis)` is not a "supported" thing in .NET
6+, let's just remove it?

Removing `$(AndroidSupportedAbis)` from this file manually does fix
the problem for me locally:

    C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.52\tools\Xamarin.Android.Common.targets

There is also a *second* `adb.props` file that triggers a subset of
things to rebuild if the selected Android device changes:

	<WriteLinesToFile
			File="$(_AdbPropertiesCache)"
			Lines="AdbTarget=$(AdbTarget);AdbOptions=$(AdbOptions)"

Usage of the new property, `$(RuntimeIdentifier)`, also changes
`$(IntermediateOutputPath)`, so I feel like we shouldn't need this
value in `build.props` in a .NET 6+ world.
@jonathanpeppers
Copy link
Member Author

This scenario is also improved by:

@jonathanpeppers
Copy link
Member Author

The current proposal is:

  • The IDE sets a new value -p:AdbTargetArchitecture
  • At this time, the emulator is closed, adb devices doesn't report anything
  • The IDE doesn't have the value for -p:AdbTarget at this time either

So, the build could:

  • Skip _GetPrimaryCpuAbi if $(AdbTargetArchitecture) is set
  • Set appropriate values for $(RuntimeIdentifiers), etc.

By the time the IDE Deploys, or runs the Install target:

  • Build is complete
  • Emulator is running
  • Install will be passed -p:AdbTarget as before, and passed -p:AdbTargetArchitecture for completeness (this way _GetPrimaryCpu is skipped).

@jonathanpeppers
Copy link
Member Author

/cc @dellis1972 @tondat

@dellis1972
Copy link
Contributor

If the IDE knows what emulator it is going to launch before we do the build then this might work 👍

jonathanpeppers added a commit that referenced this issue Aug 20, 2024
@jonathanpeppers
[tests] add test for $(AdbTargetArchitecture)
83814a4 
Context: #8662
Context: xamarin/monodroid#1537
@jonathanpeppers jonathanpeppers mentioned this issue Aug 20, 2024
Merged
jonathanpeppers added a commit that referenced this issue Sep 5, 2024
@jonathanpeppers
[tests] add test for $(AdbTargetArchitecture)
0440a84 
Context: #8662
Context: xamarin/monodroid#1537

* Bump to xamarin/monodroid@6ba6f3b6

Changes: xamarin/monodroid@ae47ded...6ba6f3b

* [tools/msbuild] implement $(AdbTargetArchitecture) for IDEs
jonathanpeppers added a commit that referenced this issue Sep 6, 2024
@jonathanpeppers
[tests] add test for $(AdbTargetArchitecture) (#9227)
d187a1d 
Context: #8662
Context: xamarin/monodroid#1537

* Bump to xamarin/monodroid@6ba6f3b6

Changes: xamarin/monodroid@ae47ded...6ba6f3b

* [tools/msbuild] implement $(AdbTargetArchitecture) for IDEs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jonathanpeppers jonathanpeppers

Labels
Area: App+Library Build Issues when building Library projects or Application projects. enhancement Proposed change to current functionality.
Projects
None yet
Milestone
.NET 9
Development

No branches or pull requests
3 participants
@jpobst @dellis1972 @jonathanpeppers