[Xamarin.Android.Build.Tasks] Use correct Mono.Android.dll

[jonpryor]

DO NOT MERGE

This is an "alternate" take on PR #146.

---

We're trying to get make jenkins working on Jenkins, and
it's failing, as one might expect when a particular repo and
associated build system has never been run on Jenkins before:

Android.App/ApplicationTest.cs(9,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference?

This error occurs while building
src/Mono.Android/Test/Mono.Android-Tests.csproj, and happens because
the Xamarin.Android.NUnitLite.dll assembly isn't referenced...
because it isn't found:

Microsoft.Common.targets: warning : Reference 'Xamarin.Android.NUnitLite' not resolved

This raises a long-standing issue with building xamarin-android:
The Xamarin.Android SDK is intended to be usable from a system-wide
installation environment, e.g. installed into
$(MSBuildExtensionsPath), as many MSBuild tasks such as
<GetReferenceAssemblyPaths/> are used to resolve assemblies, and
those -- by default -- look in system-wide installation locations.

"Unfortunately," A xamarin-android build should not be built
into the system-wide install location; it should be built in a
separate location, for all manner of "hygiene" and "sanity" reasons.

Additionally, overriding $(TargetFrameworkRootPath) isn't a reliable
solution.

All of which adds up to either build failures such as the above --
when there is no system-wide Xamarin.Android install -- or the
use/resolution of the system-wide Xamarin.Android assemblies when
building e.g. src/Mono.Android/Test, which is wholly undesirable.

A possible "fix"/"workaround": force xbuild to behave as we want
it to by setting the $MSBuildExtensionsPath and
$XBUILD_FRAMEWORK_FOLDERS_PATH environment variables
from within the build process. Since xbuild doesn't cache the
value of these environment variables, calling
Environment.SetEnvironmentVariable() within the build process will
cause subsequent <GetReferenceAssemblyPaths/>/etc. invocations to
use the updated values, allowing us to control which directories are
used for assembly framework resolution purposes.

Update the _GetReferenceAssemblyPaths target within
Xamarin.Android.Common.targets and
Xamarin.Android.Bindings.targets so that they call the new
<SetMSBuildExtensionsPath/> task, which updates the
$MSBuildExtensionsPath and $XBUILD_FRAMEWORK_FOLDERS_PATH
environment variables. This allows building src/Mono.Android/Test
with "normal" xbuild to use the intended assemblies without
requiring the use of tools/scripts/xabuild to build
src/Mono.Android/Test.

[radical]

re:commit-msg, did you miss the links for [make jenkins][0] and [it's failing][1]?

[radical]

Where is this task being loaded from? Can this path that we are trying to determine here, be computed in the targets and passed as input here?

[jonpryor]

The task is being loaded from wherever Xamarin.Android.Build.Tasks.dll is installed, $prefix/lib/xbuild/Xamarin/Android on OS X.

[jonpryor]

It seems that this approach isn't viable, because of xbuild's AsssemblyResolver. (There's no way to clear/invalidate target_framework_cache.)

Background: we want src/Mono.Android/Test/Mono.Android-Tests.csproj to be as normal as possible, so it uses <Reference Include="Xamarin.Android.NUniteLite" /> instead of a @(ProjectReference) to Xamarin.Android.NuniteLite. (There is a @(ProjectReference) to Xamarin.Android.NuniteLite.csproj, but %(ProjectReference.ReferenceOutputAssembly) is False, preventing the assembly from being referenced. @(ProjectReference) is there solely to control the build order: Xamarin.Android.NUniteLite.dll is required, so it must be built first.)

The idea of PR #147 was to "hack things up" so that Xamarin.Android.NuniteLite.dll would be properly resolved during the build of Mono.Android-Tests.csproj when building everything.

The problem is this can't work, because xbuild has a "target framework cache," with no way to invalidate it, and the cache is populated the first time the target framework is used. Due to build ordering issues, this first use is before Xamarin.Android.NunitLite.dll was built, and thus it doesn't exist in the cache. The result:

Task "ResolveAssemblyReference"
    ....
    TargetFrameworkDirectories:
        /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.0
        /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0
        /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/
    ...
    Primary Reference System.Xml
        Reference System.Xml resolved to /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/System.Xml.dll. CopyLocal = False
    ...
    Primary Reference Xamarin.Android.NUnitLite
Microsoft.Common.targets:  warning : Reference 'Xamarin.Android.NUnitLite' not resolved
    For searchpath {TargetFrameworkDirectory}
    Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.0, assembly named 'Xamarin.Android.NUnitLite' not found.
    Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0, assembly named 'Xamarin.Android.NUnitLite' not found.
    Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/, assembly named 'Xamarin.Android.NUnitLite' not found.
...

Consequently, the mcs invocation is missing a /reference:path/to/Xamarin.Android.NUniteLite.dll, and compilation fails:

Android.App/ApplicationTest.cs(9,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference?
...plus 29 others...

[jonpryor]

This doesn't work, as per a prior comment, so we're going with PR #146.