When trying to change the C# version on my project, in the Advanced Build Settings dialog box I found the language version drop-down greyed out, with a link saying "Why can't I select a different C# version?" This link directed me to this page, which doesn't address this question at all.
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
Thanks for pointing this out @jwfxpr
We should be more clear about the reasoning behind this. I've added it to our backlog to address in the near future.
You could at least give us an informal answer rihght now.
@kwaazaar I'm checking with some folks internally to make sure I have the correct explanation. I will post an answer as soon as I can.
I suspect that you're going to find that the answer is actually "Due to a bug affecting the latest version of VS2019."
Microsoft Visual Studio Community 2019
Version 16.4.2
@kwaazaar, if you are trying to figure out why your .NET Framework project is _not_ in fact using the listed C# language version (C# 7.3) and has downgraded you to 6, and the methods listed here for manually changing the language version are being ignored by VS, I had to download the latest .NET Framework (4.8) from https://dotnet.microsoft.com/download/visual-studio-sdks, change my project to target this framework (when in fact I need to be targeting 4.0), and only then would VS compile my project in a C# version higher than 6.
The document intends to answer the question in the tooling in the first two paragraphs:
The latest C# compiler determines a default language version based on your project's target framework or frameworks. This is because the C# language may have features that rely on types or runtime components that are not available in every .NET implementation. This also ensures that for whatever target your project is built against, you get the highest compatible language version by default.
The rules in this article apply to the compiler delivered with Visual Studio 2019, or the .NET Core 3.0 SDK. The C# compilers that are part of the Visual Studio 2017 installation or earlier .NET Core SDK versions target C# 7.0 by default.
Is that insufficient?
@cartermp, entirely insufficient, yes.
"determines a default language version" et cetera would explain why a _default_ language was selected. That would be fine, if one wanted an explanation of why a certain default were chosen.
That is not the question under consideration. It is not at all clear why no choice other than that default version is _permitted to the user_, either upwards nor downwards.
In this case, further in the paragraph is the explanation - to ensure you get a highest compatible language version. Adjusting this default is explained further below. Does that work?
On Fri, Dec 20, 2019, at 09:33, jwfxpr wrote:
@cartermp https://github.com/cartermp, entirely insufficient, yes.
"determines a default language version" et cetera would explain why a default language was selected. That would be fine, if one wanted an explanation of why a certain default were chosen.
That is not the question under consideration. It is not at all clear why no choice other than that default version is permitted to the user, either upwards nor downwards.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/dotnet/docs/issues/16335?email_source=notifications&email_token=ABQEJTTMCGFVTJVXCAPZVQLQZT6XPA5CNFSM4J5A3B2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHNSWSI#issuecomment-568011593, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQEJTUBHSGDZ5H7AWBMVQ3QZT6XPANCNFSM4J5A3B2A.
I... _believe_ you're trying to be helpful, @cartermp, but repeating the text of the document we've already read many times with increasing frustration that didn't sufficiently answer our questions any of those tones is simply not helpful.
So, to answer your redundant question, no. That doesn't work, for two reasons.
Firstly, those options (Edit the project file, Configure multiple projects) _do not work_, and it isn't clear that they are supposed to work in the event that I can't select a different C# version. The wording in Visual Studio literally says can't. It is reasonable to assume that can't means can't. And then, if one assumes those solutions _are_ in fact intended to be some kind of answer, one tries manually editing and reloading ones project again and again in different combinations to find that the advice you repeated is _not_ a solution and is _not_ a way to change the language which, to repeat, Visual Studio tells you you can't do.
Secondly, the explanation your describe is still explaining _why the default has been chosen_, not _why the default cannot be changed_.
It would be _just great_ if any further comments on this issue were focused on enhancing or correcting information, not redundantly and slavishly repeating what I have read again and again. Thank you for your help, but next time make it helpful.
If the stated ways to override a default does not work for you, that is a product issue which should be fixed. I haven’t seen an issue about this yet, but if you have a link to an open issue could you point me at it? Thanks!
The answer to your question is stated in this document: the default is chosen to ensure everything works for your environment, which was not the case prior to VS 16.3. This is simply a product change: the way you might have done things in the past is now different.
On Fri, Dec 20, 2019, at 10:30, jwfxpr wrote:
I... believe you're trying to be helpful, @cartermp https://github.com/cartermp, but repeating the text of the document we've already read many times with increasing frustration that didn't sufficiently answer our questions any of those tones is simply not helpful.
So, to answer your redundant question, no. That doesn't work, for two reasons.
Firstly, those options (Edit the project file, Configure multiple projects) do not work, and it isn't clear that they are supposed to work in the event that I can't select a different C# version. The wording in Visual Studio literally says can't. It is reasonable to assume that can't means can't. And then, if one assumes those solutions are in fact intended to be some kind of answer, one tries manually editing and reloading ones project again and again in different combinations to find that the advice you repeated is not a solution and is not a way to change the language which, to repeat, Visual Studio tells you you can't do.
Secondly, the explanation your describe is still explaining why the default has been chosen, not why the default cannot be changed.
It would be just great if any further comments on this issue were focused on enhancing or correcting information, not redundantly and slavishly repeating what I have read again and again. Thank you for your help, but next time make it helpful.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/dotnet/docs/issues/16335?email_source=notifications&email_token=ABQEJTTDMWCFYBHBUD5ICSDQZUFMXA5CNFSM4J5A3B2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHNY5AI#issuecomment-568036993, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQEJTQLOXAYJM7GTKGB75TQZUFMXANCNFSM4J5A3B2A.
@BillWagner, does @cartermp represent the official response to this? I'm tired of explaining to him why he's wrong, and his passive-aggressive, counter-productive "responses".
I’m sorry you feel that the answer is not satisfactory, but this is the official position. If the product does not behave as documented, then that is an issue that will be resolved. Is the problem of overriding a default occurring with the latest Visual Studio?
On Fri, Dec 20, 2019, at 14:14, jwfxpr wrote:
@BillWagner https://github.com/BillWagner, does @cartermp https://github.com/cartermp represent the official response to this? I'm tired of explaining to him why he's wrong, and his passive-aggressive, counter-productive "responses".
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/dotnet/docs/issues/16335?email_source=notifications&email_token=ABQEJTXPNAA4B75A7RZXNI3QZU7TNA5CNFSM4J5A3B2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHOKCIY#issuecomment-568107299, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQEJTTEICNHCGR4JSEXU7TQZU7TNANCNFSM4J5A3B2A.
Yes. It is. I thought I made that clear.
I'll be unsubscribing from this now, since I don't want to interact with you any more.
Still awaiting a resolution to this problem. 3 weeks seems more than enough time to ask your coworkers.
@dannyagle The rationale for why a default language version is documented, as are workarounds. To the question of why one cannot toggle something in the UI that used to be toggle-able, the answer is that it was a deliberate product change to support how C# is evolving. If the stated workarounds aren't working for you, please do file an issue because that would indicate a product bug that needs resolving.
I'm building a project that targets .NET 4.8, and I keep getting the error message:
Feature 'async main' is not available in C# 7.0. Please use language version 7.1 or greater.
Where before I could have modified my project to explicitly target a language version, I now have no control. @cartermp You're saying that this was done to better support how the language is evolving - but it sure seems like a regression to me.
Only happens on our build agents for TFS, which are likely contain older copies of VS. But still - this scenario should have been envisioned by MS.
@mason-mcglothlin You're seeing that error because somewhere in your build you have LangVersion explicitly set to C# 7 (often done to give a consistent experience for people/teams round-tripping projects through older/newer VS instances), or if it is in CI, you are using older images that do not have VS 2019 installed. Since VS 2019 has shipped with C# 7.3 as a default since the 16.0 release, I don't think this is related to your problem. You would have observed the same issue when VS 2019 and C# 7.3 came out last March.
One possible reason: You had changed the language version of your project, but after an update of VS, the drop list was locked. And even when the value of <LangVersion> is not latest, VS still shows "Automatically selected based on framework version".
The solution is simple: Find and replace the value of <LangVersion> in your project to latest outside of VS.

@cartermp Here's the message I had to post to my team:
If your build works locally but in TFS you get errors like:
Error CS8107: Feature 'async main' is not available in C# 7.0. Please use language version 7.1 or greater.
Error CS5001: Program does not contain a static 'Main' method suitable for an entry point
And you can't modify the language in VS because it says "Automatically selected based on framework version" then congratulations! You've hit a breaking change that Microsoft made. VS 2019 now chooses your C# version based on the version of .NET you're using, and doesn't include a LangVersion element in the csproj. However VS 2017 (such as our TFS build agents) wasn't updated to be aware of this, so it defaults to like C# 6 for .NET Framework projects, so certain features like "async main" won't work. To fix it, I was able to manually modify the .csproj and add a7.1 element.
The reasoning for this is not solid, and the explanation in the documentation is far from satisfactory.
@mason-mcglothlin That isn't quite right. The error you're seeing in build agents isn't new to VS 2019 and isn't related to the recent behavior of tying the default LangVersion to a framework. You would have seen the same issue if this were VS 2017 with C# 7 syntax and your build agents only used VS 2015 (which comes with a compiler that only understands C# 6 syntax). This has been the case since VS and C# have shipped in tandem.
@cartermp Yes, it absolutely is related. Because before to fix this I could have simply opened up the project in VS and set the LangVersion. Now I have to manually modify the .csproj. And the explanation for this reasoning makes little sense, and the documentation doesn't even cover the explanation or the change in behavior adequately.
However VS 2017 (such as our TFS build agents) wasn't updated to be aware of this, so it defaults to like C# 6 for .NET Framework projects, so certain features like "async main" won't work
I just want to reiterate that this has always been the case and if no change to C# language versioning or VS 2019 were made, you would still see this behavior. The wording implies that you wouldn't, which is untrue. TFS build agents with an older VS don't understand newer C# language versions unless they are upgraded. So this issue isn't new and isn't related to the change to tie an implicit LangVersion set by tooling (in this case, VS 16.3 or higher) to the flavor of .NET you're using. The difference is that the UI for setting that LangVersion explicitly yourself no longer exists because
I'm not sure your fix to the problem you're seeing is right, either, unless I misread what you wrote earlier. If one machine has a newer compiler that understands a newer language version (C# 7.x) and another does not, the answer is to either restrict the language version to be the lowest common denominator or upgrade all machines involved. Setting the LangVersion to be higher will result in anyone who has a machine with an older build environment/compiler getting an issue with their compiler not recognizing the explicit LangVersion.
I don't think we're going to explain a change to VS UI in this document. VS UI changes happen all of the time as products evolve. In this case, C# has evolved such that your maximum default LangVersion is C# 7.3 for .NET Framework projects, and so tooling has changed to reflect that.
If anyone is interested, the disable of the drop down was done in this pull request: https://github.com/dotnet/project-system/pull/4923, you can read and see the lack of rationale behind it. I think this was a bad decision, so hopefully it can be rolled back in the future, to something just like this: https://github.com/dotnet/roslyn/issues/37703#issuecomment-523557058
In the meantime, if anyone has already reported this issue in https://developercommunity.visualstudio.com/ please let me know, so I can upvote it in there.
@cartermp Why do I have to manually set LangVersion to latest in the csproj to get C# 8.0 when I'm using netcoreapp3.1 ? It was defaulting to using 7.3 and saying I can't change the version in properties. Isn't it supposed to default to version 8 since I'm using .netcore 3.0+?
@jmoralesv I'm not sure why you're confused facing me. The docs literally say 3.x defaults to C# 8.0 but in my case it did not and I had to explicitly define "latest" in csproj.
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version#defaults
@ckrausko You shouldn't need to. Was it already set manually to C# 7.3 before, or are you using a preview SDK? There was a preview SDK version with a bug that defaulted to C# 7.3 but that was resolved before the release.
So how this problem was addressed finally? I am asking because all I can see is more explanation why the DEFAULTS are this or that way.
Most helpful comment
I... _believe_ you're trying to be helpful, @cartermp, but repeating the text of the document we've already read many times with increasing frustration that didn't sufficiently answer our questions any of those tones is simply not helpful.
So, to answer your redundant question, no. That doesn't work, for two reasons.
Firstly, those options (Edit the project file, Configure multiple projects) _do not work_, and it isn't clear that they are supposed to work in the event that I can't select a different C# version. The wording in Visual Studio literally says can't. It is reasonable to assume that can't means can't. And then, if one assumes those solutions _are_ in fact intended to be some kind of answer, one tries manually editing and reloading ones project again and again in different combinations to find that the advice you repeated is _not_ a solution and is _not_ a way to change the language which, to repeat, Visual Studio tells you you can't do.
Secondly, the explanation your describe is still explaining _why the default has been chosen_, not _why the default cannot be changed_.
It would be _just great_ if any further comments on this issue were focused on enhancing or correcting information, not redundantly and slavishly repeating what I have read again and again. Thank you for your help, but next time make it helpful.