[msbuild] Set 'CopyNuGetImplementations' to true for app extensions. Fixes #4235 and #4237. (#4512) (#4648)

[spouliot]

• [msbuild] Set 'CopyNuGetImplementations' to true for app extensions. Fixes error MT0099 : Internal error : Not all assemblies for Xamarin.Sdk have link tasks. #4235 and MTOUCH : error MT2002: Failed to resolve assembly: 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' #4237.

In Xamarin.iOS.Common.targets, just before the _CompileToNative target, we
modify the mtouch references to ensure that we get the lib assemblies for
nugets, and not the ref references:

https://github.com/xamarin/xamarin-macios/blob/9e31d07ecc08a64372dd562e843c3d8950d24985/msbuild/Xamarin.iOS.Tasks.Core/Xamarin.iOS.Common.targets#L784-L791

This logic removes nuget references, and then re-adds any copy-local dll
references.

This works fine in executable projects, but not in library projects (aka
extensions), because nugets aren't copied for library projects:

https://github.com/NuGet/NuGet.BuildTasks/blob/cf4b0a12cf1f75e0654f28c2a9020251c41d126a/src/Microsoft.NuGet.Build.Tasks/Microsoft.NuGet.targets#L86

So we need to set the CopyNuGetImplementations variable to 'true' for our
library projects.

Fixes #4235.
Fixes #4237.

• [tests] Redirect MSBuildExtensionsPath to MSBuildExtensionsPathFallbackPathsOverride when running msbuild for package reference tests.

This fixes a problem where nuget restore would fail for projects with
PackageReferences, because a variable would be empty and msbould would try to
write to /:

nuget restore ../MyAppWithPackageReference/MyAppWithPackageReference.csproj
MSBuild auto-detection: using msbuild version '15.0' from '/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/'.
Restoring packages for /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/msbuild/tests/MyAppWithPackageReference/MyAppWithPackageReference.csproj...
Committing restore...
Generating MSBuild file /MyAppWithPackageReference.csproj.nuget.g.props.
Path / is a directory

This will become unnecessary when PR #4111 is merged.

• Add Xamarin.Mac test showing that fix is not needed (?!?)

• Add AppExtension test with packagereference

• Make extension actually have json code generated

• Fix ProjectTypeGuids of checked in extension projects, as they were not openable in VSfM

• XM extension test now correctly fails

• Now that we have a failing test, fix XM same as rest of platforms

• Disable XM tests due to msbuild redirect sadness

• Disable iOS tests as well due to msbuild-mac tests should be running with msbuild in addition to xbuild #4110

• Disable iOS tests by using the Ignore attribute.

Disable tests by using the Ignore attribute, because just commenting out the
TestCase attributes makes the test fail:

1) NotRunnable : Xamarin.iOS.Tasks.ProjectReferenceTests.BasicTest
   No suitable constructor was found

[xamarin-release-manager]

🔥 Jenkins job (on internal Jenkins) failed in stage 'Build' 🔥 : hudson.AbortException: script returned exit code 2

🔥 Build failed 🔥

[monojenkins]

Build failure
❌ Build was aborted

🔥 Build failed 🔥

[xamarin-release-manager]

✅ Jenkins job (on internal Jenkins) succeeded

✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)
ℹ️ Test run skipped: Not running tests here because they're run on public Jenkins.

[monojenkins]

Build success
✅ Build succeeded
✅ API Diff (from stable)
✅ API Diff (from PR only) (no change)
✅ Generator Diff (only version changes)
✅ Test run succeeded

[SaqibS]

As discussed by email, members of my team using VS4Mac can now build fine, but I'm using Windows and can't build even after installing the new SDK. See logs attached.
log.txt

[rolfbjarne]

@SaqibS did you try installing the package from this PR (xamarin.ios-11.14.0.15.pkg) to see if that fixes the problem? If not, it's a different problem, in which case you should file a new issue for it.

[spouliot]

@rolfbjarne yes, that's the package I gave @SaqibS and his team. People had success on VS4M but not on Windows. Can you have a look at the logs to see if the logic you modify is somehow not triggered ? thanks!

[rolfbjarne]

@spouliot the logic I modified does not show up in even diagnostic logs, I had to hand-edit target files all over my system to add debug spew to track this down. If it only happens on Windows now, I think we'll need to get the VS team involved.

[spouliot]

moved up to xcode10