-
Notifications
You must be signed in to change notification settings - Fork 526
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
Improve "first run" build & run time inside VS #8662
Labels
Area: App+Library Build
Issues when building Library projects or Application projects.
enhancement
Proposed change to current functionality.
Milestone
Comments
jonathanpeppers
added
enhancement
Proposed change to current functionality.
Area: App+Library Build
Issues when building Library projects or Application projects.
labels
Jan 22, 2024
microsoft-github-policy-service
bot
added
the
needs-triage
Issues that need to be assigned.
label
Jan 22, 2024
jonathanpeppers
changed the title
Improve "first run" build & run time
Improve "first run" build & run time inside VS
Jan 22, 2024
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Feb 12, 2024
…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.
dellis1972
pushed a commit
that referenced
this issue
Feb 13, 2024
…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
…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.
This scenario is also improved by: |
The current proposal is:
So, the build could:
By the time the IDE Deploys, or runs the
|
/cc @dellis1972 @tondat |
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
Context: #8662 Context: xamarin/monodroid#1537
jonathanpeppers
added a commit
that referenced
this issue
Sep 5, 2024
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
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
to jonathanpeppers/xamarin-android
that referenced
this issue
Sep 23, 2024
Context: dotnet#8662 Context: xamarin/monodroid#1537 * Bump to xamarin/monodroid@352bcbe8 Changes: xamarin/monodroid@1a9ee37...352bcbe * [tools/msbuild] implement $(AdbTargetArchitecture) for IDEs * Bump to dotnet/android@c158adfd6f
jonathanpeppers
added a commit
that referenced
this issue
Sep 23, 2024
Backport of: #9227 Context: #8662 Context: xamarin/monodroid#1537 * Bump to xamarin/monodroid@352bcbe8 Changes: xamarin/monodroid@1a9ee37...352bcbe * [tools/msbuild] implement $(AdbTargetArchitecture) for IDEs * Bump to c158adfd6f
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.
enhancement
Proposed change to current functionality.
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: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
Did you find any workaround?
No response
Relevant log output
No response
The text was updated successfully, but these errors were encountered: