[release/5.0] Fix incremental build issue in WPF's markup compiler

[ryalanms]

Description

[release/5.0] Fix incremental build issue in WPF's markup compiler

This moves @MichaeIDietrich's original PR from master.

WPF rebuilds its intermediate assembly containing local types when no inputs have changed.

As part of the WPF's incremental build logic, WPF applies a hash to the list of reference filenames during compilation. The hash value is written to a cache file and compared against the hash value of the new list of reference filenames next compile. This comparison always fails due to the hash value for the same list of strings differing between runs and causes WPF to always build its intermediate project, even when inputs have not changed. .NET's GetHashCode is not stable between separate application runs as it was in .NET Framework.

Customer Impact

One large internal Microsoft customer and one large external customer have both asked for this to be fixed as soon as possible.

The WPF team has been working with both customers to reduce their build times. Customers tested instrumented builds of our markup compiler with earlier versions of this fix to identify causes of unnecessary temporary target assembly builds. Replacing GetHashCode fixed the majority of the incremental build issues for both customers. (Accidental file changes during the build was another non-WPF cause.)

Regression?

Not from 3.0, but from .NET Framework.

Risk (see taxonomy)

Low. The replacement hash function is a port of existing .NET code. This is only called during markup compilation.

Link the PR to the original issue and/or the PR to master.

Original Issue:

Building WPF projects is not deterministic with dotnet.exe #3876

Original PR:

Fix incremental build for WPF projects with dotnet.exe #4053

Is there a packaging impact?

No.

[ryalanms]

The request from Tactics was to verify that updating the .NET 5.0 version with this fix always forces a rebuild of existing projects. The concern was that the cache file from a previous version without the fix may prevent the rebuild from occurring.

[ryalanms]

I've confirmed that building a project with release/5.0, and updating to the release/5.0 branch with the fix, forced the project to rebuild. The detection happened here:

https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/PresentationBuildTasks/MS/Internal/Tasks/IncrementalCompileAnalyzer.cs#L88

                // if PresenationBuildTasks.dll is changed last build, rebuild the entire project for sure.

                if (IsFileChanged(Assembly.GetExecutingAssembly().Location) ||
                    IsFileListChanged(_mcPass1.ExtraBuildControlFiles))
                {
                    _analyzeResult = RecompileCategory.All;
                }