dotnet / project-system

The .NET Project System for Visual Studio
MIT License
969 stars 387 forks source link

Make UpgradeProject work for VB #3141

Open jinujoseph opened 6 years ago

jinujoseph commented 6 years ago

The driving scenario is tuple inferred names (#18374) (VB 15.3).

Update: also VB 15.5 features.

ported from https://github.com/dotnet/roslyn/issues/18694

jcouv commented 6 years ago

We need to confirm with @KathleenDollard, but last I heard this was holding back announcing features released in VB point releases. I'm hoping we can schedule this for 16.0 at least (along with related change for warning versions, tracked by https://github.com/dotnet/roslyn/issues/1580).

jcouv commented 6 years ago

Tagging @KathleenDollard

paul1956 commented 6 years ago

@KathleenDollard not sure this is the right place to address this but why doesn't the latest VS version automatically set the compiler version to the latest? VS 2017.7.5 with VB 15.5 set VB compiler version to 15 not 15.5.

jcouv commented 6 years ago

@paul1956 The default project setting (which most people keep, since it's the default) is LangVersion = default. That means "latest major version". If you want to change your project to use the "latest minor version", use LangVersion = latest.

paul1956 commented 6 years ago

@jcouv I don't see default or latest or anything else a user can set. I know there is "plan" to allow users to set this in the IDE, but can you verify that "default" is actually stored somewhere? Or is the lack of anything stored just giving me "Default" and this unexpected behavior.

jcouv commented 6 years ago

If LangVersion doesn't appear in the project file, you can check its effective value by running msbuild with option '/bl' (which produces a binary/structured log, see "msbuild structured log viewer"). As I said, "default" is the default and it means "latest major version". That should answer your earlier question. If the property isn't explicit in the file, then to modify it, you must add it.

jjmew commented 5 years ago

This is tracked internally in https://dev.azure.com/devdiv/DevDiv/_workitems/edit/823507

tmeschter commented 5 years ago

Tom's triage notes: I don't think I fully understand what this issue is about.

If it is about surfacing a project property than I recommend we fix it for the new project system, but not CSProj.

tmeschter commented 5 years ago

Spoke with @jcouv: The essence of this issue is that in C# code dotnet/roslyn can provide a code fix that updates the project file with a newer C# language version. We can't do the same for VB because we don't expose the VB language version property through the project system. I recommend fixing this for CPS, but not the CSProj project system.

KathleenDollard commented 5 years ago

@tmeschter: So the project file supports it and it is used by Visual Studio (I just checked) but we can't get at the value to change it? This is unfortunate. Most VB customers are on .NET Framework and would like to be able to use tuples and several other features.

(LangVersion in the project file must be supported to some degree to be used all the places it is.)

paul1956 commented 5 years ago

I VS2019 2.0 Preview 3, you can set VB Language version to 16, and use all the new features but you get a warning. I have had mixed results setting it to latest or leaving it out and while I have seen mention of Preview, for VB that does not work and version is set to 15. I would have expected that for VS 2019 leaving it out would have defaulted to 16 or at least 15.5, not 15 and when upgrading a project I would expect it leave version alone but when I use a new feature offer the option to upgrade the version number to one that support the feature as is done in C#. image

drewnoakes commented 5 years ago

@paul1956 it sounds like you're hitting https://developercommunity.visualstudio.com/content/problem/553000/load-of-property-langversion-failed.html. You can follow that ticket and vote it up to raise its profile.