Consider inverting `Language` property special-casing

[alexrp]

Specifically:

https://github.com/dotnet/Nerdbank.GitVersioning/blob/2b5ba90c74dc5d3e9300e8079d6ed511536000a9/src/Nerdbank.GitVersioning.Tasks/build/Nerdbank.GitVersioning.targets#L43C6-L44

I would like to propose that instead of special-casing Language values that are known to be unsupported, NBGV should special-case values that are known to be supported. After all, it is a fairly rare event for a new programming language to appear and gain traction in the .NET space, and subsequently get support in NBGV.

This would make it easier to use NBGV out of the box in repositories that have Microsoft.Build.NoTargets projects, or projects using other languages (e.g. Zig in my case), etc.

[alexrp]

To be clear, the current approach is problematic because LANGUAGE is a common environment variable on Linux systems with any kind of GUI, with values looking like en_US:en or whatever. MSBuild happily promotes that environment variable to a property, and suddenly NBGV thinks that the project programming language is en_US:en! (This only happens in projects w/o an explicit Language value, such as ones based on Microsoft.Build.NoTargets.) This then leads to this error:

Nerdbank.GitVersioning/src/Nerdbank.GitVersioning.Tasks/AssemblyVersionInfo.cs

Line 182 in 2b5ba90

this.Log.LogError("CodeDomProvider not available for language: {0}. No version info will be embedded into assembly.", this.CodeLanguage);

Notably, NBGV already has a condition checking for non-empty Language here:

Nerdbank.GitVersioning/src/Nerdbank.GitVersioning.Tasks/build/Nerdbank.GitVersioning.targets

Line 118 in 2b5ba90

<Target Name="GenerateAssemblyNBGVVersionInfo" DependsOnTargets="GetBuildVersion" Condition=" '$(Language)' != '' and '$(GenerateAssemblyVersionInfo)' != 'false' ">

But, of course, that doesn't help when it's set to some nonsense like en_US:en.

[AArnott]

Makes sense. Thanks for the great problem description and proposed solution.