Bump to xamarin/Java.Interop/master@56c92c70

[jonpryor]

DO NOT MERGE

Context: dotnet/java-interop#597

Just testing to see if dotnet/java-interop#597 works...

[jonpryor]

Doh, forgot to make this a Draft!

[jonpryor]

Alas, it doesn't work; it fails to build:

  Java.Interop.Tools.Diagnostics/Diagnostic.cs(151,39): error CS0433: The type 'SequencePoint' exists in both 'Mono.Cecil, Version=0.11.2.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e' and 'Xamarin.Android.Cecil, Version=0.11.1.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' [/Users/builder/azdo/_work/3/s/xamarin-android/external/Java.Interop/src/Java.Interop.Tools.Diagnostics/Java.Interop.Tools.Diagnostics.csproj]
  Java.Interop.Tools.Diagnostics/XamarinAndroidException.cs(38,10): error CS0433: The type 'SequencePoint' exists in both 'Mono.Cecil, Version=0.11.2.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e' and 'Xamarin.Android.Cecil, Version=0.11.1.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' [/Users/builder/azdo/_work/3/s/xamarin-android/external/Java.Interop/src/Java.Interop.Tools.Diagnostics/Java.Interop.Tools.Diagnostics.csproj]

Current conjecture is that external/Java.Interop/src/Java.Interop.Tools.Diagnostics/obj contains various *.cache files which mention both Mono.Cecil.dll and Xamarin.Android.Cecil.dll:

 % grep -ril Cecil --include=\*.cache obj | xargs strings | grep Cecil
}…/Java.Interop/$/../packages/mono.cecil/0.11.2/lib/netstandard2.0/Mono.Cecil.dll
…/Java.Interop/$/../packages/mono.cecil/0.11.2/lib/netstandard2.0/Mono.Cecil.Mdb.dll
…/Java.Interop/../../bin/Debug/lib/xamarin.android/xbuild/Xamarin/Android/Xamarin.Android.Cecil.dll
…/Java.Interop/$/../packages/mono.cecil/0.11.2/lib/netstandard2.0/Mono.Cecil.Rocks.dll
…/Java.Interop/$/../packages/mono.cecil/0.11.2/lib/netstandard2.0/Mono.Cecil.Pdb.dll
Mono.Cecil
NMono.Cecil, Version=0.11.2.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e
Mono.Cecil.Mdb
RMono.Cecil.Mdb, Version=0.11.2.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e
Xamarin.Android.Cecil
YXamarin.Android.Cecil, Version=0.11.1.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756
Mono.Cecil.Rocks
TMono.Cecil.Rocks, Version=0.11.2.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e
Mono.Cecil.Pdb
RMono.Cecil.Pdb, Version=0.11.2.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e
…/Java.Interop/%24/../packages/mono.cecil/0.11.2/lib/netstandard2.0/Mono.Cecil.Mdb.dll
…/Java.Interop/%24/../packages/mono.cecil/0.11.2/lib/netstandard2.0/Mono.Cecil.Pdb.dll
…/Java.Interop/%24/../packages/mono.cecil/0.11.2/lib/netstandard2.0/Mono.Cecil.Rocks.dll
…/Java.Interop/%24/../packages/mono.cecil/0.11.2/lib/netstandard2.0/Mono.Cecil.dll
Mono.Cecil
…/Java.Interop/%24/../packages/mono.cecil/0.11.2/lib/netstandard2.0/Mono.Cecil.Mdb.dll
…/Java.Interop/%24/../packages/mono.cecil/0.11.2/lib/netstandard2.0/Mono.Cecil.Pdb.dll
…/Java.Interop/%24/../packages/mono.cecil/0.11.2/lib/netstandard2.0/Mono.Cecil.Rocks.dll
…/Java.Interop/%24/../packages/mono.cecil/0.11.2/lib/netstandard2.0/Mono.Cecil.dll
Mono.Cecil
PathInPackage%lib/netstandard2.0/Mono.Cecil.Mdb.dll%lib/netstandard2.0/Mono.Cecil.Pdb.dll'lib/netstandard2.0/Mono.Cecil.Rocks.dll!lib/netstandard2.0/Mono.Cecil.dll
Mono.Cecil.Mdb.dll
Mono.Cecil.Pdb.dll
Mono.Cecil.Rocks.dll
Mono.Cecil.dll

Furthermore, if I delete the external/Java.Interop/src/Java.Interop.Tools.Diagnostics/obj directory, it builds:

$ rm -Rf obj
$ msbuild /restore /v:diag > b.txt
$ echo $?
0

[jonpryor]

It looks like using msbuild /restore everywhere allows Java.Interop.Tools.Diagnostics to build even when obj contains cache files mentioning the "wrong" assembly...

[jonpryor]

...and, related: dotnet/msbuild#3000 (comment)

dotnet/msbuild#2811

[jonpryor]

Now that it builds, dotnet/java-interop#597 has been merged. Now to turn this PR into a "real" Java.Interop bump

[jonpryor]

Squash-and-merge summary:

Bump to xamarin/Java.Interop/master@56c92c70 (#4376)

Commit body:

Changes: https://github.com/xamarin/Java.Interop/compare/1a086ffd51436ec3bb78467a150e4f9121d57419...56c92c70887c58275917752450126c8c39988aa2

  * xamarin/Java.Interop@56c92c7: [build] Remove cecil submodule (#597)
  * xamarin/Java.Interop@3091274: [build] Provide a default $(Configuration) value (#612)
  * xamarin/Java.Interop@cf3e7c2: [generator] Don't process duplicate reference assemblies (#611)
  * xamarin/Java.Interop@f5fa462: [jnienv-gen] Convert to SDK-style (#608)

Of particular note is [xamarin/Java.Interop@56c92c7][0], which
replaces the `mono/cecil` submodule within Java.Interop with the
[`Mono.Cecil` NuGet package][1] in an effort to simplify the
Java.Interop build system.

This simplifies the Java.Interop repo, and we *thought* that since
xamarin-android *doesn't even use* Java.Interop's cecil submodule-built
`Mono.Cecil.dll` -- instead the `Mono.Cecil.dll` from the
"mono archive" is "renamed" to `Xamarin.Android.Cecil.dll` during
`make prepare` (0c9f83b7) -- surely this would be a simple change.

The removal of the cecil submodule also required changing
`ThirdPartyNotice.txt` generation so that the LICENSE for Cecil was
obtained from the mono archive instead of from Java.Interop.

Unfortunately, the integration was a tad more complicated than
anticipated.  With the ongoing adoption of MSBuild multi-targeting
and builds against the `netcoreapp3.1` target framework -- commit
e2854ee7 and numerous commits in Java.Interop -- we encountered a
problem with MSBuild semantics: If two `$(TargetFramework)` builds
share the same output directory, the `IncrementalClean` target will
*remove files created by previous builds*, e.g. when e.g.
`Java.Interop/tools/generator.csproj` builds the `netcoreapp3.1`
framework, it will *delete* the `generator.exe` built by the `net472`
framework, which results in subsequent build breaks.

The only path to sanity is to *ensure* that different
`$(TargetFramework)` builds have *completely separate* `$(OutputPath)`
values.  The "normal" approach to doing this is for `$(OutputPath)`
to end with `$(TargetFramework)`, which is the case when
`$(AppendTargetFrameworkToOutputPath)`=True (the default).

Unfortunately in xamarin-android we don't want `$(OutputPath)` to end
with `$(TargetFramework)`; we want the build tree structure to mirror
the installation directory structure, which -- at present -- doesn't
mention `$(TargetFramework)` at all.

The solution here is to use "non-overlapping" directories.  For
example, in e2854ee7 there are "two" `$(OutputPath)` values:

  * `MonoAndroid10.0`: `bin/Debug/lib/xamarin.android/xbuild-frameworks/MonoAndroid/v10.0/Mono.Android.dll`
  *   `netcoreapp3.1`: `bin/Debug/lib/xamarin.android/xbuild-frameworks/Xamarin.Android.App/netcoreapp3.1/Mono.Android.dll`

The same "non-overlapping directories" strategy needs to be extended
to *all* multi-targeted projects from Java.Interop, *including*
dependencies.  Dependencies such as `Xamarin.Android.Cecil.dll`.

Define a new `$(UtilityOutputFullPathCoreApps)` MSBuild property so
that Java.Interop "utility" project builds, when building for the
`netcoreapp3.1` framework, use a *different* `Xamarin.Android.Cecil.dll`
than is used with the `net472`-related builds.

Update `xaprepare` to *create* this new `netcoreapp3.1`-correlated
`Xamarin.Android.Cecil.dll`.  It's the same file, just in a different
directory, to prevent "accidental" deletes by `IncrementalClean`.

Even with all that, MSBuild still had other ideas.  In particular,
MSBuild wasn't particularly happy about our attempt to use the
`$(UtilityOutputFullPath)` property to "switch" between using a
`@(PackageReference)` to the Mono.Cecil NuGet package vs. using a
`@(Reference)` to the `Xamarin.Android.Cecil.dll` assembly, because
MSBuild *caches* this information somewhere within `obj` directories.

To get MSBuild to re-evaluate it's assembly reference choices, we must
instead replace `msbuild` with `msbuild /restore`.

Which still isn't enough, because some of our MSBuild invocations are
via the `<MSBuild/>` task, within `msbuild`.  To get *that* working,
we need to explicitly invoke the `Restore` target through a *separate*
`<MSBuild/>` task invocation.  You ***CANNOT*** use
`<MSBuild Targets="Restore;Build" />`, as "obvious" as that may be,
because it [doesn't work reliably][2].  ([Yet.][3])

[0]: https://github.com/xamarin/Java.Interop/commit/56c92c70887c58275917752450126c8c39988aa2
[1]: https://www.nuget.org/packages/Mono.Cecil/0.11.2
[2]: https://github.com/microsoft/msbuild/issues/3000#issuecomment-417675215
[3]: https://github.com/microsoft/msbuild/issues/2811