search

dotnet / source-build

A repository to track efforts to produce a source tarball of the .NET Core SDK and all its components
MIT License
265 stars 132 forks source link

Tracking: Repos targeting .NET 9 SDK #3770

Closed mthalman closed 2 months ago

mthalman commented 11 months ago

This is a tracking issue to identify which repos are currently onboarded to use .NET 9 SDK. This is necessary as a prerequisite to eventually have these repos produce packages that target net9.0.

Repos:

Related to:

dotnet-issue-labeler[bot] commented 11 months ago

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

ViktorHofer commented 11 months ago

We will hit this issue every year again and again. Maybe it would make sense for source-build to use a different SDK than what the non source build infrastructure uses? That would also help with issues like https://github.com/dotnet/runtime/issues/95022#issuecomment-1827826930

mthalman commented 11 months ago

Source build is already using a .NET 9 SDK to build the VMR. The main driver of getting all these repos onto the new SDK is so we can roll out this change: https://github.com/dotnet/arcade/pull/14108. Once that's been rolled out, then we can remove a bunch of source build patches: https://github.com/dotnet/source-build/issues/3663.

ViktorHofer commented 11 months ago

Why not change these properties now when building from source and make repositories use a .NET 9 SDK in their source build legs? We will hit this problem with every release and it would be good to come up with a pattern that works long-term.

mthalman commented 11 months ago

make repositories use a .NET 9 SDK in their source build legs

How would that work? I thought this was all controlled by global.json whether it's for source build or not.

ViktorHofer commented 11 months ago

How would that work? I thought this was all controlled by global.json whether it's for source build or not.

Isn't there an environment variable today that the host respects to specify a different global.json? If not, we should discuss if adding such a feature would be worthwhile.

mthalman commented 11 months ago

Isn't there an environment variable today that the host respects to specify a different global.json? If not, we should discuss if adding such a feature would be worthwhile.

Not that I'm aware of. It's certainly not documented. That's related to https://github.com/dotnet/source-build/issues/3169.

ViktorHofer commented 11 months ago

One possible solution would be to allow major version SDK rollforwards in the individual repos (that's a global.json setting) and then just download a newer SDK. We should be able to change the version that is restored as that is handled via Arcade.

mthalman commented 11 months ago

But regardless of what SDK is used for source build, the issue of rolling out https://github.com/dotnet/arcade/pull/14108 still exists. Not having that rolled out would mean we would need to have a bunch of source build conditions that explicitly set NetCurrent to net9.0. That's not a good solution either. Alternatively, you would iteratively rollout net9.0 in Arcade by first setting NetCurrent in Arcade to net9.0 only for source build. Then once repos have taken the new SDK, NetCurrent in Arcade can be upgraded with no conditions. Still seems like a lot of coordination.

ViktorHofer commented 10 months ago

templating (doesn't consume NetCurrent)

From the list in the top post. What does that mean? I see that they are using a 9.0 Arcade SDK and are currently targeting net8.0.

ViktorHofer commented 9 months ago

All the repos in the list above that don't intentionally stay on an older .NET SDK and Arcade SDK, now upgraded to .NET 9 and Arcade 9. I assume the remaining six repositories will update later around ~June/July when they stop dual-inserting. Except for command-line-api which doesn't dual-inserts but just doesn't want to use the .NET 9 SDK yet.

MichaelSimons commented 2 months ago

I am closing this as its usefulness is over. There are two remaining repos (aspire and command-line-api) that don't utilize a net 9.0 SDK. They both utilize NetCurrent so they are compatible with the product source-build.