NETSDK1221 warning for wpftmp.csproj projects

[KirillOsenkov]

There's a new warning when building WPF projects targeting net472 using desktop msbuild.exe /r:

C:\Program Files\dotnet\sdk\9.0.100-rc.2.24474.11\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(267,5): warning NETSDK1221: NuGetPackageRoot property is empty so package Microsoft.Net.Sdk.Compilers.Toolset cannot be used but it is recommended because your MSBuild and SDK versions are mismatched. Ensure you are building with '/restore /t:Build' and not '/t:Restore;Build'. [C:\proj\proj_o3rfveu0_wpftmp.csproj]

This is a breaking change and is potentially urgent, cc @marcpopMSFT

[marcpopMSFT]

@KirillOsenkov Adding @jjonescz. Are you doing anything special? Is there a reason that NuGetPackageRoot
is not set? You can work around this by setting BuildWithNetFrameworkHostedCompiler to false though that's now defaulting to true if your SDK and VS don't match (what VS version are you using with RC2 SDK)?

#43119 brought in this warning

[KirillOsenkov]

It could be because I'm using VS 17.11.5 with the rc2 SDK. Have you tried building a WPF project targeting net472 with that combination?

[KirillOsenkov]

@jjonescz ping me on Teams if you're having trouble reproducing.

[jjonescz]

VS 17.11.5 with the rc2 SDK

That looks like a mismatched combination. Can you use VS 17.12 instead?

Have you tried building a WPF project targeting net472 with that combination?

Yes, WPF is a known problematic scenario where NuGetPackageRoot isn't set. See the following in #43016:

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

• in the inner build started by task GenerateTemporaryTargetAssembly when building WPF on .NET Framework

We already discussed this under the issue it seems: #43016 (comment)

Note that this is just a warning so it should be suppressible.

@marcpopMSFT I believe we knew and discussed this WPF scenario is broken when we were introducing the warning. I don't know if someone is looking at solving this inside WPF? Or should we try to suppress this warning for the problematic WPF inner build?

[KirillOsenkov]

The problem is that builds that were fine a month ago will suddenly be not fine after installing the 9.0 SDK.

People also have warnings as errors set.

We need to have a higher bar for compat, we can't be breaking users builds like this.

[KirillOsenkov]

definitely need to add a check for wpftmp

[marcpopMSFT]

@marcpopMSFT I believe we knew and discussed this WPF scenario is broken when we were introducing the warning. I don't know if someone is looking at solving this inside WPF? Or should we try to suppress this warning for the problematic WPF inner build?

@jjonescz We should definitely try to avoid the warning in this situation for WPF if we can as customers see warnings as errors and as Kyrill noted, are suddenly broken if they update in a way as to get torn. Can we do this in the SDK or should this be in the WPF side? Seems like suppressing the automatic Roslyn package when NuGetPackageRoot is not set will handle a broader set of cases (ie in case any other situations end up with that unset)?

CC @pchaurasia14 @baronfel @jaredpar for visibility.

[jjonescz]

Can we do this in the SDK or should this be in the WPF side?

Depends on what you mean by "avoid the warning". We can probably suppress it if we detect we are in wpftmp build. Solving the empty NuGetPackageRoot problem would likely require some work on WPF side, I haven't investigated that.

Seems like suppressing the automatic Roslyn package when NuGetPackageRoot is not set will handle a broader set of cases (ie in case any other situations end up with that unset)?

So are you saying we should just remove the warning? Because that's exactly why we added it - to avoid customers being in a torn state without noticing. We already aren't using the automatic Roslyn package when NuGetPackageRoot is empty (we can't), we are just not silent about it.

[jjonescz]

We can probably suppress it if we detect we are in wpftmp build.

Opened a PR for this here: #44688

Solving the empty NuGetPackageRoot problem would likely require some work on WPF side, I haven't investigated that.

I realized this is from a task defined in .NET Framework targets (C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets), I assume those are hard/impossible to change?