Hey @dotnet/aspnet-build, looks like this PR is something you want to take a look at.

I prefer dotnet/installer#16318 (comment) if it's fast enough, it's more of a stage0 SDK issue than an aspnetcore issue (cc @mmitche)

I prefer dotnet/installer#16318 (comment) if it's fast enough, it's more of a stage0 SDK issue than an aspnetcore issue (cc @mmitche)

I'd prefer both. I like the value that we get out of being able to control what version we build against in the event that this happens in the future.

I also prefer both. I like that we get a consistent experience in and out of source-build. No surprises.

Looks like you need to follow https://github.com/dotnet/source-build/blob/main/Documentation/eliminating-pre-builts.md#allowed-exceptions

dotnet/runtime's Regex source generator is already using this version (4.5.0), so it should be OK to use it in source-build.

FYI - @mthalman

Looks like you need to follow https://github.com/dotnet/source-build/blob/main/Documentation/eliminating-pre-builts.md#allowed-exceptions

dotnet/runtime's Regex source generator is already using this version (4.5.0), so it should be OK to use it in source-build.

FYI - @mthalman

I went ahead and updated the existing exemptions we had for M.CA dependencies to remove the version pin. I noticed that the runtime repo is extremely liberal about what is exempt so I assume not being picky about version numbers is fine.

I noticed that the runtime repo is extremely liberal about what is exempt so I assume not being picky about version numbers is fine.

I don't think dotnet/runtime has the "pre-built" checks working yet.

Requested review from Matt for the prebuilt baseline update