After update to VS 16.9.0: Feature 'init-only setters' is not available in C# 7.3. Please use language version 9.0 or greater

user_1838048 0
Viewed 1739

We have a project that targets netstandard2.0 and that project uses the NuGet package CsvHelper, that is also available as netstandard2.0.

This project contains the class CsvConfiguration that is build as:

public class CsvConfiguration
{
    public virtual string Delimiter { get; init; }
}

And we use this library without any problems in the past. After updating Visual Studio from 16.8.6 to 16.9.0 the above mentioned error message occurs on a build:

error CS8370: Feature 'init-only setters' is not available in C# 7.3. Please use language version 9.0 or greater.

While I understand why this error would occur, if I would use this feature in my own code, I don't know why this happens if a third party library uses it, that is declared to match my framework version.

Is this a bug in the library or in Visual Studio? Cause in VS 16.8.6 it compiles fine and in VS 16.9.0 it fails.

I know, an easy workaround would be to add a <LangVersion> entry within our .csproj file, but is this the recommended way?

csvhelper visual-studio c#
2 Answers

This looks to be a badly-advised breaking change in the library, that was added at the end of January and which has already been reverted. Changing from set to init is a fundamentally breaking change that introduces a modreq which is only understood in recent C# versions.

It is odd that it would compile in VS 16.8.6, and honestly: I find that unlikely - it should fail, but with an error message about an unknown modreq (as opposed to failing but knowing why). I suspect that what is more likely is that you have also updated the library version to the post-January version that introduced the problem, and you're now seeing the failure.

Fixes:

  1. revert to a version before the end of January that doesn't yet have the breaking change
  2. update to a newer version after the revert, that doesn't have the breaking change any more
  3. use <LangVersion> in the csproj to choose a more recent C# version; since the compiler you're using knows what the specific problem is, you definitely have a compliant compiler - it is simply being restricted to down-level C# features

Ultimately, the entire point of modreq (as opposed to modopt) is that the compiler must understand a modreq to use a type/member, but the compiler can silently ignore a modopt if it doesn't understand what it means. I find it unlikely that an old version of the C# compiler was happily ignoring a modreq that it didn't understand.

Marc_Gravell_233540
user_153223190
Related