[Android/Guava] fix for missing [assembly:TargetFramework]

[jonathanpeppers]

Fixes: dotnet/android#3343
Context: dotnet/android#3343 (comment)
Context: dotnet/android#2934

In Visual Studio 2019 16.1, we added some performance improvements in
Xamarin.Android.

In cases of .NET assemblies that:

• Do not have [assembly: TargetFramework ("MonoAndroid")]
• Have no reference to Mono.Android.dll

Unfortunately, these two Guava projects fit into this category! They
include <EmbeddedJar/> but otherwise have no markings at all that
would indicate they are Xamarin.Android assemblies.

Reading the source code for MSBuild, I found that including a single
@(Compile) item solves the issue:

https://github.com/microsoft/msbuild/blob/0cd0e92a7243088977d31b56626b56d6116de016/src/Tasks/Microsoft.Common.CurrentVersion.targets#L3341-L3344

<ItemGroup Condition="'@(Compile)' != '' and '$(TargetFrameworkMonikerAssemblyAttributeText)' != ''">
  <Compile Include="$(TargetFrameworkMonikerAssemblyAttributesPath)"/>
</ItemGroup>

As soon as I added an empty *.cs file to the projects,
[assembly:TargetFramework] appeared in the output assembly with the
necessary info.

This must be a weird corner case for MSBuild... I am not sure if there
is anything we can do on the Xamarin.Android side yet.

[jonathanpeppers]

@Redth is this a NuGet package that would be easy to update?

The only possible thing I could do is look for any *.jar file that is an EmbedddedResource on the Xamarin.Android side -- which would hurt build performance slightly, but be better than reverting the improvement entirely.

Also... are there other components like these?

[dellis1972]

@jonathanpeppers this might be related to the issue I found dotnet/android#3354 ...

[dellis1972]

Would an AssembyInfo.cs file not be better? Surely the assembly should have version information right?

[jonathanpeppers]

@dellis1972 yeah I was seeing it put that file in the temp location, but things were working OK.

The problem was it doesn't create that file at all if @(Compile) is blank. These projects are special in that they don't have any code, and just have <EmbeddedJar/>.

Would an AssembyInfo.cs file not be better? Surely the assembly should have version information right?

These are actually SDK-style projects, which don't have AssemblyInfo.cs:

https://github.com/xamarin/XamarinComponents/blob/54646f5c0bef9c618c700628bd1167768d7c9b4f/Android/Guava/source/Guava.ListenableFuture/Guava.ListenableFuture.csproj

[dellis1972]

@jonathanpeppers it might be just adding

<AssemblyVersion>1.0.0.0</AssemblyVersion>

or something is enough to get something into the @(Compile) itemgroup

[dellis1972]

@jonathanpeppers see https://docs.microsoft.com/en-us/dotnet/core/tools/csproj#assemblyinfo-properties

[jonathanpeppers]

This is really weird, if I add those, I get:

[assembly: CompilationRelaxations(8)]
[assembly: RuntimeCompatibility(WrapNonExceptionThrows = true)]
[assembly: Debuggable(/*Could not decode attribute arguments.*/)]
[assembly: AssemblyCompany("Microsoft")]
[assembly: AssemblyConfiguration("Release")]
[assembly: AssemblyCopyright("© Microsoft Corporation. All rights reserved.")]
[assembly: AssemblyDescription("\r\n    NOTE: This package is meant to be used as a reference only for other binding projects that depend on Guava.\r\n    This package does not expose any useful API's in the .dll itself.\r\n    \r\n    Guava is a set of core libraries that includes new collection types (such as multimap and multiset), immutable collections, a graph library, functional types, an in-memory cache, and APIs/utilities for concurrency, I/O, hashing, primitives, reflection, string processing, and much more!\r\n    ")]
[assembly: AssemblyFileVersion("1.0.0.0")]
[assembly: AssemblyInformationalVersion("1.0.0")]
[assembly: AssemblyProduct("Xamarin.Google.Guava.ListenableFuture")]
[assembly: AssemblyTitle("Xamarin.Google.Guava.ListenableFuture")]
[assembly: SecurityPermission(8, SkipVerification = true)]
[assembly: AssemblyVersion("1.0.0.0")]
[module: UnverifiableCode]

These attrributes come from: obj\Release\monoandroid50\Guava.AssemblyInfo.cs

But the one that is messed up here is: C:\Users\jopepper\AppData\Local\Temp\MonoAndroid,Version=v5.0.AssemblyAttributes.cs and it's not being added to @(Compile) unless there is at least one @(Compile) item already...

I should probably file an MSBuild bug.

[jonathanpeppers]

On second thought, we might be able to just fix this: dotnet/android@master...jonathanpeppers:workmanager

It is looking like it only adds ~25ms on every build, but let me time that with a Release build of XA on a slower PC to be sure.

[dellis1972]

@jonathanpeppers interesting idea. I would make

EmbeddedResourceExtension=".jar"

support

EmbeddedResourceExtensions=".jar;.zip;.mp4"

so that we can extend it in the future.