Add SQL code analysis from PackageReference or ProjectReference

[zijchen]

Corresponding SDK changes for analyzer package support, fixes #332

TODO: Need new DacFx version

Add PackageReference to analyzer Nuget via

<PackageReference Include="CodeAnalyzerSample" Version="1.0.0" />

• Analyzer DLL must be in analyzers/dotnet/cs
• Analyzer package can target any .NET version DacFx supports

You can also add reference via ProjectReference

<ProjectReference Include="C:\test\test_analyzer\CodeAnalyzerSample.csproj"
                      PrivateAssets="all"
                      ReferenceOutputAssembly="false"
                      OutputItemType="Analyzer"
                      SetTargetFramework="TargetFramework=netstandard2.1" />

• You must override target GetTargetPath in your csproj

See example analyzer in CodeAnalyzerSample.csproj

[ErikEJ]

As a rules author, do I really need to add all this cruft to my project to build an analyzer package? Seems complex and error prone..

[zijchen]

I couldn't find a straightforward sample either, seems like .NET doesn't have an easy path to creating an analyzer package. The sample I used is from https://github.com/dotnet/samples/blob/main/csharp/roslyn-sdk/Tutorials/MakeConst/MakeConst.Package/MakeConst.Package.csproj

[ErikEJ]

Again, this is not a roslyn analyzer and DacFx has its own analysis result mechanism.

But OK - there will be few publishers of rules and hopefully many consumers

[zijchen]

We can add this in a future dotnet new template @dzsquared

[ErikEJ]

Why this uncommon location? How about "tools" ?

[zijchen]

This is the path Nuget natively resolves analyzers from

[ErikEJ]

Ok, but this is not a roslyn analyzer and the target language is not "cs" ...

[zijchen]

Yeah I can understand that, my motivation was to keep it similar to C# and use Nuget's package resolution logic. We did build in the extensibility via SqlCodeAnalysisAssemblyPaths so if there is a growing demand for another location, we can easily hook that up.

[ErikEJ]

Nuget's package resolution logic

Fair, if that adds value for you.

But maybe just use analyzers\dotnet\ ??

[ErikEJ]

This is very cool, looking forward.

I already publish a couple of NuGet packages with analyzer rules, targeting both .net standard 2.1 and netfx 4.6.2: https://www.nuget.org/packages?q=erikej.dacfx

So very interested in this topic.

The packages that I publish are currently used for consumption by a project, that use DacFX, not for consumption in a .sqlproj project. But it would be very nice to be able to support both scenarios in the same NuGet package, IMHO.

[ErikEJ]

What does "You must override target GetTargetPath in your csproj" mean??

[ErikEJ]

So, this is the result of Nuget pack with the sample here:

And this is my package:

Questions:

What is the value of having the .dll in two places?

How do I target multiple frameworks? Or is this a .NET only proposal? (No NetFX) ?

[zijchen]

What does "You must override target GetTargetPath in your csproj" mean??

This is only necessary if you want to add the analyzer via ProjectReference. It's to workaround a bug of a csproj referenced from sqlproj throwing that the target doesn't exist

DacFx/test/Microsoft.Build.Sql.Tests/TestData/CodeAnalyzerSample/CodeAnalyzerSample.csproj

Line 10 in 79da904

<Target Name="GetTargetPath" />

[ErikEJ]

Is it really necessary ti support that?

[zijchen]

This is very cool, looking forward.

I already publish a couple of NuGet packages with analyzer rules, targeting both .net standard 2.1 and netfx 4.6.2: https://www.nuget.org/packages?q=erikej.dacfx

So very interested in this topic.

The packages that I publish are currently used for consumption by a project, that use DacFX, not for consumption in a .sqlproj project. But it would be very nice to be able to support both scenarios in the same NuGet package, IMHO.

We are introducing a new property SqlCodeAnalysisAssemblyPaths in the next version of DacFx that you can use to hook up additional analyzer paths. I imagine you can use this for MSBuild.Sdk.Sqlproj too

[ErikEJ]

Amazing!

[jmezach]

@ErikEJ That would make it a lot easier to implement rr-wfm/MSBuild.Sdk.SqlProj#569.

[ErikEJ]

@zijchen I can see there is a preview release now with SqlCodeAnalysisAssemblyPaths I assume

In which namespace do I find SqlCodeAnalysisAssemblyPaths ?

[zijchen]

@zijchen I can see there is a preview release now with SqlCodeAnalysisAssemblyPaths I assume

In which namespace do I find SqlCodeAnalysisAssemblyPaths ?

SqlCodeAnalysisAssemblyPaths is a property of Microsoft.Data.Tools.Schema.Tasks.Sql.SqlStaticCodeAnalysisTask. This hooks into a new AssemblyLookupPath property in Microsoft.SqlServer.Dac.CodeAnalysis.CodeAnalysisServiceSettings if you're using the library directly.

[ErikEJ]

@zijchen I actually just did this to pack my rules:

    <None Include="..\SqlServer.Dac\bin\$(Configuration)\netstandard2.1\SqlServer.Dac.dll" 
             Pack="true"
             PackagePath="analyzers\dotnet\cs"
             Visible="false" />
    <None Include="bin\$(Configuration)\netstandard2.1\SqlServer.Rules.dll" 
        Pack="true"
        PackagePath="analyzers\dotnet\cs"
        Visible="false" />

[ErikEJ]

Sadly, the property in DacFX ended up being called: SqlCodeAnalysisAssemblyPath 😢 - s is missing