Introduce [MSBuild]::StableStringHash overload(s) with alternative hashing

[JanKrivanek]

Blocked By

#9572
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1937630

Context

#9387 introduced improved hashing for [MSBuild]::StableStringHash, that however broke internal functionality relying on the hash to be stable between versions (despite documented otherwise).

Proposal

The easiest way around it is to keep the current property function untouched, but introduce a new overload taking an enum argument:

<!-- Works unchanged -->
[MSBuild]::StableStringHash($x)

<!-- 
  $hashAlgo will currently allow:
    'GetHashCode' - the legacy behavior (mimicking string.GetHashCode)
    'FNV1a_32' - Fawler-Noll-Vo 1a 32bit
-->
[MSBuild]::StableStringHash($x, $hashAlgo)

This way other hashes (like xxHash) can be introduced in the future

Related

• Moving from SHA1 to SHA256 for Hash task #8812 - leveraging the FNV, we can improve the speed of Hash task (as we contemplated usage of xxHash)
• The property function StableStringHash is relatively weak on some input #7131

[KalleOlaviNiemitalo]

This should not have been closed yet; 5af9301 mentioned this issue but did not implement the feature request.

[danmoseley]

Why not just change the existing method rather than add an overload? Keeping it simple. Would it just cause one unnecessary builds on upgrade?

[rainersigwald]

hashtag we tried, @danmoseley.

The change caused a category of problem that's new now that we have caching plugins. The cache used today for some internal Microsoft repos (like the VS repo for example) is populated on official builds from CloudBuild, which run on a recent stable MSBuild, so the caches have the old hash behavior burned in if relevant. When a new hash behavior is deployed to the cache clients (local dev machines), the cache stops functioning correctly.

[JanKrivanek]

Let's not move the hashing utils to StringTools until the #9572 is resolved - as we'd broke the DevKit!

[JanKrivanek]

Blocked by AB#1937630