-
Notifications
You must be signed in to change notification settings - Fork 533
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Xamarin.Android.Build.Tasks] Install should skip Build when inside t…
…he IDE (#2626) Context: http://work.devdiv.io/765447 Context: https://github.com/jonathanpeppers/HelloWorld Context: https://github.com/xamarin/xamarin-android/wiki/IDE-Performance-Results When doing some performance measurements *inside* of Visual Studio, I noticed some significant overhead in a build without changes. In a "Hello World" Xamarin.Forms app: Preparation Time: 00:03.9 Launch Time: 00:02.5 Where "Preparation Time" is everything MSBuild, and "Launch Time" is the time it takes to start the Android application and attach the debugger. "Preparation Time" is effectively: msbuild Foo.Android.csproj /p:BuildingInsideVisualStudio=True /t:Build msbuild Foo.Android.csproj /p:BuildingInsideVisualStudio=True /t:Install One concern here is that the `Install` target depends on the `SignAndroidPackage` target, which depends on the `Build` target. We are doing a lot of MSBuild work here *twice*, since MSBuild needs to run through certain targets twice and decide whether they can be skipped. This work is "not free" and mostly involves MSBuild evaluating properties and time stamps on files. What I found we could do here is skip the `Build` on the `Install` targets when `$(BuildingInsideVisualStudio)` is `True`. Due to the dependency chain, this also affects `SignAndroidPackage`. The minimal list of targets for `SignAndroidPackage` that still work: * `_CreatePropertiesCache` * `ResolveReferences` * `_CopyPackage` * `_Sign` Initial results from the IDE show: Preparation Time: 00:02.06s Launch Time: 00:02.5 This is a ~1.8 second saving on the inner dev loop! ~~ MSBuild Tests ~~ Since our MSBuild tests set `$(BuildingInsideVisualStudio)`, a lot of our tests might break. We might have to add an additional call to `Build` in each failing test. The way I worked around this was to make the `BuildHelper.CreateApkBuilder()` method run the `Build,SignAndroidPackage` target by default. Originally there were 248 test failures. I also did some other cleanup: - Added a `ProjectBuilder.RunTarget()` method, so tests can more easily run custom targets and not modify the `Target` property: `builder.RunTarget ("Foo")`. - Added `ProjectBuilder.DesignTimeBuild`(). - `Builder` now has a `BuildingInsideVisualStudio` property to toggle the value as a command-line global property. We were putting this in the `csproj`, which seems a bit different than what IDEs are actually doing... Also added a `BuildTest.BuildOutsideVisualStudio()` test to verify the `SignAndroidPackage` target works by itself *outside* of IDEs.
- Loading branch information
1 parent
5951aa5
commit 76fb90e
Showing
12 changed files
with
95 additions
and
60 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters