[master] Update dependencies from dotnet/msbuild

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/msbuild

• Subscription: bf9f701b-6ee8-4142-55c5-08d8c8769860
• Build: 20210316.7
• Date Produced: 3/16/2021 8:34 PM
• Commit: 17677364d656a98ce4c6eff73b49eddf24f0fd72
• Branch: refs/heads/main

• Updates:
  • Microsoft.Build.Localization: from 16.10.0-preview-21162-01 to 16.10.0-preview-21166-07
  • Microsoft.Build: from 16.10.0-preview-21162-01 to 16.10.0-preview-21166-07

[ghost]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[sfoslund]

@Forgind @benvillalobos it looks like we're seeing a real error here and in #16349:

C:\code\sdk\artifacts\bin\redist\Debug\dotnet\sdk\6.0.100-dev\NuGet.targets(131,5): The given key '16414' was not present in the dictionary. [C:\code\sdk\artifacts\tmp\Debug\It_builds_non---266F020C\NetStandardAndNetCoreApp\NetStandardAndNetCoreApp.csproj]

[benvillalobos]

First-pass investigation:

The failing task in nuget.targets is:

    <RestoreTask
      RestoreGraphItems="@(_RestoreGraphEntryFiltered)"
      RestoreDisableParallel="$(RestoreDisableParallel)"
      RestoreNoCache="$(RestoreNoCache)"
      RestoreIgnoreFailedSources="$(RestoreIgnoreFailedSources)"
      RestoreRecursive="$(RestoreRecursive)"
      RestoreForce="$(RestoreForce)"
      HideWarningsAndErrors="$(HideWarningsAndErrors)"
      Interactive="$(NuGetInteractive)"
      RestoreForceEvaluate="$(RestoreForceEvaluate)"
      RestorePackagesConfig="$(RestorePackagesConfig)"/>
  </Target>

Not sure what 16404 is referring to. $(HideWarningsAndErrors) makes me think it could be warningsaserrors. Is it possible this test was expecting previous WarningsAsErrors functionality?

What changed: Say a task logged a warning that was turned into an error and returned !Log.HasLoggedErrors. After this change, the task now properly returns false and the build would fail. Previously HasLoggedErrors didn't know when it logged a warning that turned into an error.

[Forgind]

What BenVillalobos said sounds right. Looking at the other PRs that it could theoretically be, most of them prevented exceptions from being thrown (i.e., added a try/catch, deleted an error, etc.) or had no code impact in any scenario here.

What test failed? Does it assume the build will succeed but include an error?

[sfoslund]

What test failed?

GivenThatWeWantToBuildACrossTargetedLibrary.It_builds_nondesktop_library_successfully_on_all_platforms is failing, and I don't think it's expected to have any errors or warnings, it's just building a relatively simple project with no changes:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>netcoreapp1.1;netstandard1.5</TargetFrameworks>
  </PropertyGroup>
  <PropertyGroup Condition="'$(TargetFramework)' == 'netcoreapp1.1'">
    <OutputType>exe</OutputType>
    <DefineConstants>NETCOREAPP;$(DefineConstants)</DefineConstants>
    <AssetTargetFallback>dnxcore50</AssetTargetFallback>
  </PropertyGroup>
  <ItemGroup Condition="'$(TargetFramework)' == 'netcoreapp1.1'">
    <PackageReference Include="Newtonsoft.Json" Version="7.0.1" />
  </ItemGroup>
  <ItemGroup Condition="'$(TargetFramework)' == 'netstandard1.5'">
    <PackageReference Include="Newtonsoft.Json" Version="9.0.1" />
  </ItemGroup>
</Project>

[Forgind]

Could it be sending a warning because .NET Core 1.1 is out of support?

[sfoslund]

Could it be sending a warning because .NET Core 1.1 is out of support?

That happens with a lot of the SDK tests, I don't think it's the cause here.

@nkolev92 have you seen this error before?

C:\code\sdk\artifacts\bin\redist\Debug\dotnet\sdk\6.0.100-dev\NuGet.targets(131,5): The given key '16414' was not present in the dictionary. [C:\code\sdk\artifacts\tmp\Debug\It_builds_non---266F020C\NetStandardAndNetCoreApp\NetStandardAndNetCoreApp.csproj]

[Forgind]

It looks like it was a warnings-as-errors problem. We have a dictionary access without checking that the key is actually in the dictionary here. I should be able to make a PR to fix it.

[marcpopMSFT]

Build with the fix finished a few hours ago but the PR hasn't updated. Let's check back tomorrow and if still not, we can check if the default branch rename affected the subscriptions.