[build] Build Mono.Android.Export.dll for the *minimum* API level #581
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-time assembly resolution is...complicated, but to summarize greatly, when `<Reference Include="Mono.Android.Export" />` is resolved, the following locations are checked: $(TargetFrameworkRootPath)\$(TargetFrameworkVersion)\Mono.Android.Export.dll ...included framework versions... $(TargetFrameworkRootPath)\v1.0\Mono.Android.Export.dll The `...included framework versions...` list is controlled by the `RedistList/FrameworkList.xml` files and their `/FileList/@IncludeFramework` attribute value. For example, `bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.1/RedistList/FrameworkList.xml` may have a value of `v7.0` for the `IncludeFramework` attribute. Checking `/FileList/@IncludeFramework` is done "recursively", and if you have a build environment created by `make jenkins`, this will "chain" through every supported framework version. Thus, if `$(TargetFrameworkVersion)` is `v6.0`, then the following directories may be checked to resolve `Mono.Android.Export.dll`: …/MonoAndroid/v6.0/Mono.Android.Export.dll …/MonoAndroid/v5.1/Mono.Android.Export.dll …/MonoAndroid/v5.0/Mono.Android.Export.dll …/MonoAndroid/v4.4.87/Mono.Android.Export.dll …/MonoAndroid/v4.4/Mono.Android.Export.dll …/MonoAndroid/v4.3/Mono.Android.Export.dll …/MonoAndroid/v4.2/Mono.Android.Export.dll …/MonoAndroid/v4.1/Mono.Android.Export.dll …/MonoAndroid/v4.0.3/Mono.Android.Export.dll …/MonoAndroid/v2.3/Mono.Android.Export.dll …/MonoAndroid/v1.0/Mono.Android.Export.dll The first match is used. Which presents a bit of a problem for e.g. [Build dotnet#373's `oss-xamarin.android*.zip`][0] file, which is a build tree prior to this change: It places `Mono.Android.Export.dll` into the `$(AndroidLatestFrameworkVersion)` directory: $ unzip -l oss-xamarin.android_v7.3.99.35_Darwin-x86_64_master_767caad.zip | grep Mono.Android.Export.dll 77824 05-01-2017 21:30 oss-xamarin.android_v7.3.99.35_Darwin-x86_64_master_767caad/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.1/Mono.Android.Export.dll 69632 05-01-2017 21:26 oss-xamarin.android_v7.3.99.35_Darwin-x86_64_master_767caad/bin/Release/lib/xbuild-frameworks/MonoAndroid/v7.1/Mono.Android.Export.dll This is problematic because if the app's `$(TargetFrameworkVersion)` value is *lower* than `v7.1`, then `Mono.Android.Export.dll` *cannot be resolved*: $ xbuild /t:SignAndroidPackage /p:TargetFrameworkVersion=v5.0 ExampleUsingExport.csproj ... error XA4210: You need to add a reference to Mono.Android.Export.dll when you use ExportAttribute or ExportFieldAttribute ...ouch. :-( The correct fix is to update the `make framework-assemblies` target to build `Mono.Android.Export.csproj` into the lowest supported API-level, `$(firstword $(API_LEVELS))`. This would change the contents of the above `oss-xamarin.android*.zip` file to instead contain: …/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v2.3/Mono.Android.Export.dll …/bin/Release/lib/xbuild-frameworks/MonoAndroid/v2.3/Mono.Android.Export.dll Since API-10 (v2.3) is the lowest supported API level, this allows `Mono.Android.Export.dll` to be used in all supported framework versions. "While we're at it," remove the `make task-assemblies` and `make runtime-libraries` targets, as these were redundent with -- and ran the same commands as -- the `make leeroy-all` target. [0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/373/Azure/processDownloadRequest/xamarin-android/oss-xamarin.android_v7.3.99.35_Darwin-x86_64_master_767caad.zip
jonpryor
pushed a commit
that referenced
this pull request
Feb 22, 2020
Changes: dotnet/java-interop@b81cfbb...4f47ec8 Fixes: dotnet/java-interop#572 Context: dotnet/project-system#1821 Context: dotnet/java-interop#509 * dotnet/java-interop@4f47ec8: [generator] Make DIM invoking plumbing private (#581) * dotnet/java-interop@2a0f863: [Java.Interop.sln] Let VS update the project type guids. (#579) * dotnet/java-interop@9a01c9b: [Java.Interop.Tools.Cecil] remove System.Linq in IsSubclassOf (#577) * dotnet/java-interop@cd33da6: [generator] Bind protected nested types (#578) * dotnet/java-interop@fa10e98 :[generator] Do bind package-private nested types (#575)
jonpryor
pushed a commit
that referenced
this pull request
Feb 24, 2020
Changes: dotnet/java-interop@e92f341...178e849 Fixes: dotnet/java-interop#572 Context: dotnet/project-system#1821 Context: dotnet/java-interop#509 * dotnet/java-interop@178e849: [generator] Make DIM invoking plumbing private (#581) * dotnet/java-interop@b7b10bc: [Java.Interop.sln] Let VS update the project type guids. (#579) * dotnet/java-interop@3c590a4: [Java.Interop.Tools.Cecil] remove System.Linq in IsSubclassOf (#577) * dotnet/java-interop@d1bbed7: [generator] Bind protected nested types (#578) * dotnet/java-interop@5db30a8: [generator] Do bind package-private nested types (#575)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
Build-time assembly resolution is...complicated, but to summarize
greatly, when
<Reference Include="Mono.Android.Export" />isresolved, the following locations are checked:
The
...included framework versions...list is controlled by theRedistList/FrameworkList.xmlfiles and their/FileList/@IncludeFrameworkattribute value. For example,bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.1/RedistList/FrameworkList.xmlmay have a value of
v7.0for theIncludeFrameworkattribute.Checking
/FileList/@IncludeFrameworkis done "recursively", and ifyou have a build environment created by
make jenkins, this will"chain" through every supported framework version.
Thus, if
$(TargetFrameworkVersion)isv6.0, then the followingdirectories may be checked to resolve
Mono.Android.Export.dll:The first match is used.
Which presents a bit of a problem for e.g.
Build #373's
oss-xamarin.android*.zipfile, which is a buildtree prior to this change: It places
Mono.Android.Export.dllintothe
$(AndroidLatestFrameworkVersion)directory:This is problematic because if the app's
$(TargetFrameworkVersion)value is lower than
v7.1, thenMono.Android.Export.dllcannot be resolved:
...ouch. :-(
The correct fix is to update the
make framework-assembliestarget tobuild
Mono.Android.Export.csprojinto the lowest supportedAPI-level,
$(firstword $(API_LEVELS)). This would change the contentsof the above
oss-xamarin.android*.zipfile to instead contain:Since API-10 (v2.3) is the lowest supported API level, this allows
Mono.Android.Export.dllto be used in all supported frameworkversions.
"While we're at it," remove the
make task-assembliesandmake runtime-librariestargets, as these were redundent with -- andran the same commands as -- the
make leeroy-alltarget.