Actually, @wtgodbe @Pilchie is it too late for optional 6.0-rc2 infra changes❔ Or, @halter73 is there a reason we need to bump the SDK here❔

Or, @halter73 is there a reason we need to bump the SDK here?

No. I thought I was supposed to since my build-ops rotation fell on a Monday and this branch is still somewhat active.

We do want to ingest the change to make preview features give an error by default, though I'm surprised that's coming in via the SDK update rather than the runtime update - I'll make the changes in a bit to suppress the error for the quic projects (CC @JamesNK @adityamandaleeka @Tratcher)

This is concerning:

/datadisks/disk1/workspace/_work/1/s/src/Servers/Kestrel/Kestrel/src/WebHostBuilderKestrelExtensions.cs(38,17): error CA2252: Using 'KestrelServerOptions' requires opting into preview features. See https://aka.ms/dotnet-warnings/preview-features for more information. [/datadisks/disk1/workspace/_work/1/s/src/Servers/Kestrel/Kestrel/src/Microsoft.AspNetCore.Server.Kestrel.csproj]

Same for KestrelServerImpl. I don't see these using quic, or even HttpProtocols - any idea what gives @pgovind @jeffhandley @jkotas?

Setting <EnablePreviewFeatures>true</EnablePreviewFeatures> will treat every API in the assembly as being a preview feature by generating an [assembly:RequiresPreviewFeatures] attribute. The result is then calling into anything from that assembly from a different assembly (that doesn't opt in to preview feature usage) will see these errors. I believe that's what's causing all of these errors.

@halter73 I suspect you didn't want the result of the entire assembly being treated as preview, and instead only specific APIs were intended to be annotated.

Note, if you also include <GenerateRequiresPreviewFeaturesAttribute>False</GenerateRequiresPreviewFeaturesAttribute>, then preview feature usage is enabled without generating the assembly-wide attribute, but I'm not sure that's the right fix here; I defer to @pgovind and @terrajobst.

Here's the preview of the documentation for this analyzer's behavior, in case that's helpful:
https://review.docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca2252?branch=pr-en-us-26149

So is the fix to mark the call sites with RequiresPreviewFeaturesAttribute? We don't want customers using kestrel without Http3 to have to opt in to using preview features

So is the fix to mark the call sites with RequiresPreviewFeaturesAttribute? We don't want customers using kestrel without Http3 to have to opt in to using preview features

Instead of marking the entire assembly as enabling preview features, new APIs that are Preview Features should be annotated with the attribute. Existing APIs that are going to start calling into those new APIs get tricky, and the approach depends on your intent.

        public static IWebHostBuilder UseKestrel(this IWebHostBuilder hostBuilder)
        {
            hostBuilder.UseQuic();
            return hostBuilder.ConfigureServices(services =>
            {
                // Don't override an already-configured transport
                services.TryAddSingleton<IConnectionListenerFactory, SocketTransportFactory>();

                services.AddTransient<IConfigureOptions<KestrelServerOptions>, KestrelServerOptionsSetup>();
                services.AddSingleton<IServer, KestrelServerImpl>();
            });
        }

In this code, hostBuilder.UseKestrel() is unconditionally calling hostBuilder.UseQuic(), which is a preview feature. If the caller hasn't opted into preview features, then should UseKestrel() be calling UseQuic()?

hostBuilder.UseQuic() does feature detection internally and should suppress any preview warnings. Kestrels preview features are controlled elsewhere.

In that case, I recommend using a #pragma warning disable CA2252 // Preview Features -- UseQuic performs feature detection directive around that API call, and any others that are similar where you're calling a feature-detecting-preview-feature API from a non-preview-feature API. Then you can remove <EnablePreviewFeatures>true</>, returning the assembly as a whole to non-preview-feature mode.

It looks like there are still some call sites that need the pragmas, but the direction here looks good to me.

Just went through the thread here. +1 to Jeff's suggestion. I also just saw the latest commit adding more pragmas. It looks correct.