CODEWITHSUNDEEP
c#versioncompatibility.net-4.8
MBeckius
MBeckius

Reputation: 1527

Is <LangVersion>latest</LangVersion> safe in a .NET Framework project?

We have a .NET Framework 4.x project that has the language version set to the following:

<LangVersion>latest</LangVersion>

According to the documentation

The latest C# compiler determines a default language version based on your project's target framework or frameworks. Visual Studio doesn't provide a UI to change the value, but you can change it by editing the csproj file. The choice of default ensures that you use the latest language version compatible with your target framework. You benefit from access to the latest language features compatible with your project's target. This default choice also ensures you don't use a language that requires types or runtime behavior not available in your target framework. Choosing a language version newer than the default can cause hard to diagnose compile-time and runtime errors.

It is unclear to me; by using "latest" for the langversion, could we get runtime errors because we have inadvertently used a language feature that is not properly supported by the runtime?

For example, with langversion latest, we are able to use the new() operator and using declarations which are supported in C# 8.0 and above even though the .NET Framework only supports up to version 7.3.

Upvotes: 8

Views: 3836

Answers (1)

Andrey Pelepets
Andrey Pelepets

Reputation: 21

It is unclear to me that if we use "latest" for the langversion could we get run-time errors, because we have inadvertently used a language feature that is not properly supported by the runtime? For example, with langversion latest we are able to use the new() operator and using declarations which are supported in c# 8.0 and above even though the .net framework only supports up to version 7.3.

I suppose runtime errors mainly related to "latest", which can be suddenly switched from 10.0 to 11.0, from 11.0 to 12.0 etc. - during updating of Visual Studio. There are no guarantees that for example some ultra new C# 12 will be fully compatible with .NET Framework 4.x at runtime level.

So I prefer to use exact value of LangVersion for .NET Framework - 9.0 is enough for me now.

AFAIK tandem of .NET Framework and C# 9.0 don't have significant potential runtime errors, at least if you are using syntax sugar part of C# 9 only.

In any case, rest things C# 9 (not related to syntax sugar part of C# 9) should be used carefully, as described in below link.

While we still have some features left in C# 8 and 9 that can work on our older targets, these remaining ones will need some extra care in order to make the Roslyn compiler happy. Specifically, these are features that are backwards compatible, but do need some specific types or attributes to be present in the project. The good news is that if we are missing libraries we can just reference them from NuGet, and if we miss types we can literally just copy them from the CoreCLR source on GitHub and paste them into our project! The C# compiler does not actually need those types to be built-in — as long as it can find them in the right place, that will be enough for it to successfully build our code. So, let’s go through all the remaining features one by one!

https://sergiopedri.medium.com/enabling-and-using-c-9-features-on-older-and-unsupported-runtimes-ce384d8debb

Upvotes: 2

Related Questions