Update MSBuildLocator submodule to v1.10.2.

[tmds]

This version provides a fix for crashing on Mono (dotnet/msbuild#12570).

[tmds]

cc @rainersigwald @YuliiaKovalova @ViktorHofer

[ViktorHofer]

Two updates are necessary:

• https://github.com/dotnet/source-build-reference-packages/blob/main/eng/Versions.props#L16 to 1.10.2
• https://github.com/tmds/source-build-reference-packages/blob/mono_fix/src/externalPackages/patches/MSBuildLocator/0002-Move-to-net8.patch needs an update as the tfm got changed upstream to net8.0. I would just trim out the .NET Framework TFM.

[tmds]

I've made the requested changes.

[tmds]

CI isn't passing because both this PR and dotnet/dotnet#2675 are needed together.

[tmds]

Ah, nvmd, I need to move the patch here.

[ViktorHofer]

Looks like another patch also needs an update: 0003-Remove-MicroBuild-signing.patch

[rainersigwald]

@YuliiaKovalova before the next release we should change MSBuildLocator to make these patches unnecessary (by checking for sourcebuild conditions).

[tmds]

@ViktorHofer build failure is:

  /__w/1/s/src/externalPackages/src/MSBuildLocator/artifacts/clone/src/MSBuildLocator/Microsoft.Build.Locator.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Ref with version (= 8.0.20)
  /__w/1/s/src/externalPackages/src/MSBuildLocator/artifacts/clone/src/MSBuildLocator/Microsoft.Build.Locator.csproj : error NU1102:   - Found 4 version(s) in SBRP [ Nearest version: 9.0.0 ]

I'm going to see what happens when I target net10.0 instead of 8.0.

[ViktorHofer]

@tmds as far as I'm aware, MSBuildLocator needs to stay on net8.0. @MichaelSimons @mthalman any idea why that submodule needs the 8.0.20 runtime version? Is the submodule building with the same SDK as the other submodules?

[mthalman]

as far as I'm aware, MSBuildLocator needs to stay on net8.0

I'm not aware of any requirement for that. That may have been a thing in the past when we had repo-level prebuilt detection but that's not around anymore.

any idea why that submodule needs the 8.0.20 runtime version

That's because that's the latest runtime version associated with the net8.0 TFM so that's what it targets by default. I don't know what particular thing causes that package name to be restored though.

Is the submodule building with the same SDK as the other submodules?

Yes.

[ViktorHofer]

I just checked and you are right, all projects that consume this in the source-build graph target the latest TFM. That said, a goal is to keep the differences between the SB builds and MSFT or external packages as small as possible. Having a net10.0 TFM in SB but net8.0 from the upstream package could result in differences. I let you folks decide whether that's a reason to make net8.0 work or not.

[mthalman]

net8.0 can be made to work by following the same pattern that existed in the patch that was removed and have it target 8.0.0 instead of 7.0.0: https://github.com/dotnet/source-build-reference-packages/pull/1399/files#diff-55a2fe703adfc36576f195f486767c265a42560c03d2bd75c1002044810baeb9L28

[rainersigwald]

I don't have strong opinions on the SBRP side, but MSBuildLocator should certainly work fine compiled against net10, so if that smooths things over no objection from me.

[tmds]

The version that gets compiled with source-only .NET 10 will run on the .NET 10 runtime, so except if MSBuildLocator were doing something really specific to .NET 10 (like #if NET10), it will work the same whether it targets net8.0 or net10.0. Based on @rainersigwald comment, I think we can safely use net10.0.