This should unblock dotnet/installer#18770

Unfortunately this still leads to the same issue - so reverting now.
Not sure now, why PR build didn't catch this, but it failed upon merging:

https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=9155329&view=logs&j=bb592630-4b9d-53ad-3960-d954a70a95cf&t=94418e61-6648-5751-f7d4-a14f4e5e2bb7&l=157

Unfortunately this still leads to the same issue - so reverting now. Not sure now, why PR build didn't catch this, but it failed upon merging:

https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=9155329&view=logs&j=bb592630-4b9d-53ad-3960-d954a70a95cf&t=94418e61-6648-5751-f7d4-a14f4e5e2bb7&l=157

@JanKrivanek my hunch is that:

• In CI/PRs, the version of VS on the machine is newer, and has the updated version of desktop msbuild.
• In your official build, the version is older, and only has 17.8 or whatever. This causes either that VS to be used, or the 17.8.3 xcopy-msbuild.

I'm not sure what the right solution is here. You can't rely on core msbuild for the build in all cases, due to generating TLBs in certain cases (and needing to finding the tlb tooling), but it's hard to predict which msbuild is going to get used in various CI/PR/Officail scenarios.

Submitted #9797