Onboarding new build infrastructure

[vatsan-madhavan]

This PR onboards a new shared build infrastrucutre - primarily props + targets - that are shared between this repo and WPF's internal build.

[dotMorten]

I just pulled latest after this merge, clean everything and do a new build. I'm getting a few build errors (VS2019 Prevew 4.4):

1>------ Build started: Project: System.Xaml, Configuration: Release Any CPU ------
2>------ Build started: Project: Microsoft.DotNet.Wpf.GitHub (packaging\Microsoft.DotNet.Wpf.GitHub\Microsoft.DotNet.Wpf.GitHub), Configuration: Release Any CPU ------
3>------ Build started: Project: Microsoft.DotNet.Wpf.GitHub.ArchNeutral, Configuration: Release Any CPU ------
4>------ Build started: Project: Microsoft.DotNet.Arcade.Wpf.Sdk.ArchNeutral, Configuration: Release Any CPU ------
2>Microsoft.DotNet.Wpf.GitHub ->
3>Microsoft.DotNet.Wpf.GitHub.ArchNeutral ->
1>C:\Program Files\dotnet\sdk\3.0.100-preview-009812\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(220,5): message NETSDK1062: Unable to use package assets cache due to I/O error. This can occur when the same project is built more than once in parallel. Performance may be degraded, but the build result will not be impacted.
4>Microsoft.DotNet.Arcade.Wpf.Sdk.ArchNeutral ->
1>System\Xaml\Runtime\DynamicMethodRuntime.cs(41,16,41,29): error CS1069: The type name 'PermissionSet' could not be found in the namespace 'System.Security'. This type has been forwarded to assembly 'System.Runtime.Extensions, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' Consider adding a reference to that assembly.
1>System\Xaml\Permissions\XamlLoadPermission.cs(20,35,20,50): error CS1069: The type name 'PermissionState' could not be found in the namespace 'System.Security.Permissions'. This type has been forwarded to assembly 'System.Runtime.Extensions, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' Consider adding a reference to that assembly.
1>Done building project "System.Xaml.csproj" -- FAILED.
========== Build: 3 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

[dotMorten]

I installed today's CoreFX SDK, but still getting this error, which might be why?

Error occurred while restoring NuGet packages: The operation failed as details for project Microsoft.DotNet.Arcade.Wpf.Sdk.ArchNeutral could not be loaded.
1>------ Build started: Project: System.Xaml, Configuration: Debug Any CPU ------
1>E:\GitHub\dotnet\wpf\src\Microsoft.DotNet.Wpf\src\System.Xaml\System.Xaml.csproj : error NU1605: Detected package downgrade: Microsoft.NETCore.Platforms from 3.0.0-preview4.19178.1 to 3.0.0-preview4.19164.7. Reference the package directly from the project to select a different version. 
1>E:\GitHub\dotnet\wpf\src\Microsoft.DotNet.Wpf\src\System.Xaml\System.Xaml.csproj : error NU1605:  System.Xaml -> System.Security.Permissions 4.6.0-preview4.19178.1 -> System.Security.AccessControl 4.6.0-preview4.19178.1 -> Microsoft.NETCore.Platforms (>= 3.0.0-preview4.19178.1) 
1>E:\GitHub\dotnet\wpf\src\Microsoft.DotNet.Wpf\src\System.Xaml\System.Xaml.csproj : error NU1605:  System.Xaml -> Microsoft.NETCore.Platforms (>= 3.0.0-preview4.19164.7)
1>Done building project "System.Xaml.csproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

[vatsan-madhavan]

We have been seeing multiple clean builds on build servers (which gate merging code everywehre) as well as dev-boxes across several devs, so it seems like it's likely a local problem.

That said, I have definitely seen this problem before in other projects and I've had to clear my nuget cache and uninstall older versions of .NET Core 3 SDK from Add/Remove Programs to recover from this. To be honest, I haven't understood why those steps worked - just that they seemed to work.

[dotMorten]

Thanks @vatsan-madhavan. I'll start digging into some random cleanup.
I just tried building from commandline with build.cmd, and that does work, but I notice it'll run dotnet-install and a bunch of other steps. I however sort of assumed that just building from within VS should "just work" ?

After running a command-line build, VS2019 now only reports this error:

1>------ Rebuild All started: Project: System.Xaml, Configuration: Debug Any CPU ------
1>C:\Program Files\dotnet\sdk\3.0.100-preview4-010965\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.TargetingPackResolution.targets(27,5): error MSB4062: The "CheckForDuplicateFrameworkReferences" task could not be loaded from the assembly C:\Program Files\dotnet\sdk\3.0.100-preview4-010965\Sdks\Microsoft.NET.Sdk\targets\..\tools\net472/Microsoft.NET.Build.Tasks.dll.  Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
1>Done building project "System.Xaml.csproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

[stevenbrix]

@dotMorten can you kill msbuild.exe from the command line and try building in vs again?

[vatsan-madhavan]

@dotMorten, I spent some time trying to reproduce your problem and was eventually able to get it to reproduce it. I can't say that I understand fully why VS builds are different (I'm still learning - clearly BuildingInsideVisualStudio is a popular property in msbuild targets! ;-)) , but this is what I know so far.

• When building via our build.cmd initiated scripts, it looks like Acrade Sdk's script portion under eng\common sets up the build just right to ensure that the version of .NET Core specified in global.json is always used. It does this by getting a copy into $(RepoRoot).dotnet\sdk, and the following build variables resolve like this, approximately (your exact values may be different, but these examples are just illustrative) :

  • BundledAspNetCoreAppPackageVersion = 3.0.0-preview-18630-0234
  • NETCoreSdkBundledVersionsProps = D:\src\repos\wpf.dotnet\sdk\3.0.100-preview-010024\Sdks\Microsoft.NET.Sdk\targets......\Microsoft.NETCoreSdk.BundledVersions.props

• When running a similar build from within VS (and I'd imagine this is the same for msbuild invoked directly), the scripts don't get involved and the global .NET Core gets used, and the corresponding build variables get set up like this:

  • BundledNETCorePlatformsPackageVersion = 3.0.0-preview4.19163.10
  • NETCoreSdkBundledVersionsProps = C:\Program Files (x86)\dotnet\sdk\3.0.100-preview4-010900\Sdks\Microsoft.NET.SDK\targets......\Microsoft.NETCoreSdk.BundledVersions.props

This in turn reproduced the Nuget package downgrade problem. Then when I installed the latest .NET Core system-wide from core-sdk and tried again, that problem went away.

I suspect that when building from within VS/MSBuild (rather than building using build.cmd), one has to ensure that the global version of .NET Core is >= the one specified in global.json.

In addition to this, I also found a couple of other bugs in our codebase that hinders solution builds - I'll fix it shortly (you can preview it in dev/vatsanm/sln-build-fixups branch).

I expect that we will always ask developers to run restore.cmd before VS can be used effectively. A freshly cloned WPF repo would probalby not be ready for use in VS immediately until restore.cmd is run - this is so because our build depends on additional tools being downloaded (for e.g., perl), which are downloaded via powershell scripts that is invoked by restore.cmd.

[dotMorten]

@vatsan-madhavan Thanks Vatsan. Perhaps @davkean has a few good tips to make this "just work" in VS when people clone the repo.