Add alpha branding

[SimonZhao888]

No description provided.

[github-actions]

This PR is targeting main, which is now for .NET 11-facing work. If you intended to target .NET 10, either retarget this PR to release/10.0.1xx or make sure you backport the change to release/10.0.1xx after merging. See #50394 for more details.

[Copilot]

Pull Request Overview

This PR updates the versioning configuration to add alpha branding by incrementing the major version from 10 to 11 and changing the pre-release label from "rc" (release candidate) to "alpha".

• Incremented major version from 10 to 11
• Changed pre-release label from "rc" to "alpha" for unstable packages

[marcpopMSFT]

make sure to record this in the main tracking issue as this is a new item we'll need to unwind as we move to 11 that we didn't have last year

[marcpopMSFT]

@tmat @dotnet/run-file There are a lot of watch and runfile tests that appear to depend on a hardcoded version check. Can ya'll take a look at fixing that so we can rebrand to 11 (and in the future, more easily to 12)?

[jjonescz]

(and in the future, more easily to 12)

It should be as easy as changing the following I believe:

sdk/test/Microsoft.NET.TestFramework/ToolsetInfo.cs

Line 11 in 97bc396

public const string CurrentTargetFramework = "net10.0";

At least that's what I've been using for run-file tests (but it's a pre-existing constant that many other tests are also using). Should we be using something else?

[marcpopMSFT]

@jjonescz we don't have net11 templates yet. Can we retarget all these tests to 10 for now using a PreviousTargetFramework value and then find/replace that later?

CC @SimonZhao888

[jjonescz]

Looking closer, some basic run-file tests (like RunFileTests.FilePath) are failing with

error NETSDK1045: The current .NET SDK does not support targeting .NET 11.0. Either target .NET 10.0 or lower, or use a version of the .NET SDK that supports .NET 11.0. Download the .NET SDK from https://aka.ms/dotnet/download

Is that expected to be broken? dotnet run file.cs targets the current TFM under the hood. The basic tests don't do any hard-coded version checks, so that's not the problem here.

We could add an explicit #:property TargetFramework=net10.0 to the tests, but then we won't be testing the real product.

I guess the problem is that you want to brand the SDK as 11.* but keep the "current" TFM as net10.0? The I can just change computation of this property:

sdk/src/Cli/Microsoft.DotNet.Cli.Utils/Product.cs

Line 12 in 39844e2

public static readonly string TargetFrameworkVersion;

[SimonZhao888]

@tmat, could you please take a look at these failure dotnet-watch cases:
Microsoft.CodeAnalysis.MSBuild.RemoteInvocationException : An exception of type System.InvalidOperationException was thrown: We don't have an MSBuild to use; HasUsableMSBuild should have been called first to check. - file BuildHost.cs line 150

[SimonZhao888]

@SimonZhao888 @DonnaChen888 I talked a bit with folks offline. To fix the watch tests correctly, it's giong to take an 11 runtime and that's a long way away. The next recommendation is to see if we can downtarget any of those watch tests at net10 to get them unblocked. If that doesn't work, disable them.

Can you do it in a way that'll be easy to undo later (like TransitionTargetFramework when targeting net10 and we can switch that to net11 later without having to go update all the tests maybe)? I'm just trying to think of ways of making this easier next year.

Got it! We will do it!

[SimonZhao888]

@marcpopMSFT I had disabled the failing test cases and using #51491 to track them.

[marcpopMSFT]

Same issue as #51557

[marcpopMSFT]

@DonnaChen888 Looks like this was created back when rc.1 was publicly available. With GA releasing tomorrow, let's update all of the spots we have rc.1 to point at the GA versions and try to get this merged later this week.

It's passing all checks (other than known failures) so I think we're good to go later this week. I just didn't want it to go in with rc.1 which was a while ago now.

[marcpopMSFT]

@DonnaChen888 I think the last leg is just hitting our known templating issue but I can't tell if there are any real failure in there. We're free to merge this once the build analysis check passes.