Special case object pool redirection

[chsienki]

• Don't redirect to the shared VS copy
• Redirect to the copy that is next to the compiler
• This ensures that both tooling and roslyn can find the same assemblies

See embedded comment for a detailed description of the problem and why this fixes it.

Fixes https://devdiv.visualstudio.com/DevDiv/_queries/edit/2595643 (AKA Race condition 2)

[davidwengier]

Excellent comment!

The only thing this doesn't really answer for me is why it started happening so much more often, or was it just because the default for the source generator suppression changed?

[chsienki]

@davidwengier Yeah, we changed the default.

Previously, when Roslyn loaded first the other race condition would ensure that the generator is suppressed. That means it doesn't really touch any of the actual generator code and doesn't load ObjectPool. Razor would then load and actually load the rest of the compiler assemblies, including ObjectPool. The first race condition would eventually unstick itself and the generator would use the assemblies loaded by razor.

So this race condition was effectively being avoided by the suppression race condition acting as a loader lock 😆

[chsienki]

/backport to release/dev18.0

[github-actions]

Started backporting to release/dev18.0: https://github.com/dotnet/razor/actions/runs/18391573119