Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Expand MSBuildSdkResolver #45364

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 22 commits into from
Dec 13, 2024
Merged

Conversation

surayya-MS
Copy link
Member

@surayya-MS surayya-MS commented Dec 6, 2024

Fixes dotnet/msbuild#11086

Context

Details - Here's the flow for sdk resolution in msbuild repo
MSBuildSdkResolver is in resolver list only in case of msbuild.exe.
MSBuildSdkResolver is not present in case of dotnet build. Hence, Muxer is not available in msbuild.exe context as the corresponding issue description suggests.

Changes

  1. Added DOTNET_HOST_PATH to the SdkResult.PropertiesToAdd with value of the path of dotnet.exe similar to dotnet CLI does before triggering builds
  2. Added SdkResolverMSBuildTaskHostRuntimeVersion to the SdkResult.PropertiesToAdd with value of the runtime version MSBuild uses (from MSBuild.runtimeconfig.json file) similar to Muxer.SharedFxVersion

Testing

Manually tested by building sdk repo with build.cmd, then copying Microsoft.DotNet.MSBuildSdkResolver.dll to msbuild, then running msbuild.exe on a console app. Result - DOTNET_HOST_PATH and SdkResolverMSBuildTaskHostRuntimeVersion are present in the binlog as a property in Evaluation phase.
Added check for DOTNET_HOST_PATH and SdkResolverMSBuildTaskHostRuntimeVersion keys in unit tests.

@ghost ghost added Area-SdkResolvers untriaged Request triage from a team member labels Dec 6, 2024
@baronfel
Copy link
Member

baronfel commented Dec 6, 2024

When this is merged, we will want to backport to release/9.0.2xx so that this will ship in a version of VS that Roslyn can use to begin testing. If we don't backport, they would have to wait until we had an insertion of .NET 10 into VS, which is quite a while away.

@surayya-MS surayya-MS marked this pull request as ready for review December 12, 2024 18:44
surayya-MS and others added 5 commits December 13, 2024 17:19
check only "dotnet.exe";
log if couldn't set DOTNET_HOST_PATH and  SdkResolverMSBuildTaskHostRuntimeVersion
@surayya-MS surayya-MS enabled auto-merge December 13, 2024 19:45
@surayya-MS surayya-MS disabled auto-merge December 13, 2024 19:46
@surayya-MS surayya-MS enabled auto-merge (squash) December 13, 2024 19:46
@surayya-MS surayya-MS merged commit 9e7011b into dotnet:main Dec 13, 2024
38 checks passed
@surayya-MS surayya-MS deleted the expand-MSBuildSdkResolver branch December 13, 2024 21:11
@surayya-MS
Copy link
Member Author

/backport to release/9.0.2xx

Copy link
Contributor

Started backporting to release/9.0.2xx: https://github.com/dotnet/sdk/actions/runs/12323103032

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-SdkResolvers untriaged Request triage from a team member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make .NET Framework usage of MSBuild able to set context required to consistently spawn .NET components
4 participants