Fix non-existing language targets restore

[jeromelaban]

This PR fixes the scenario where building a head project should only build the proper dependency chain and ignore unknown targets (e.g. xamarinios10 on linux).

The current behavior is the following:

/mnt/c/temp/msbe-linux/ClassLibrary1/ClassLibrary1.csproj error MSB4057: The target "_GetRestoreSettingsPerFramework" does not exist in the project. [/mnt/c/temp/msbe-linux/ClassLibrary1/ClassLibrary1.csproj]

This PR also adds validations on Linux and macOS.

For the Linux tests, the MSBuild version installed version in the azure devops hosted agents is not working properly (some missing methods in nuget), so the build needs to rely on a container that has the proper setup applied.

See https://github.com/nventive/docker/blob/master/wasm-build/Dockerfile

[clairernovotny]

Be careful with the file encoding. There's an issue where UTF8 with BOM isn't being correctly handled. This file needs to be either ANSI or UTF8 without a BOM. The build error looks like it's tripping up over this.

[jeromelaban]

Yes I just noticed that in your commits, that’s quite the gotcha 🙂 thanks!

[jeromelaban]

@onovotny I'm a bit puzzled by the modification I had to make in order for the tests to pass. Do you remember why it would be needed to conditionally include the original language targets ?

It's all in CheckMissing.targets.

[clairernovotny]

@jeromelaban That import in CheckMissing is intended to only do the import of the default in case the target doesn't exist. Otherwise, the SDK imports it here: https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/sdk/Sdk.targets#L37

Those sdk targets are called here https://github.com/onovotny/MSBuildSdkExtras/blob/f1476ba441d9eacf4152ea04e5cc2e05b97ea6f8/Source/MSBuild.Sdk.Extras/Sdk/Sdk.targets#L15

That said, CheckMissing is called after that point given that it goes:

SDK.target import -> LanguageTargets (like Windows.targets) -> CheckMissing.

However -- and this is big -- in MSBuild 16, because of MSBuildAllProjects being conditional and no longer used, the mechanism no longer works. There's no string/variable that comes from the common targets I can test reliably to see if it has already been imported.

[jeromelaban]

I see. This is why I'm seeing double imports warnings in the tests. I'll see if I can find a way to detect that, maybe I'll be lucky :)

[jeromelaban]

@onovotny It seems that we can rely on CommonTargetsPath to determine if common targets have been included. It fixes both the missing targets issue, and the duplicate imports messages.

[clairernovotny]

@jeromelaban Nice, not sure how I missed that as I was trying to find something like that!

[clairernovotny]

Thanks for tracking this down and setting up those tests!

I'll get this pushed to NuGet once the master build completes.

[jeromelaban]

My pleasure :) We'll be able to add actual 16.3 tests soon.

[clairernovotny]

16.3 is on the agent now if that helps.

[jeromelaban]

I did not notice! That was fast. Then it'll be the turn for macOS and Linux agents.

[clairernovotny]

Not sure when that will be for those. There was an urgent need for 16.3 given the hard error with .NET Core 3.