Using SDK compiler in torn builds

[jaredpar]

This is the work breakdown for #41790.

• Flow the Micosoft.Net.Compilers.Toolset.Framework package to the .NET SDK
• Create a new package Micosoft.Microsoft.Net.Sdk.Compilers.Toolset in .NET SDK.
  • The contents of this package will include the contents of the tasks\net472 folder in the Microsoft.Net.Compilers.Toolset.Framework package. This subset is all that is needed and makes the package not usable via <PackageReference>. The latter reduces the incentive for customers to use it directly.
  • The contents will include a README.md stating the package is not supported for direct user consumption.
  • The package will follow the versioning scheme of the .NET SDK.
  • The package will be unlisted (ideal but not a hard requirement)
• Change the Sdk.targets file to have copies of the following three <UsingTasks> from [Microsoft.Common.tasks][microsoft-common-tasks]. Having a copy in Sdk.targets means that resetting $(RoslynTargetsPath) during build will change the chosen compiler.
• When the .NET SDK detects a torn state
  • Use a <PackageDownload> to acquire the Microsoft.Net.Sdk.Compilers.Toolset package
  • Change $(RoslynTargetsPath) to point into the package contents

[dotnet-policy-service]

Thanks for creating this issue! We believe this issue is related to NuGet tooling, which is maintained by the NuGet team. Thus, we closed this one and encourage you to raise this issue in the NuGet repository instead. Don’t forget to check out NuGet’s contributing guide before submitting an issue!

If you believe this issue was closed out of error, please comment to let us know.

Happy Coding!