.NET Standard 2.0 Removal complicates .NET Source Generator development

[Tornhoof]

Hello,
The Sql Sript DOM library is quite useful for .NET Source Generators, as it makes it possible to parse SQL statements to decide on proper C# source generation, e.g. parse SELECT statement columns to create proper column mappings etc or in general do dev time analysis of sql statements.

.NET source generators and or analyzers are targeting .NET standard 2.0 projects, as they need to run on both Visual Studio roslyn (.netfx) and everything more modern (.net 8+).

Examples of libraries using this approach is DapperAOT by @mgravell, i think he was the first to use the SQL script dom lib to parse sql statements to figure out code generation.

While it is possible to suppress NU1701 (the wrong tfm warning) per package, it would be quite nice if you'd add netstandard2.0 back again, as roslyn analyzers and source generators with external dependencies are already quite messy to develop.

[mgravell]

Oh, yeah, this would be catastrophically painful for Dapper. I'd basically need to fork SqlScriptDOM if this (from here) can't go back (thanks for the tip, @Tornhoof).

netstandard2.0 has a special place in hell, as analyzers are basically restricted to netstandard2.0; SqlScriptDOM is IMO very well placed for use in analyzer code, so: I think it is a huge loss to drop this.

(btw, it isn't just codegen; Dapper.Advisor allows SQL statements to be inspected for correctness and best-practice independently of codegen)

[ErikEJ]

@Tornhoof Where do you see signs of .NET Standard 2.0 removal from this library?

[mgravell]

Where do you see signs of .NET Standard 2.0 removal from this library?

See my edit, or: this PR: a6592c7

[Tornhoof]

Yeah that's the one, I'm currently working around it in my own code with the following hack:
Suppress 1701 for it and manually copying the net462 target version dll, this appears to be working in VS 17.12 and dotnet command line, this works for the inhouse lib here, but I honestly have no idea of the impact on e.g. Rider or any other dev environment.

  <ItemGroup>
    <PackageReference Include="Microsoft.CodeAnalysis.Analyzers" PrivateAssets="all" />
    <PackageReference Include="Microsoft.CodeAnalysis.CSharp" PrivateAssets="all" />
    <PackageReference Include="Microsoft.SqlServer.TransactSql.ScriptDom" PrivateAssets="all" GeneratePathProperty="true">
      <NoWarn>NU1701</NoWarn>
    </PackageReference>
    <None Include="$(OutputPath)\$(AssemblyName).dll" Pack="true" PackagePath="analyzers/dotnet/cs" Visible="false" />
    <None Include="$(OutputPath)\$(AssemblyName).xml" Pack="true" PackagePath="analyzers/dotnet/cs" Visible="false" />
    <None Include="$(PkgMicrosoft_SqlServer_TransactSql_ScriptDom)/lib/net462/Microsoft.SqlServer.TransactSql.ScriptDom.dll" PackagePath="analyzers/dotnet/cs" Pack="true" Visible="false" />
  </ItemGroup>

[ErikEJ]

@llali FYI - I suggest reverting - no real reason to drop support for .NET Standard