Version of Microsoft.DotNet.Arcade.Sdk to use for MSBuild

[f-alizada]

MSBuild is shipped with .NET SDK hence we are retargetting TF to .NET 9 and moving to the Arcade sdk 9.
.NET 9 is STS however at the same time VS 17.12 is LTSC.
Could you please let us know what would be the solution for this specific case?

[mmitche]

MSBuild is shipped with .NET SDK hence we are retargetting TF to .NET 9 and moving to the Arcade sdk 9. .NET 9 is STS however at the same time VS 17.12 is LTSC. Could you please let us know what would be the solution for this specific case?

When does 17.12 go out of support?

If fixes are required after the .NET SDK is out of support, the solution would be to move your branch forward onto a newer .NET SDK (.NET 10 probably), while still targeting net9. Arcade will not prevent this. You could also move onto a newer Arcade if required.

[missymessa]

Not an ops issue. Related to Arcade. Moving to the Arcade repo.

[rainersigwald]

When does 17.12 go out of support?

We don't know yet, unfortunately.

[rainersigwald]

If fixes are required after the .NET SDK is out of support, the solution would be to move your branch forward onto a newer .NET SDK (.NET 10 probably), while still targeting net9. Arcade will not prevent this. You could also move onto a newer Arcade if required.

The concern is the inverse, actually: we'll almost certainly need newer Arcade but may not be able to bump .NET SDK version due to coupling in our repo. That should be less now but probably won't be gone for 17.12.

[mmitche]

Unfortunately it doesn't end up working that well. The newer Arcade would end up dragging up the SDK. We take dependencies on newer functionality. For instance, it ends up targeting the newer TFM for build tasks.

What kind of problematic coupling exists? Today MSBuild builds with the newer SDK in source build + VMR modes.

[rainersigwald]

A bunch of our tests overlay the just-built MSBuild onto some known-good SDK and use that to build stuff--historically that's been "the one we used to build ourselves" requiring TF matching.

dotnet/msbuild#10282 adds much more separation but I don't know what will break if we build with SDK 10.

[mmitche]

We're in a tough spot then. No matter what you're going to end up on some out of support product. It's likely that we will end up in some unresolvable situation that forces an upgrade. For instance, a 9.0 runtime package dependency that arcade depends on might be vulnerable, but there will be no way to fix it without updating to a .NET 10 version, which may force an upgrade of the SDK/runtime.

[mmitche]

When does 17.12 go out of support?

We don't know yet, unfortunately.

Do we have a ballpark estimate? Is it 10 years?

[f-alizada]

I do not have estimatesions on that.

Do we have a ballpark estimate? Is it 10 years?

May I clarify:
If there are any blockers on merging the retargeting dotnet/msbuild#10484, having that if the fix will require the upgrade to the newer version of Arcade: #14991 (comment)

Am I missing something that actually blocks us from doing that, or just complicates things in future?
@rainersigwald @mmitche

[mmitche]

I don't think there are any blockers to merging the PR but I'll defer to @rainersigwald on that. Whether or not you stay on .NET 8, there may come a point when VS is in support but .NET/Arcade is not. Moving to 9 might make that slightly more likely (since 9 will go out of support ~6 months before .NET 8), but either way it would be good to have a story for moving forward on Acade/.NET without adversely affecting the repo.