-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add SQL code analysis from PackageReference or ProjectReference #479
Conversation
@@ -0,0 +1,16 @@ | |||
<Project Sdk="Microsoft.NET.Sdk"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can add this in a future dotnet new
template @dzsquared
<Target Name="GetTargetPath" /> | ||
<Target Name="_AddAnalyzersToOutput"> | ||
<ItemGroup> | ||
<TfmSpecificPackageFile Include="$(OutputPath)\CodeAnalyzerSample.dll" PackagePath="analyzers/dotnet/cs" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this uncommon location? How about "tools" ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the path Nuget natively resolves analyzers from
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, but this is not a roslyn analyzer and the target language is not "cs" ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nuget's package resolution logic
Fair, if that adds value for you.
But maybe just use analyzers\dotnet\
??
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. |
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
|
Is it really necessary ti support that? |
We are introducing a new property |
Amazing! |
@ErikEJ That would make it a lot easier to implement rr-wfm/MSBuild.Sdk.SqlProj#569. |
test/Microsoft.Build.Sql.Tests/TestData/CodeAnalyzerSample/TableNameEndingInViewRule.cs
Outdated
Show resolved
Hide resolved
@zijchen I can see there is a preview release now with In which namespace do I find |
|
@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" />
|
Sadly, the property in DacFX ended up being called: |
Corresponding SDK changes for analyzer package support, fixes #332
TODO: Need new DacFx version
Add PackageReference to analyzer Nuget via
You can also add reference via ProjectReference
GetTargetPath
in your csprojSee example analyzer in CodeAnalyzerSample.csproj