Project-system: Setting CSharpProjectConfigurationProperties3.LanguageVersion creates verbose XML in project file

[jcouv]

The UpgradeProject code fixer produces a lot of "fluff" in the project file:

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
  <LangVersion>latest</LangVersion>
</PropertyGroup>

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
  <LangVersion>latest</LangVersion>
</PropertyGroup>

I would expect a single <LangVersion>latest</LangVersion> to be added to the standard, non-conditional, <PropertyGroup/> instead.

Thanks @DavidArno for reporting this. Also FYI @jnm2 @BillWagner

[davkean]

There's really two bugs; one for the legacy and one for new project system.

New project system, let's just make langversion a non-config property. Easy peasy.
Legacy project system, a big more work and compat to think about. You're going through a "configuration" so the behavior you are seeing is definitely expected. We'd need to introduce a dual concept here where reading would read via configuration (for compat) but write would bypass config and set it project-wide.

[davkean]

The setting is also on a config-based page so we'd need to think about that as well./

[jnm2]

I wish the build properties page opened to show all configurations by default, and thus any change made would first remove all conditional <LangVersion> elements from the .csproj and then add/update an unconditional <LangVersion> element.

[davkean]

That's an interesting idea - perhaps we have a way of setting "all configs" and just not condition the property when you set that.

[jnm2]

The same would be very helpful for <AllowUnsafeBlocks>, <WarningsAsErrors />, <TreatWarningsAsErrors>. and <DocumentationFile>. It only results in confusion when any of these properties has a configuration-conditional value- the feedback loop for discovering errors is much longer, when you push to CI for example.

[DavidArno]

@davkean,

My original request was specifically related to the new csproj file format. You guys did such an amazing job with that new format that I've happily spent time rewriting all old csproj files in my code to the new format. So - personally - I don't much care what happens with legacy projects 😉

(I appreciate you have to look at a much bigger picture than me though and so will need to address both scenarios)

[yaakov-h]

Even if I select 'All Configurations' before changing the language version, I get the conditional duplication defined in the OP (new project system, haven't tried old).

Shouldn't this define it once for all configurations, rather than N times for each current configuration?

[davkean]

Yes that's one of the proposal aboves. Legacy project system has always had this behavior - and the new project system kinda mirrored it. We should fix that.

[jnm2]

So - personally - I don't much care what happens with legacy projects

Gotta say I'd prefer the energy be put into allowing winforms projects to use the new sdk so I can just get off the legacy sdk altogether :D

[jcouv]

Note: a number of users reported pain with this setting being per-configuration (see comments in https://github.com/dotnet/roslyn/issues/21783#issuecomment-376308936).

[DavidArno]

Will this likely be fixed any time soon? As @davkean says, it ought to be easy to fix for the new project file format, but six months later it's still doing it the messy way.

[davkean]

@DavidArno We're focusing on bugs that affect inner loop and those without workarounds. While annoying, this is a once per project change that has an easy workaround to simplify resulting comparison.

[Neme12]

@davkean Aren't all configuration-specific options also possible to be set independently of configuration? If that's the case, the ConfigurationManager API could have a special property (maybe AllConfigurations) that would return a fake Configuration that would always write configuration-independent values.

[Pilchie]

Also mentioned in :link: https://developercommunity.visualstudio.com/content/problem/252667/when-setting-langversion-via-project-properties-it.html

[davkean]

Have a fix for the new project system here: ~https://github.com/dotnet/project-system/issues/2732~ https://github.com/dotnet/project-system/pull/3547. This bug will be left open to track the legacy project system.

[Neme12]

Note: AllowUsafeBlocks could use this fix as well (https://github.com/dotnet/roslyn/pull/25875)

[davkean]

AllowUnsafeBlocks requires a UI change - it's prominent (as opposed to langversion which is behind Advanced) on a configuration-specific page. I'd prefer tracking that as a separate bug.

[davkean]

LangVersion is now configuration-agnostic for the new project system (SDK-based projects). This change will first appear in 15.8 Preview 2.

[davkean]

@Neme12 Can you please file new bugs for any other properties that you feel fall into the same bucket?

[Pilchie]

Correction - it will be in Preview 3 at this point.

[tmeschter]

Tom's triage notes: Recommend we just close the issue.

[tmeschter]

We have decided to _not_ address this in the legacy project system. Closing.

[weedkiller]

I still have this problem where even after adding latest C# compilerTools its still not using the latest C# compilers for ASP MVC 5 project on 4.8