[tests] fix BuildAMassiveApp under MSBuild #1095
Merged
Conversation
This file contains hidden or 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
|
build |
jonpryor
reviewed
Dec 13, 2017
| }; | ||
| //NOTE: under MSBuild BuildingInsideVisualStudio prevents the projects from being built as dependencies | ||
| if (sb.RunningMSBuild) { | ||
| app1.SetProperty("BuildingInsideVisualStudio", "False"); |
There was a problem hiding this comment.
Should we just always set this? I don't think that this will negatively impact xbuild.
Context: https://devdiv.visualstudio.com/DevDiv/Default/_build/index?buildId=1206705&tab=ms.vss-test-web.test-result-details `BuildAMassiveApp` has been failing under MSBuild with: ``` E:\A\_work\1\s\bin\Debug\lib\xamarin.android\xbuild\Xamarin\Android\Xamarin.Android.Common.targets(1167,2): error MSB4018: The "ResolveLibraryProjectImports" task failed unexpectedly. System.IO.FileNotFoundException: Could not load assembly 'Lib0, Version=0.0.0.0, Culture=neutral, PublicKeyToken='. Perhaps it doesn't exist in the Mono for Android profile? File name: 'Lib0.dll' ``` It turns out that setting `BuildingInsideVisualStudio` signals MSBuild that it doesn't need to figure out project dependencies. So `Lib0.csproj` isn't built at the time `ResolveLibraryProjectImports` runs. For now, it seems simpler to turn off `BuildingInsideVisualStudio` in this test under MSBuild, since it was not the goal of the test to verify how things would work inside Visual Studio.
jonathanpeppers
force-pushed
the
windows-buildamassiveapp
branch
from
e78add6 to
341ede0
Compare
jonpryor
pushed a commit
that referenced
this pull request
May 21, 2020
#4643) Changes: xamarin/monodroid@5849ea1...e795bce * xamarin/monodroid@e795bcef3: Bump to xamarin/androidtools@739afe5 (#1095) * xamarin/monodroid@97451721c: [tools/msbuild] add $(_AndroidAllowDeltaInstall) (#1089) Add ***Experimental*** "`.apk` delta installation" support. *What do we want?!* Faster `.apk` installs! (See also PR #4690.) The question, as ever, is *how* to reduce the time of `.apk` installs, and what the tradeoffs are. Fast dev, which removes assemblies from the `.apk`, is one way to do that; PR #4690 is "fastdev v2", which does more there. But for everything else in the `.apk` -- Android Assets, Resources, and more -- how do we make deploying it faster? Here is one way. Android Studio contains an [`installer`][0] utility, built for each supported Android target platform, which is installed onto the target device as `/data/local/tmp/.studio/bin/installer`. `installer` works in terms of "protocol buffers", and can *in place update* an `.apk` file installed on the Android target via a "delta" between the currently installed `.apk` and the "to be installed" `.apk`. `installer` deals with *just* `.apk` contents, and thus doesn't special-case Android Assets, Resources, or IL assemblies. As the `installer` utility is Apache 2 licensed, Xamarin.Android can redistribute and use the `installer` utility as well. To use `installer` to deploy `.apk` updates: 1. Use a Xamarin.Android install which contains `installer` integration, e.g. via `make make prepare-external-git-dependencies` or via a master AzDO-hosted build. 2. Install an app: msbuild /t:Install samples/HelloWorld/HelloWorld.csproj 3. Make a change, e.g. by editing `samples/HelloWorld/Resources/layout/Main.axml`. 4. Install the app, enabling use of this new feature: msbuild /t:Install samples/HelloWorld/HelloWorld.csproj /p:_AndroidAllowDeltaInstall=True This triggers the following in the code: a. Create the `.apk` to deploy, "as normal". b. Check to see if `installer` is present on the Android target. If not, deploy to `/data/local/tmp/.studio/bin/installer`. This happens optimistically, by trying to start up `installer`, looking for certain error codes that indicate the installer isn't present, then installing `installer` if needed. c. Invoke the target's `installer` to obtain the contents of the *currently installed* `.apk` file. d. Compute a diff between (4.c) and the `.apk` in (4.a). e. Deploy the diff to the Android target. f. Invoke `installer` to apply the diff (4.e) to the installed `.apk`, updating its contents to that of (4.a). g. If this process fails for any reason, a "normal" `adb install` is performed. This new workflow is only performed when: * The `$(_AndroidAllowDeltaInstall)` MSBuild Property is True * The App is *already deployed* to the Android target. * The Android target is running API-24 (Android v7.0) or later. Some initial Install timing results for step (4), against a Pixel 3a. Timings are total times, including the build, of which the deploy part takes on the order of 1.5 - 2.5 sec or so: | Test | Normal (s) | Delta (s) | |:----------------------------------------------|--------------:|--------------:| | 18MB APK, fast deploy off, updated 1 assembly | 6.3 | 5.6 | | 9MB APK, fast deploy on, updated 1 resource | 5.6 | 5.3 | [0]: https://android.googlesource.com/platform/tools/base/+/studio-master-dev/deploy/installer
jonpryor
pushed a commit
that referenced
this pull request
May 26, 2020
#4643) Changes: https://github.com/xamarin/monodroid/compare/52312f241428fc78f4d15baaa80b56f85a180427...8d51d0af0572db1583a8ab5ec095bec3046ae476 * xamarin/monodroid@8d51d0af0: Bump to xamarin/androidtools/d16-7@767cfdfe (#1095) * xamarin/monodroid@a0fcae82e: [tools/msbuild] add $(_AndroidAllowDeltaInstall) (#1089) * xamarin/monodroid@781e564e5: [tests] Fix build from xamarin-android (#1093) Add ***Experimental*** "`.apk` delta installation" support. *What do we want?!* Faster `.apk` installs! (See also PR #4690.) The question, as ever, is *how* to reduce the time of `.apk` installs, and what the tradeoffs are. Fast dev, which removes assemblies from the `.apk`, is one way to do that; PR #4690 is "fastdev v2", which does more there. But for everything else in the `.apk` -- Android Assets, Resources, and more -- how do we make deploying it faster? Here is one way. Android Studio contains an [`installer`][0] utility, built for each supported Android target platform, which is installed onto the target device as `/data/local/tmp/.studio/bin/installer`. `installer` works in terms of "protocol buffers", and can *in place update* an `.apk` file installed on the Android target via a "delta" between the currently installed `.apk` and the "to be installed" `.apk`. `installer` deals with *just* `.apk` contents, and thus doesn't special-case Android Assets, Resources, or IL assemblies. As the `installer` utility is Apache 2 licensed, Xamarin.Android can redistribute and use the `installer` utility as well. To use `installer` to deploy `.apk` updates: 1. Use a Xamarin.Android install which contains `installer` integration, e.g. via `make make prepare-external-git-dependencies` or via a master AzDO-hosted build. 2. Install an app: msbuild /t:Install samples/HelloWorld/HelloWorld.csproj 3. Make a change, e.g. by editing `samples/HelloWorld/Resources/layout/Main.axml`. 4. Install the app, enabling use of this new feature: msbuild /t:Install samples/HelloWorld/HelloWorld.csproj /p:_AndroidAllowDeltaInstall=True This triggers the following in the code: a. Create the `.apk` to deploy, "as normal". b. Check to see if `installer` is present on the Android target. If not, deploy to `/data/local/tmp/.studio/bin/installer`. This happens optimistically, by trying to start up `installer`, looking for certain error codes that indicate the installer isn't present, then installing `installer` if needed. c. Invoke the target's `installer` to obtain the contents of the *currently installed* `.apk` file. d. Compute a diff between (4.c) and the `.apk` in (4.a). e. Deploy the diff to the Android target. f. Invoke `installer` to apply the diff (4.e) to the installed `.apk`, updating its contents to that of (4.a). g. If this process fails for any reason, a "normal" `adb install` is performed. This new workflow is only performed when: * The `$(_AndroidAllowDeltaInstall)` MSBuild Property is True * The App is *already deployed* to the Android target. * The Android target is running API-24 (Android v7.0) or later. Some initial Install timing results for step (4), against a Pixel 3a. Timings are total times, including the build, of which the deploy part takes on the order of 1.5 - 2.5 sec or so: | Test | Normal (s) | Delta (s) | |:----------------------------------------------|--------------:|--------------:| | 18MB APK, fast deploy off, updated 1 assembly | 6.3 | 5.6 | | 9MB APK, fast deploy on, updated 1 resource | 5.6 | 5.3 | [0]: https://android.googlesource.com/platform/tools/base/+/studio-master-dev/deploy/installer
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context: https://devdiv.visualstudio.com/DevDiv/Default/_build/index?buildId=1206705&tab=ms.vss-test-web.test-result-details
BuildAMassiveApphas been failing under MSBuild with:It turns out that setting
BuildingInsideVisualStudiosignals MSBuildthat it doesn't need to figure out project dependencies. So
Lib0.csprojisn't built at the timeResolveLibraryProjectImportsruns.
For now, it seems simpler to turn off
BuildingInsideVisualStudiointhis test under MSBuild, since it was not the goal of the test to verify
how things would work inside Visual Studio.