Do not test LangVersion

[rdeago]

Describe the Bug

ThisAssembly will issue a warning if the LangVersion MSBuild property specifies a C# language version older than 9.0.

This is the relevant code, copied from the source:

    <Warning Code="THIS001" 
             Text="ThisAssembly uses Roslyn source generators, which are only supported in C# 9.0 or greater at the moment."
             Condition="'$(Language)' != 'C#' OR 
                  ('$(LangVersion)' != 'preview' AND
                   '$(LangVersion)' != 'latest' AND
                   '$(LangVersion)' != 'latestMajor' AND
                   '$(LangVersion)' &lt; '9.0')" />

The above warning will even cause a build to fail if TreatWarningsAsErrors is set to true (which is my case, incidentally).

LangVersion, though, has nothing to do with code generators: any version of Roslyn that supports code generators will happily run them even with LangVersion set to 1.0. It is up to code generators to generate code that is compatible with the language version used in a project. dotnet/roslyn#61094
For example, both a library targeting .NET Standard 2.0 and an application targeting .NET Framework will have LangVersion set to 7.3 by default; there is no real reason for this to prevent them from using ThisAssembly.

Steps to Reproduce

Create a .csproj file as follows:

<Project>

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="ThisAssembly" Version="1.0.9" />
  </ItemGroup>

</Project>

Verify that it does not build because of warning THIS001 treated as error.

Expected Behavior

The LangVersion property should not be checked, as it tells nothing about actual support of code generators.

Version Info

ThisAssembly (or any other package depending on ThisAssembly.Prerequisites) v1.0.7+

Additional Info

Support for code generators is not a feature of the C# language: rather it is a feature of the Roslyn compiler. The confusion probably stems from C# 9.0 and Roslyn 3.6 being released together with .NET 5.0 (Roslyn was at version 3.7 by the time .NET 5.0 reached GA, but 3.6 is the first version containing GeneratorAttribute).

In other words, the first version of Roslyn supporting code generators was also the first version of Roslyn implementing C# 9.0.

This does not mean, however, that code generators only work with C# 9.0: as a matter of fact they even work fine with Visual Basic (again, not necessarily the latest language version). I have prepared a proof-of-concept project that demonstrates code generators working with both C# 7.3 and VB 15.0.

[kzu]

Heya @rdeago , thanks a lot for reporting this.

I believe as part of your PR for #105 , you had addressed this by checking for a new property that instead exposes the Roslyn version.

Perhaps you could send a PR with that check to fix this issue? I take it that it should go to the prerequisites project so all generators use the same check. I'd say that (since net5 is not LTS) if the property isn't found, we turn off generators entirely (warn/fail as the current improper check).

Thanks again!

[rdeago]

Sorry for the late answer. Busy as a bee, as usual. I'll try to open the PR this weekend.

.NET 5 should not be a concern anyway: if a generator is in a roslyn42 folder, it just means "Roslyn 4.2 or any later version". For example, Roslyn 4.3 will happily recognize and use the generator, unless the same package has a roslyn43 folder. This mechanism is in place since Roslyn 4.1 IIRC.