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

[ryalanms]

Description

[release/3.1] 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]

Validated .NET upgrade scenario, as requested by .NET Tactics. The project always rebuilds when changing the version of PresentationBuildTasks.

[wtgodbe]

@ryalanms this branch isn't open for check-in right now, please make sure that servicing branches are open before checking into them in the future (no harm in this case, as dependency flow is currently off, but early check-ins can cause problems)