[Xamarin.Android.Build.Tasks] <FilterAssemblies/> should look for .jar files #3362
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
…r files Fixes: dotnet#3343 Context: https://github.com/xamarin/XamarinComponents/blob/54646f5c0bef9c618c700628bd1167768d7c9b4f/Android/Guava/source/Guava.ListenableFuture/Guava.ListenableFuture.csproj We introduced a performance improvement in 5ec3e3a that "classifies" assemblies as Xamarin.Android assemblies or not. This allows us to skip processing of NetStandard/BCL assemblies throughout the build. Unfortunately, this Guava.ListenableFuture assembly is odd: * No `[assembly: TargetFramework]` attribute at all * No reference to `Mono.Android.dll` The only "marker" is that it has a `.jar` file as an `EmbeddedResource`, which is put there by `<EmbeddedJar/>`. Its weirdness is related to it not having any C# code, and using SDK-style projects. The fix here is to update `<FilterAssemblies/>` to look for: * `[assembly: TargetFramework("MonoAndroid,Version=v9.0")]` * `Mono.Android.dll` reference * `EmbeddedResource` ending with `*.jar` * `EmbeddedResource` beginning with `__Android` I also reworked this task so that the logic is hardcoded. It does not seem useful to pass in input parameters from MSBuild targets anymore.
dellis1972
approved these changes
Jul 17, 2019
jonpryor
pushed a commit
that referenced
this pull request
Jul 18, 2019
…r files (#3362) Fixes: #3343 Context: https://github.com/xamarin/XamarinComponents/blob/54646f5c0bef9c618c700628bd1167768d7c9b4f/Android/Guava/source/Guava.ListenableFuture/Guava.ListenableFuture.csproj Context: https://www.nuget.org/packages/Xamarin.Google.Guava.ListenableFuture/1.0.0 We introduced a performance improvement in 5ec3e3a that "classifies" assemblies as Xamarin.Android assemblies or not. This allows us to skip processing of NetStandard/BCL assemblies throughout the build. Unfortunately, the `Xamarin.Google.Guava.ListenableFuture.dll` assembly is "odd": * No `[assembly: TargetFramework]` attribute at all * No reference to `Mono.Android.dll` Without either of those, 5ec3e3a thinks that this assembly is *not* a Xamarin.Android-profile assembly, and thus skips processing. The only "marker" is that `Xamarin.Google.Guava.ListenableFuture.dll` has is a `.jar` file as an `@(EmbeddedResource)`, which is put there by the `@(EmbeddedJar)` Build action. The weirdness is related to it not having any C# code, and it using SDK-style projects. Fix support for the `Xamarin.Google.Guava.ListenableFuture.dll` and similar assemblies by updating the `<FilterAssemblies/>` task to look for: * `[assembly: TargetFramework("MonoAndroid,Version=v9.0")]` * `Mono.Android.dll` reference * `EmbeddedResource` ending with `*.jar` (this is new.) * `EmbeddedResource` beginning with `__Android` (this is new.) I also reworked this task so that the logic is hardcoded. It does not seem useful to pass in input parameters from MSBuild targets anymore.
jonpryor
pushed a commit
that referenced
this pull request
Jul 31, 2019
…r files (#3362) Fixes: #3343 Context: https://github.com/xamarin/XamarinComponents/blob/54646f5c0bef9c618c700628bd1167768d7c9b4f/Android/Guava/source/Guava.ListenableFuture/Guava.ListenableFuture.csproj Context: https://www.nuget.org/packages/Xamarin.Google.Guava.ListenableFuture/1.0.0 We introduced a performance improvement in 5ec3e3a that "classifies" assemblies as Xamarin.Android assemblies or not. This allows us to skip processing of NetStandard/BCL assemblies throughout the build. Unfortunately, the `Xamarin.Google.Guava.ListenableFuture.dll` assembly is "odd": * No `[assembly: TargetFramework]` attribute at all * No reference to `Mono.Android.dll` Without either of those, 5ec3e3a thinks that this assembly is *not* a Xamarin.Android-profile assembly, and thus skips processing. The only "marker" is that `Xamarin.Google.Guava.ListenableFuture.dll` has is a `.jar` file as an `@(EmbeddedResource)`, which is put there by the `@(EmbeddedJar)` Build action. The weirdness is related to it not having any C# code, and it using SDK-style projects. Fix support for the `Xamarin.Google.Guava.ListenableFuture.dll` and similar assemblies by updating the `<FilterAssemblies/>` task to look for: * `[assembly: TargetFramework("MonoAndroid,Version=v9.0")]` * `Mono.Android.dll` reference * `EmbeddedResource` ending with `*.jar` (this is new.) * `EmbeddedResource` beginning with `__Android` (this is new.) I also reworked this task so that the logic is hardcoded. It does not seem useful to pass in input parameters from MSBuild targets anymore.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 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.
Fixes: #3343
Context: https://github.com/xamarin/XamarinComponents/blob/54646f5c0bef9c618c700628bd1167768d7c9b4f/Android/Guava/source/Guava.ListenableFuture/Guava.ListenableFuture.csproj
We introduced a performance improvement in 5ec3e3a that "classifies"
assemblies as Xamarin.Android assemblies or not. This allows us to
skip processing of NetStandard/BCL assemblies throughout the build.
Unfortunately, this Guava.ListenableFuture assembly is odd:
[assembly: TargetFramework]attribute at allMono.Android.dllThe only "marker" is that it has a
.jarfile as anEmbeddedResource, which is put there by<EmbeddedJar/>. Itsweirdness is related to it not having any C# code, and using SDK-style
projects.
The fix here is to update
<FilterAssemblies/>to look for:[assembly: TargetFramework("MonoAndroid,Version=v9.0")]Mono.Android.dllreferenceEmbeddedResourceending with*.jarEmbeddedResourcebeginning with__AndroidI also reworked this task so that the logic is hardcoded. It does not
seem useful to pass in input parameters from MSBuild targets anymore.