Will C#8 be supported on the .NET Framework?

[kingboyk]

I'd be really grateful if you could clear up some uncertainty I (and others) have regarding the blog post Building C# 8.0; specifically, will C# 8 be available for use in .NET Projects - minus the features which required CLR changes - or will .NET not be supported at all?

The statement "C# 8.0 is only supported on platforms that implement .NET Standard 2.1" is perfectly clear, but there are conflicting signals elsewhere, such as C# 8 being available to .NET Standard 2.0 projects and Microsoft employees working on tooling for C#8 support in legacy csproj format files.

[There was some discussion in an earlier issue but that fizzled out some months ago].

[HaloFour]

IIRC, the only feature that definitely won't appear on .NET Framework is DIM (default interface methods) as that requires runtime changes. The other features are driven by the shape of classes that might never be added to the .NET Framework but can be polyfilled through your own code or NuGet (ranges, indexes, async iterators, async disposal).

[Gnbrkm41]

I suppose it'd be just like things we had already; ValueTuple requiring a separate package on .NET Frameworks 4.6, and stackalloc assignment to Span<T>s working fine provided that you have System.Memory package. As HaloFour mentioned, DIM requires addidional runtime supports so will not happen; however, I suppose that things like switch expressions, recursive patterns etc should work fine given that they can be implemented with existing ILs / runtime support. One big thing that'd be missing would be the framework nullability annotations, though, just like how .NET Framework BCLs don't have any Span based overloads.

[benbhall]

I think this is answered now by https://github.com/dotnet/corefx/issues/40039.

[NetherGranite]

Is there a timeline as to when C# 8 features will begin landing in .NET Framework?

[HaloFour]

@NetherGranite

From everything I've read it sounds like those required BCL types will never be added to the .NET Framework proper. Nor does it sound like Microsoft will publish official NuGet packages to polyfill those types. Third-party NuGet packages will likely appear to polyfill the types necessary to support most of the language features. However, DIM (default interface methods) will never come to .NET Framework as that requires changes to the underlying runtime.

[benbhall]

As @HaloFour says :) .. types quicker than me!

I've not got link handy but if you look at the talks from the first day of .NET Conf this year, use of C# 8 outside of Core 3.0 is addressed.

[svick]

@HaloFour

Nor does it sound like Microsoft will publish official NuGet packages to polyfill those types.

There is Microsoft.Bcl.AsyncInterfaces, which should let you use async streams on .Net Standard 2.0 frameworks (including .Net Framework).

[cartermp]

C# 8 will not be supported on .NET Framework. We don't stop you from targeting it - see how to use it in these docs - but we're not committing to fixing any issues that may arise from this action either.

The official word is at the bottom of this blog post: https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/

New applications should be built on .NET Core. .NET Core is where future investments in .NET will happen. Existing applications are safe to remain on .NET Framework which will be supported. Existing applications that want to take advantage of the new features in .NET should consider moving to .NET Core.

[hfickes]

We use Microsoft Office VSTO and it is still on framework 4.8.1, so we're still stuck there 6 years later.

[NetherGranite]

I was finally able to find this comment on another thread that actually outlines which parts of C# 8.0 are (unofficially) supported in .NET Framework.

It would be nice if this hard-to-find information were aggregated in documentation somewhere; repeatedly hearing ".NET Framework will never officially support C# 8.0" is not helpful to the many people left in an incredibly awkward spot by how unnecessarily monolithically this shift has been executed.

[fowl2]

It would be really awesome if we could get a response to this comment - especially to clarify this:

(1) We will support library authors using C# 8 to build null-annotated libraries targeting .NET Standard 2.0. However, even in .NET Standard, this doesn't make all of C# 8 supported, only this particular subset. The goal of this effort is to allow library developers to have a single binary that they can use from .NET Standard 2.1/.NET Core 3.0 and see null annotations without having to give up .NET Framework support.

This seems fraught: as long as there's no tooling/guide rails it's far far too easy to fall off the cliff into unsupported territory without any warning. Also this comment seems to be the only places this is documented.

(as an aside: sayings that things are only allowed for first party libraries like Azure is incredibly disheartening to hear)