I have my LangVersion set to 5 and I'm getting suggestions about using a null propagating operator. Since that feature isn't supported with C# 5 it should not be making this suggestion. I have confirmed that VS 2017 does not have this behavior.
I have my LangVersion set using a .targets file referenced in my .csproj (if that makes a difference not sure).
_This issue has been moved from https://developercommunity.visualstudio.com/content/problem/554113/visual-studio-2019-suggests-code-changes-that-aren.html
VSTS ticketId: 860907_
_These are the original issue comments:_
Visual Studio Feedback System on 5/4/2019, 11:46 PM (81 days ago):
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
_These are the original issue solutions:_
(no solutions)
Proposed that this be expanded to not just be for explicit, but also _effective_ langversion.
I also get this problem without an explicit langversion - I'm using .Net Framework and so can't get C# 8 language features. It keeps suggesting changes and when I tell it to make them, it immediately marks it as an error due to compatibility.
For example:
public ProjectHubCommercial Commercial => commercial ?? (commercial = JsonConvert.DeserializeObject<ProjectHubCommercial>(CommercialJson));
it wants to change the ?? to ??= but Framework is limited to C# 7.3.
@scott-moxham-kf
You cannot use C# 8 for .NET Framework targeted projects.
You can only use C# 8 for .NET Core 3.0 or .NET Core later versions (including the upcoming .NET 5.0) targeted projects.
This limitation is mentioned at this official docs article: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version
It is mentioned quite clear:

@eriawan This is my point.
I cannot use C# 8 due to .Net Framework but VS is still suggesting changes that require C#8.
It's not a useful suggestion if it's incompatible and lots of suggestions make me less likely to look at the ones that would be useful. It should never suggest changes that are incompatible with my project.
@eriawan not supported does not mean not working, some of the types required by individual features can be supplied by the project.
I don't see why ??= shouldn't be working in .NET Framework, unless, of course, it is blocked for marketing reasons.
@scott-moxham-kf
oh, apologize! I understand your point clearly now. I was thinking I had to point out the official mention about the fact that C# 8.0 only supports .NET Core 3.0 or later projects.
This is clearly a bug at Roslyn side, it should not offer C# 8.0 (or later) related code suggestions at all if the currently opened project is solely targeted to .NET Framework.
But before we start to fix this, there are some possible scenarios need to be considered and addressed.
@sharwell
I'd like to start to work on this issue. But I need to confirm with you or the rest of dotnet/roslyn team first, because I start to think about the possibility of some scenarios to be considered that may cause the fix for this issue may not be feasible and also the possible scenarios are exploding.
For example, if the project is using SDK model but it has multiple TFM of netcore and NET Fx inside <TargetFrameworks> in the csproj. How the code suggestions should behave, then?
I think I may open a new separate github issue to act as proposed workaround and possible scenarios discussions for this issue first.
@miloush
about this:
I don't see why ??= shouldn't be working in .NET Framework,
I agree that ??= is a very useful/handy features that should be made available in .NET Framework as well, especially it is not related to .NET Core at all.
on this:
unless, of course, it is blocked for marketing reasons.
Sorry, I'm not the right person to comment or to answer on that. I'm not MS employee 馃檪
About the need for the ??= should be available in .NET Framework, I think it's a separate problem.
Please open a new issue and you should mention @dotnet/roslyn team directly on why ??= operator is only available on C# 8.0 or later.
... because I start to think about the possibility of some scenarios to be considered that may cause the fix for this issue may not be feasible and also the possible scenarios are exploding ...
I'd start with _just_ the ?. issue, which is the one originally indicated above. Similar issues affecting other features would be filed and implemented separately.
For example, if the project is using SDK model ... How the code suggestions should behave, then?
Fortunately the SDK and target framework are irrelevant for implementing a fix for this issue. The only thing to consider is the CSharpParseOptions.LanguageVersion property. This property will be correct both when the language version is explicitly specified in a project, and when it is implicitly provided by the SDK.
Most helpful comment
I'd start with _just_ the
?.issue, which is the one originally indicated above. Similar issues affecting other features would be filed and implemented separately.Fortunately the SDK and target framework are irrelevant for implementing a fix for this issue. The only thing to consider is the
CSharpParseOptions.LanguageVersionproperty. This property will be correct both when the language version is explicitly specified in a project, and when it is implicitly provided by the SDK.