[Xamarin.Android.Build.Tasks] ILRepack the NuGet.* Tasks Dependencies.

[dellis1972]

ResolveAssemblies is throwing the following error on
a newer mono (2018-04).

error : Could not load file or assembly 'NuGet.ProjectModel, Version=4.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.

This is because we took a dependency on NuGet.ProjectModel 4.6 and
the newer mono has 4.7. This results in the error above.

Now we cannot always be sure which version of the NuGet assemblies
will be installed since users are able to upgrade mono independently.
So this PR will use the ILRepack NuGet to package up the dependencies
we need so that Xamarin.Android.Build.Tasks contains all the
correct assemblies it needs.

[jonpryor]

Why don't we just copy NuGet.ProjectModel into bin/$(Configuration)/lib/xamarin.andriod/xbuild/Xamarin/Android?

This is what we had to do with FSharp.Core.dll, in PR #1440.

[dellis1972]

@jonpryor because we don't know what versions the IDE's might load. And if the API changes ...boom!

[marek-safar]

If you had correct/expected version next to the assembly Mono will load them side by side if they are strongly signed

[dellis1972]

@marek-safar so we could ship the version of Nuget.Project we use if they are Strong Signed?

@jonpryor do we Strong Sign our stuff on Mac and Windows?

[marek-safar]

Yes, that's what does not allows you do to. You can load multiple versions of assemblies with the same name. Now it has its own prons and cons

[alanmcgovern]

sn -v lib/xamarin.android/xbuild/Xamarin/Android/Xamarin.Android.Build.Tasks.dll
Mono StrongName - version 5.14.0.0
StrongName utility for signing assemblies
Copyright 2002, 2003 Motus Technologies. Copyright 2004-2008 Novell. BSD licensed.

lib/xamarin.android/xbuild/Xamarin/Android/Xamarin.Android.Build.Tasks.dll is not a strongly named assembly.

[alanmcgovern]

Alans-MacBook-Pro-2:Current alan$ sn -v lib/mono/msbuild/15.0/bin/NuGet.ProjectModel.dll
Mono StrongName - version 5.14.0.0
StrongName utility for signing assemblies
Copyright 2002, 2003 Motus Technologies. Copyright 2004-2008 Novell. BSD licensed.

Assembly lib/mono/msbuild/15.0/bin/NuGet.ProjectModel.dll is delay-signed but not strongnamed

[jonpryor]

@dean, @alanmcgovern, @marek-safar: As per @alanmcgovern's last comment, NuGet.ProjectModel.dll is delay-signed but not strong-named.

1. Can we easily sign and strong-name it with our own signing key?
2. If (1) is Yes, should we do that? Rephrased, if (1) works, which approach should be preferred: separate assemblies which are strong-named, or IL Repacking?

I'm hesitant to prefer IL Repacking in an OSS context because it makes it harder to "see" where assemblies "come from" and have the user plausibly replace them.

This may just be me "overthinking" things.

[alanmcgovern]

The upstream assemblies aren't signed. We could look into strongnaming the copy that the Xamarin.Android buildsystem wants to ship and also all other assemblies which then need to be strongnamed, but ILRepack has been the in-production mechanism for solving this for Xamarin.iOS and Xamarin.Mac for the last few months: xamarin/xamarin-macios#3168 .

In an opensource context it's still easy for someone to replace arbitrary assemblies. If they understand what they're doing ilrepacking a new assembly will be easy. If they don't understand what they're doing then they probably shouldn't be replacing binaries inside a build system :p