Design and implement Project SDK resolution that does not involve source-edits or SDK mutation.

[mmitche]

Right now, the source-build infra uses a special msbuild sdk resolver https://github.com/dotnet/dotnet/tree/main/eng/tools/tasks/SourceBuild.MSBuildSdkResolver to enable using the correct msbuild SDK version when building a repo. We need behavior that achieves this for unified build. Is this the best option? I dunno.

For instance, when you build arcade initially, you want to use the arcade version that the VMR has, not what Arcade's global.json specifies. When you build any repo after arcade, you want to use the newly built arcade SDK, not what that repo mentions in its global.json either.

The custom SDK resolver feels a little bit hacky? Maybe maybe not.

T-Shirt Size: Large

[steveisok]

The custom SDK resolver feels a little bit hacky? Maybe maybe not.

Are there things we can infer from the VMR build that would enable us to achieve the same result?

[mmitche]

I don't think so? I think the root of the issue is that SDKs are listed in global.json with their versions. The version of the SDK that we need to use in the build will be unknown until we build it.

[ViktorHofer]

The custom SDK resolver feels a little bit hacky? Maybe maybe not.

I agree that it is hacky. It copies binaries into the immutable .NET SDK directory. That means that developer won't be able to build with their globally installed SDK (when versions match). That would be very unfortunate as we worked really hard on supporting this in the individual repositories.

https://github.com/dotnet/dotnet/blob/2017edaa9105ca502bc09f6f9cd0346ae2fecdff/eng/tools/tasks/SourceBuild.MSBuildSdkResolver/SourceBuild.MSBuildSdkResolver.csproj#L9C59-L9C92 and https://github.com/dotnet/dotnet/blob/6934a8c588bf8627c9e60aec98c156c3e00bf203/Directory.Build.props#L54C30-L54C42

[mmitche]

Totally agree. IMO overriding of the versions of msbuild SDKs should be supported as first class concept.

[ViktorHofer]

Would we still need this if we would cloak the global.json file in the individual repos away and unify them into the root global.json one? Or alternatively, if we would update the global.json SDK entries?

[mmitche]

We would. Because once you build arcade, you want to use that arcade SDK downstream. And ideally you do so without updating the root global.json. Same goes with the Windows desktop SDK

[mmitche]

@marcpopMSFT @dsplaisted @rainersigwald Any opinions here? Some ideas:

• Official support in the default SDK resolver for env var based overrides (vs. installing one of our own)
• Official support within msbuild for overriding the versions based on properties/envvars (without using an sdk resolver)
• Official support for custom resolvers that do not have to be installed in the sdk layout.

[ViktorHofer]

Yes the second option definitely sounds better if it would mean that we could express the override versions inside msbuild before the SDK is fetched and used. That would allow us to not depend on env vars.