"Why can't I select a different C# version?" not addressed

[jwfxpr]

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.

---

Document details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 5694e62b-c756-1f62-4014-2ceafa54c011
• Version Independent ID: 3f01c378-22e4-197c-a862-ab4a924506c7
• Content: C# language versioning - C# Guide
• Content Source: docs/csharp/language-reference/configure-language-version.md
• Product: dotnet-csharp
• Technology: csharp-language-reference
• GitHub Login: @BillWagner
• Microsoft Alias: wiwagn

[BillWagner]

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.

[kwaazaar]

You could at least give us an informal answer rihght now.

[BillWagner]

@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.

[jwfxpr]

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.

[cartermp]

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?

[jwfxpr]

@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.

[cartermp]

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 <#16335?email_source=notifications&email_token=ABQEJTTMCGFVTJVXCAPZVQLQZT6XPA5CNFSM4J5A3B2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHNSWSI#issuecomment-568011593>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQEJTUBHSGDZ5H7AWBMVQ3QZT6XPANCNFSM4J5A3B2A>.

[jwfxpr]

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.

[cartermp]

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 <#16335?email_source=notifications&email_token=ABQEJTTDMWCFYBHBUD5ICSDQZUFMXA5CNFSM4J5A3B2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHNY5AI#issuecomment-568036993>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQEJTQLOXAYJM7GTKGB75TQZUFMXANCNFSM4J5A3B2A>.

[jwfxpr]

@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".

[cartermp]

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 <#16335?email_source=notifications&email_token=ABQEJTXPNAA4B75A7RZXNI3QZU7TNA5CNFSM4J5A3B2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHOKCIY#issuecomment-568107299>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQEJTTEICNHCGR4JSEXU7TQZU7TNANCNFSM4J5A3B2A>.

[jwfxpr]

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.

[dannyagle]

Still awaiting a resolution to this problem. 3 weeks seems more than enough time to ask your coworkers.

[cartermp]

@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.

[mason-mcglothlin]

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.

[cartermp]

@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.

[imba-tjd]

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.

[mason-mcglothlin]

@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 a 7.1 element.

The reasoning for this is not solid, and the explanation in the documentation is far from satisfactory.

[cartermp]

@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.

[mason-mcglothlin]

@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.

[cartermp]

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.

[jmoralesv]

If anyone is interested, the disable of the drop down was done in this pull request: dotnet/project-system#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: dotnet/roslyn#37703 (comment)
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.

[ckrausko]

@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

[cartermp]

@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.

[astrowalker]

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.

[gadget00]

hi all,

this is a massive mess; right now I have code that is "stuck" in C#5 and telling me to upgrade to C#7. When I use the Lightbulb Box to "switch this project to C#7 I get an exception error from VS and nothing gets done. The .sln file doesn't have a .csproj to modify either, so it's a dead end for now.

'CSharpUpgradeProjectCodeFixProvider' detectó un error y se ha deshabilitado. Mostrar seguimiento de la pila Habilitar Habilitar y omitir futuros errores

[jmoralesv]

@gadget00 I think this is an older issue so maybe no one else is looking at this. If you are working with a console app, ASP.NET Core or Windows Forms app, you should have a csproj file where you can change the TargetFramework or the LangVersion.

What is your app about, and what version of VS are you using?

[gadget00]

Thank you for answering; it's an ASP.net project on VS Community 17.7.4 and then I tried using the 17.8 Preview, but it doesn't have a proper .csproj file to edit. I managed to see that the web.config file was the one to edit and for some reason updating a "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" package deleted the tags where you could force the version of C# used:

<system.codedom>
    <compilers>
      <compiler extension=".cs" language="c#;cs;csharp" warningLevel="4" 
        compilerOptions="/langversion:latest /nowarn:1659;1699;1701;612;618" 
        type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, 
              Microsoft.CodeDom.Providers.DotNetCompilerPlatform, 
              Version=3.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
      <compiler extension=".vb" language="vb;vbs;visualbasic;vbscript" warningLevel="4" 
        compilerOptions="/langversion:default /nowarn:41008,40000,40008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+" 
        type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, 
              Microsoft.CodeDom.Providers.DotNetCompilerPlatform, 
              Version=3.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    </compilers>
  </system.codedom>

The Git red flag was what alerted me that something was there and got deleted. I added this code and it kind of went through, but now I have other "metadata" missing files error that I'm trying to fix, to finally start to work on the project code.

Still, I feel it is counterproductive to not let the developer pick this through the UI and have to "trust" the IDE on this. In my case, I uninstalled and installed 3 times and couldn't fix this. I'm on my 4th effort and hope I can get it right this time

[cartermp]

FWIW I think this is an older bug you're running into and likely not related to the issue discussed several years ago. It also sounds like you're using an older IDE version, and so I suspect that if it's not already fixed, you'll be asked to upgrade your IDE.

[jmoralesv]

@gadget00 looks like you're working on a web project using ASP.NET under .NET Framework (maybe 4.7.2 or 4.8) in Visual Studio 2022 (version 17.7.4 was released some days ago, so you're not using an older IDE as @cartermp said).

For older ASP.NET web projects under .NET Framework, the C# version can't be modified, because newer C# versions rely on features available in recent SDKs (.NET Core, .NET 6, .NET 7, etc), recent C# versions such as C# 9, 10 or 11 can't work with .NET Framework projects.

If you got warnings about C# 5, maybe your project is targeting .NET Framework 4.5 or older, so you can actually upgrade in the Properties of the project to .NET Framework 4.8 and use C# 7.3. You should have a Properties window and follow the steps here: https://learn.microsoft.com/en-us/visualstudio/ide/visual-studio-multi-targeting-overview?view=vs-2022#change-the-target-framework

If you need more help, I'm happy to help via email (see my profile page). I think this is not the correct issue to ask for help.

[mason-mcglothlin]

hi all,

this is a massive mess; right now I have code that is "stuck" in C#5 and telling me to upgrade to C#7. When I use the Lightbulb Box to "switch this project to C#7 I get an exception error from VS and nothing gets done. The .sln file doesn't have a .csproj to modify either, so it's a dead end for now.

'CSharpUpgradeProjectCodeFixProvider' detectó un error y se ha deshabilitado. Mostrar seguimiento de la pila Habilitar Habilitar y omitir futuros errores

If you have no .csproj, then you are doing a Website project instead of Web Application Project. That's absolutely ancient. Microsoft shouldn't spend any time supporting that old Web Forms tooling at this point. You need to upgrade to ASP.NET Core , where all new feature development is taking place. There's lots of great paths for you to take there. Blazor, MVC, Minimal API or Web API combined with a SPA framework etc.

[BillWagner]

Hi @mason-mcglothlin

can you open an issue in the roslyn repo to report this? The folks there will have a better idea what's wrong in this scenario.

/cc @CyrusNajmabadi

[mason-mcglothlin]

Hi @mason-mcglothlin

can you open an issue in the roslyn repo to report this? The folks there will have a better idea what's wrong in this scenario.

/cc @CyrusNajmabadi

@BillWagner I think you meant to direct that reply to gadget00.

[CyrusNajmabadi]

Our position would be the same: this is an ancient combo of vs and asp, and we're not supporting that anymore. If the same issues arise on asp.net core and the latest VS, please let us know.

[gadget00]

well, I indeed am using the latest VS version, which launched yesterday if I'm not mistaken; so this issue is still a problem to this day. I appreciate the time of those who answered with alternatives rather than whining and berating. What is this? S Overflow? LOL

On the other hand, if you don't want to give support to certain combinations of technologies or types of projects, just drop them from the IDE. Back in the early 2000s MSFT didn't bat an eye when they dropped perfectly working tech like VB6 and VFP just because "we're moving in a different direction now" burying many commercial products and developers in the process. Nowadays if this is 'bothersome' to attend, just drop the ax instead of a tantrum LOL If it's still in the product, you should support it I believe.

Had to reinstall VS Community 2022 5 times today and copy/paste the whole code from another colleague (pulling from Git was giving problems as well) to be able to work. Tooling for web apps development shouldn't be such a troubling endeavor in 2023, but here we are. Thanks again to those that tried to help

[mason-mcglothlin]

@gadget00 No one here is berating you. It is important though that you understand the reality of the situation so that you can make appropriate plans. You're using tech that's nearly two decades old. That's pretty much an eternity in web development times. Expecting Microsoft to keep this tooling up to date is not realistic. If you want to have solid features and expect support for those features, you need to be on a reasonably up to date piece of tech.

I know that may be frustrating to hear. But fortunately migrating is generally not too difficult, and even if you don't want to do it yourself there's plenty of others who can assist. I myself am quite active on Stack Overflow and still willing to answer questions about Web Forms, and there's lots more who are familiar with ASP.NET Core and the more recent frameworks it includes. I'd encourage you to upgrade if this app is something you must maintain, it will reduce your frustration.

[gadget00]

@mason-mcglothlin thank you for the observation. I wish I had a say in the project to tell them to upgrade, but I'm not the owner of the code so I have to work with what is in production right now. Maybe in the future we could migrate to .net core but for now this 'old (and not well understood I see) bug' was a problem in an active codebase today and that shouldn't be imho

[CyrusNajmabadi]

well, I indeed am using the latest VS version,

If you can repro this issue in the latest version of VS, please file a repro over at dotnet/Roslyn so we can investigate. Thanks @gadget00

[CyrusNajmabadi]

and that shouldn't be imho

What bug are you referring to specifically? I want to make sure I understand and the we're not talking about different things @gadget00 thanks!

[gadget00]

@CyrusNajmabadi I refer to at least 3 mishaps:
1- the lack of selection of the C# version in the project (that's more of a design decision I think)

2- the automated deletion of the entire <system.codedom> tag after updating the "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" package

3- the CSharpUpgradeProjectCodeFixProvider getting disabled after detecting a stack error in the IDE, when trying to use the Lightbulb Box recommendation to upgrade the C# language of the project to the recommended version. In my case it recommended C#6.0 and C#7.0 at times and both cases triggered the same error

[CyrusNajmabadi]

@gadget00 can you file '2' and '3' (as separate issues) over at dotnet/roslyn, with repros, so we can investigate/fix. '1' is not something we will change and is an explicit design decision.

I was unable to repro the other issues, so there is something specific about your project. Having a repro case will help us find/fix asap. Thanks! :)