Add warnings related to Microsoft.NET.Sdk.WindowsDesktop

[vatsan-madhavan]

Related: #3126
This is also needed to completely fix dotnet/wpf#866 - we still can't support support multitargeting netcoreapp2.2, and also to fix dotnet/wpf#867

• Adds warning strings related to Microsoft.NET.Sdk.WindowsDesktop
• Adds a check to warn when UseWpf or UseWindowsForms is set without including Microsoft.NET.Sdk.WindowsDesktop

[vatsan-madhavan]

/cc @rladuca

[peterhuene]

Looks good, just a few questions and a nit.

[peterhuene]

Tests are failing with the new warning (treated as error). Perhaps there are some test scenarios that need updating?

[nguerrera]

Something went wrong and things are resetting to English in some files. Can you try reverting all the xlf and let it regenerate? Also, if you have any insight on how this happened, let's add an issue to github.com/dotnet/xliff-tasks.

[peterhuene]

Nice catch as I missed this (unexpanded) file. I wonder what caused this.

[peterhuene]

It happened to src/Tasks/Common/Resources/xlf/Strings.tr.xlf too.

[vatsan-madhavan]

Looking through the history, this happened in the very first commit. I'll redo the work and look through each file this time... and see if I can repro the problem along the way..

[vatsan-madhavan]

Fixed these.

[vatsan-madhavan]

Anyone have ideas on why Windows_NT_TestAsTools Build_Debug is failing ?

[dsplaisted]

@wli3 Can you look at the TestAsTools failure here? It looks like an issue with local tools and/or Json parsing. (It's possible that the way the tool is being run is mixing up different pieces of the .NET Core SDK from stage 0 and from the repo in an incompatible way after stage 0 has been updated).

    System.TypeLoadException: Could not load type 'System.Text.Json.Serialization.JsonSerializer' from assembly 'System.Text.Json, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.
       at Microsoft.DotNet.ToolPackage.LocalToolsResolverCache.Save(IDictionary`2 restoredCommandMap)
       at Microsoft.DotNet.Tools.Tool.Install.LocalToolsResolverCacheExtensions.SaveToolPackage(ILocalToolsResolverCache localToolsResolverCache, IToolPackage toolDownloadedPackage, String targetFrameworkToInstall)
       at Microsoft.DotNet.Tools.Tool.Install.ToolInstallLocalCommand.Install(FilePath manifestFile)
       at Microsoft.DotNet.Tools.Tool.Install.ToolInstallLocalCommand.Execute()
       at Microsoft.DotNet.Tools.Tool.Install.ToolInstallCommand.Execute()
       at Microsoft.DotNet.Cli.DotNetTopLevelCommandBase.RunCommand(String[] args)
       at Microsoft.DotNet.Tools.Tool.ToolCommand.Run(String[] args)
       at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
       at Microsoft.DotNet.Cli.Program.Main(String[] args)
    Errors
        F:\workspace\_work\1\s\src\Tests\Directory.Build.targets(56,5): error MSB3073: The command "dotnet tool install --local testSdkClean --version 3.0.100-ci --add-source F:\workspace\_work\1\s\artifacts\packages\Debug\NonShipping\" exited with code 1. [F:\workspace\_work\1\s\src\Tests\Microsoft.NET.Clean.Tests\Microsoft.NET.Clean.Tests.csproj]

[wli3]

@dsplaisted yes. there was a breaking change from s.t.json. and we get a mix of assembly versions.

[wli3]

update stage 0 should resolve it

[wli3]

never mind, there should be a new breaking change. I need to push it though core-sdk to fix it

[wli3]

Here is the breaking change dotnet/corefx#38120 cc @ahsonkhan

[wli3]

my PR is here dotnet/cli#11532 however, after merging the change need to flow to core-sdk. and then we need to update the stage 0 in this PR to the new build core-sdk

[wli3]

@dsplaisted @livarcocc we need to wait for about a day to check this in. or we can consider ignore "Windows_NT_TestAsTools Build_Debug" if we need to get it in quick

[vatsan-madhavan]

@wli3 Windows_NT_TestAsTools Build_Debug is continuing to fail with the latest core-sdk in Stage 0. Any ideas when this will be fixed? I'm eager to get this change to get in since there is some preview 7 work in WPF that depends on these changes flowing through to core-sdk and then onto dotnet/wpf....

[wli3]

We have a CI issue that is blocking the dependency flow. I will add you to the thread

dotnet/toolset#1207

[wli3]

@vatsan-madhavan meanwhile do you mind add me to your fork as contributor? I can push it through finish if i have the access to push to the branch

[nguerrera]

Normally you have push access to the PR source branch if PR has the checkbox to allow maintainers to do so (which it does by default). This allows this without maintaining collaborator lists in forks.

[vatsan-madhavan]

@wli3 just added you. if i unchecked the 'allow maintainers to edit..' checkbox, i have no memory of doing so. when i try to create another PR from my fork, the checkbox is definitely enabled by default as @nguerrera describes it (which means I must have unchecked it :( and forgotten all about it... ).

[wli3]

also added e6c78c7 to adjust runtime pack name change talked to @dsplaisted

[wli3]

@fadimounir https://dev.azure.com/dnceng/public/_build/results?buildId=224313&view=ms.vss-test-web.build-test-results-tab these new failing tests are in your area. Do you know them?

[fadimounir]

Looks like some update that is maybe breaking the logic around this line:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/PrepareForReadyToRunCompilation.cs

Line 68 in fce5096

ITaskItem frameworkRef = KnownFrameworkReferences.Where(item => String.Compare(item.ItemSpec, "Microsoft.NETCore.App", true) == 0).SingleOrDefault();

Not all failing tests are R2R though...

[dsplaisted]

@wli3 From the output the It_publishes_the_project_with_a_refs_folder_and_correct_deps_file tests are failing because a new file has been added to the runtime, and the baseline needs to be updated:

Unexpected compile libraries: System.Text.Encoding.CodePages.dll

The crossgen failures are failing with:

/__w/1/s/artifacts/bin/Debug/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Publish.targets(245,5): error NETSDK1094: Unable to optimize assemblies for performance: a valid runtime package was not found. Either set the PublishReadyToRun property to false, or use a supported runtime identifier when publishing. [/__w/1/s/artifacts/tmp/Debug/It_creates_re---D21803AE/CrossgenTest3/CrossgenTest3.csproj]

That looks like it's probably also related to the runtime pack rename

[dsplaisted]

@vatsan-madhavan This should hopefully be unblocked if you rebase it on top of #3333, which was just merged

[vatsan-madhavan]

The build finally passed!

Appreciate it if someone can merge at earliest convenience!