[Xamarin.Android.Build.Tasks] filter @(ReferencePath) for MonoAndroid assemblies

[jonathanpeppers]

We have a couple MSBuild targets that need to only operate on
MonoAndroid assemblies:

• _BuildAdditionalResourcesCache is the precursor to
  Xamarin.Build.Download
• _ResolveLibraryProjectImports unzips
  __AndroidLibrariesProjects__.zip, .jar/.aar files, etc.

Both of these targets all looking at all assemblies, so we could
make a new item group @(_MonoAndroidReferencePath) and use this
instead. This would both allow the tasks inside these targets to
operate on less assemblies. It would also allow them to skip for
changes in NetStandard projects.

I added a new <FilterAssemblies/> MSBuild task to filter based on
the presence of this attribute in an assembly:

[assembly: System.Runtime.Versioning.TargetFrameworkAttribute ("MonoAndroid,Version=v8.1")]

MSBuild/Roslyn populate this attribute based on the
$(TargetFrameworkIdentifier) of the project.

One complication is that during design-time builds, some assemblies
may not exist. I made <FilterAssemblies/> just skip files in this
case--using the same logic that <ResolveLibraryProjectImports/>
uses. (I also fixed some wording/misspelling)

Results

I tested the Xamarin.Forms project in this repo.

Initial build:

Before:
  78 ms  _BuildAdditionalResourcesCache             1 calls
1678 ms  _ResolveLibraryProjectImports              1 calls
After:
  47 ms  FilterAssemblies                           1 calls
  23 ms  _BuildAdditionalResourcesCache             1 calls
1120 ms  _ResolveLibraryProjectImports              1 calls

Incremental build with XAML change:

Before:
 62 ms  _BuildAdditionalResourcesCache             1 calls
300 ms  _ResolveLibraryProjectImports              1 calls
After:
 62 ms  FilterAssemblies                           1 calls
  0 ms  _BuildAdditionalResourcesCache             1 calls
 16 ms  _ResolveLibraryProjectImports              1 calls

Note that during the incremental build, since only a NetStandard
assembly was updated the following targets are skipped:

_BuildAdditionalResourcesCache:
Skipping target "_BuildAdditionalResourcesCache" because all output files are up-to-date with respect to the input files.
...
_ResolveLibraryProjectImports:
Skipping target "_ResolveLibraryProjectImports" because all output files are up-to-date with respect to the input files.

Overall I would say this saves ~500ms on initial build, and ~250ms on
incremental builds.

[jonathanpeppers]

Logs: monoandroidreferencepath.zip

[jonpryor]

I love the idea!

Alas, macOS PR Release Pipeline Build is failing:

error MSB4018: The "FilterAssemblies" task failed unexpectedly.
error MSB4018: System.IO.DirectoryNotFoundException: Could not find a part of the path "…/bin/TestRelease/temp/DesignerBeforeNuGetRestoreTrue/Library1/bin/Debug/Library1.dll".
error MSB4018:   at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options)
error MSB4018:   at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share)
error MSB4018:   at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
error MSB4018:   at System.IO.File.OpenRead (System.String path)
error MSB4018:   at Xamarin.Android.Tasks.FilterAssemblies.Execute ()
error MSB4018:   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute ()
error MSB4018:   at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask (Microsoft.Build.BackEnd.ITaskExecutionHost taskExecutionHost, Microsoft.Build.BackEnd.Logging.TaskLoggingContext taskLoggingContext, Microsoft.Build.BackEnd.TaskHost taskHost, Microsoft.Build.BackEnd.ItemBucket bucket, Microsoft.Build.BackEnd.TaskExecutionMode howToExecuteTask)

[dellis1972]

Nice idea.

Just a head up this might impact this PR #2899 for the AndroidX support. Especially if we apply this to other tasks.

[jonathanpeppers]

The failure on macOS is network-related failures:

[erikpowa]

@jonathanpeppers

only MonoAndroid-profile assemblies can contain those
"special" embedded resources.

It's only true for "official" nuget packages and how they distribute libraries... nothing is stopping anyone to distribute embedded resources differently.

[jonathanpeppers]

@erikpowa are you using a NetStandard library that contains __AndroidLibraryProjects__.zip or __AndroidNativeLibraries__.zip? I wouldn't recommend doing that, it is a private implementation detail that we might change.

[erikpowa]

@jonathanpeppers yeah, I have binding libraries's native stuph (only) in netstandard libs and packed targeting multiple monoandroid like this.

Guess forced to use MSBuild.Sdk.Extras for embedded resources aswell.

Damn multitargeting 😂

[jonathanpeppers]

If you are using MSBuild.Sdk.Extras, you should be OK. You can put MonoAndroid90 or whichever in the list of $(TargetFrameworks), and then you have a MonoAndroid assembly.

This PR looks for:

[assembly: System.Runtime.Versioning.TargetFrameworkAttribute ("MonoAndroid,Version=v8.1")]

(v8.1 could be any number, it just looks before the ,)