Clean target breaks on unknown TFM's

[clairernovotny]

I just noticed that on a clean repo that uses my SDK Extras, without the project.assets.json, running msbuild /t:clean fails:

"C:\dev\UWPCommunityToolkit\UWP Community Toolkit.sln" (clean target) (1) ->
"C:\dev\UWPCommunityToolkit\Microsoft.Toolkit.Uwp.DeveloperTools\Microsoft.Toolkit.Uwp.DeveloperTools.csproj" (Clean target) (7) ->
  C:\Program Files\dotnet\sdk\2.0.0\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.TargetFrameworkInference.targets(96,5): error : The TargetFramework value 'uap10.0' was not recognized. It may be misspelled. If not, then the TargetFrameworkIdentifier and/or TargetFrameworkVersion prop erties must be specified explicitly. [C:\dev\UWPCommunityToolkit\Microsoft.Toolkit.Uwp.DeveloperTools\Microsoft.Toolkit.Uwp.DeveloperTools.cs proj]

To repro, clone https://github.com/Microsoft/UWPCommunityToolkit, checkout the dev branch and then try to run
Msbuild /t:clean

That’s it. This seems like a bug since in this state, the targets provided by my NuGet package won’t exist or be imported. Seems like this error check shouldn’t happen on Clean, but it should still nuke obj\TFM and bin\TFM directories?

Binlog:
log.zip

[wli3]

@commonsensesoftware FYI seems the same problem you pointed

[wli3]

@commonsensesoftware sorry, seems related

[commonsensesoftware]

Yes - it does seem to be closely related. I can't understand why MSBuild is resolving the .NET SDK folder: C:\Program Files\dotnet\sdk\2.0.0\Sdks. This only started happening after 2.0.0. If I specify an earlier version of the .NET SDK in the global.json, then things work.

At least for me, I've been completely unable to build UWP projects correctly with 2.0.0 using any of the following:

• MSBuild (directly)
• Visual Studio 15.3.x
• dotnet (but this is expected because UWP still isn't supported)

I'm unable to determine if this is an issue with the .NET SDK or MSBuild. I also tried overriding the MSBuild extension path on the command-line by setting:

/p:MSBuildExtensionsPath="C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild"

But this had no effect. MSBuild still reports the .NET SDK path. I could be wrong, but my understanding is that's how the default imports for *.props and *.targets are redirected from the default MSBuild paths to the .NET SDK paths. Even more surprising is that any global build property specified on the command-line should trump all other settings unless the property is reserved in which case you received an error from MSBuild.

@onovotny have you been able to get anything working with VS 15.3.x and .NET SDK 2.0.0? Maybe I'm just doing something completely wrong or my installation is corrupt.

[clairernovotny]

Everything builds and works fine, just Clean fails. You can see this with the UWP Toolkit.

[wli3]

@onovotny I can clean the project by adding reference to MSBuild.Sdk.Extras and run msbuild /t:restore , to make sure I understand your question: the expected behavior are even without these 2 steps, clean should work right after git clone. aka, there is a default clean target that are not relevant to TFM.

[clairernovotny]

If you do an msbuild /t:restore then an msbuild /t:clean it works. That's because my targets populate the TargetFrameworkIdentifier and TargetFrameworkVersion values. But, if you do a git clean -xdf to start from a pure clean state, where my targets haven't been restored yet, then msbuild /t:clean fails.

[wli3]

@onovotny Find the root cause, but I don’t know the right solution

In SDK, there is a target _CheckForUnsupportedNETStandardVersion to prevent fallback to Common targets that is using full framework (if you have a typo, say "netstandardard2.0" will end up running against the full framework). And this target runs before _CheckForInvalidConfigurationAndPlatform which is in common target.

_CheckForInvalidConfigurationAndPlatform intents to "target runs before any build related targets."

It is all good until, clean, which in a sense is not build related task end up in the dependency of the target _CheckForInvalidConfigurationAndPlatform.

We could

1. "Inline" _CheckForInvalidConfigurationAndPlatform and remove clean, basically

<_CheckForInvalidConfigurationAndPlatform2>$(BuildDependsOn);Build;Rebuild;BeforeRebuild;$(_ProjectDefaultTargets);AfterRebuild;</_CheckForInvalidConfigurationAndPlatform2>

however, $(BuildDependsOn) is intent to be overrode by user, we should keep it, but it includes clean by default. So every user of MSBuild.Sdk.Extras will need to override $(RebuildDependsOn) to something without clean

2. Consider clean is build related, so not fixing it. -- a different SDK could output to different folder, say WillFramework1.2 produces artifacts to a folder called out, it will be a surprise for WillFramework user to see out is not been cleaned. May be an error for complaining no SDK definition will be better.

3. Any other suggestions? @AndyGerlicher @nguerrera

_CheckForInvalidConfigurationAndPlatform
=$(BuildDependsOn);Build; $(RebuildDependsOn); Rebuild;$(CleanDependsOn);Clean
=$(BuildDependsOn);Build ;BeforeRebuild;Clean;$(MSBuildProjectDefaultTargets) ;AfterRebuild;Rebuild;$(CleanDependsOn);Clean

[clairernovotny]

The real solution is that these TFM's need to be in the SDK.... /cc @terrajobst #889