Project-system: "The specified language version is invalid" warning when using VB LangVersion set to 14.0, 15.0, default, latest

[jcouv]

@0xd4d commented on Sat Aug 19 2017

Version Used: VS2017 15.3.1

Steps to Reproduce:

1. Create a VB project
2. Add <LangVersion>latest</LangVersion> (or 14.0 or later) to the project file and save it
3. Reload the solution in VS
4. Compile
5. Check the 'Error List' window

Expected Behavior:

No warning

Actual Behavior:

Warning "Load of property 'LangVersion' failed. The specified language version is invalid." is present in the Error List window.

---

@jcouv commented on Fri Aug 25 2017

@0xd4d I was not able to repro this issue. Could you make a zip file with your repro project and attach it to the issue? Thanks

---

@jcouv commented on Fri Sep 08 2017

Didn't hear back from you in two weeks. I'll close the issue.
Feel free to re-open if you can add the details to reproduce this. Thanks

---

@memark commented on Mon Mar 19 2018

@jcouv I have the same problem. Please see attached repro.
Repro.zip

---

@memark commented on Mon Mar 19 2018

I might add I'm on VS 15.6.2.

And btw, when using an "new SDK style" VB project instead, there is no warning.

---

@gustavsigma commented on Tue Mar 20 2018

I am also experiencing this issue.

The repro @memark attached does successfully recreate the problem for me.

---

@jcouv commented on Tue Mar 20 2018

Thanks @memark. The attached solution repros the issue for me too (in 15.7 preview 1), showing the error message in the Error List.

One interesting thing is that the IDE otherwise seems to respond to the LangVersion properly (with "15.0" I get squiggles for using a tuple inferred element name, which go away went set to "latest").

@Pilchie I think this is a project-system issue. Can you confirm and route? Thanks

---

@jmarolf commented on Tue Mar 20 2018

@jcouv lets start by moving this to dotnet/project-system

[davkean]

@panopticoncentral @tmeschter Did we hook up language version support for legacy project system? If so, did you support marking it as "latest"?

[memark]

@davkean I did some investigating

CS new project system: all values work
CS old project system: all values work
VB new project system: all values work
VB old project system: values 9, 10, 11, 12 work. higher values (incl latest and default) fail.

I also note that vbc /langversion:? returns

Supported language versions:
default
9
10
11
12
14
15 (default)
15.3
15.5 (latest)
latest

[panopticoncentral]

Could either be missing support in the VB project system, or could be an issue with DTBB translation layer again.

[Pilchie]

This seems to be missing support in the VB project system. Specifically, there is list of possible values at VsProjectProperties.h.

That includes values from 9 to 15, but does not include either latest or default.

Then there are two places that reference that:

1. In the VB Host object, we support values from 9 to 15, and the empty string for default, but we don't support anything for latest.
2. In the VSProjectProperties.cpp we support values from 9 to 12, and nothing else.

The warning in the errorlist comes from 2. AFAICT, it has two effects. First it has the warning. Second, it means the VS automation object will have the wrong value for the language version.

From 1, it wouldn't be possible to set the language version explicitly to latest or default if you end up in a legacy design time build case, but it does work if Allow parallel project initialization is on.

sigh.

[Pilchie]

I submitted a PR to the closed source code for the VB project system to fix this.

[jcouv]

Thanks
Do you know why C# legacy projects don't have the same problem? Could we use whatever solution/design from C# for VB as well? Otherwise, I'm afraid we'll forget to update this when we add next version of VB.

[Pilchie]

The existing codepaths for the C# always passed langver as a string, whereas VB converts it into an enum. Hopefully in 15.8, we'll be simplifying the language service initialization and will just remove all the code that marshals to/from the enum in favor of passing a commandline string, but until then, there isn't really a better option here.

[Pilchie]

I merged the PR here for 15.7 Preview 4.