Open ErikEJ opened 3 months ago
Do they need to be next to the dacpactool
or would it be enough to know the path to a rules assembly? Either way I think we can make this work, in a similar way as we reference .dacpac
's. It is mostly figuring out the set of NuGet packages that are referenced that contain rules, which could perhaps be marked as such in the .csproj
and then either copying the assemblies from there (probably making the assumption that the assembly bears the same name as the package), or passing its path to the tool.
They need to be in the same folder as the dacpactool
.
Either way I think we can make this work
That would be amazing!
https://github.com/NuGet/Home/issues/6301 seems helpful
This also could be useful? https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#generatepathproperty (if the rules package contains the rules dll in the tools folder?)
I guess we can define what we want to those "rules" packages to look like internally, so it shouldn't be an issue to put the rules assembly into the tools folder. We are also defining what "dacpac" packages look like and if I'm not mistaking we also put the .dacpac
into the tools
folder as well.
Yes, I noticed that the .dacpac files are also in the tools folder, so we could potentially take advantage of the automatic property that points to it these days.
We are using that already for resolving the PackageReference to the actual .dacpac
file, see https://github.com/rr-wfm/MSBuild.Sdk.SqlProj/blob/4b8a8f3484ae203ffeab84826bff95c6148fce94/src/MSBuild.Sdk.SqlProj/Sdk/Sdk.targets#L117
Ah! Just proves how bad I am at MsBuild 😄
It is definitely not for the faint of heart ;), although I believe the documentation has improved a bit compared to a couple of years ago when you could barely find any.
I could probably throw something together for this, but I'm fairly pressed for time at the time so I don't really know when I'll get around to it.
@jmezach FYI - https://github.com/microsoft/DacFx/pull/479
With the latest DacFX we now have this.
So I guess what we need to do is gather the paths of referenced analyzer packages within MSBuild and then pass that through to this property.
Correct, hoping for some help with the msbuild part. 😅
Could it be as simple as this?
SqlCodeAnalysisAssemblyPaths="$(SqlCodeAnalysisAssemblyPaths);@(Analyzer);"
I guess that depends on what is in @(Analyzer)
;).
Let me try to give it a go, and I will find out 😅
Looks like it just works!!!
I just need to repackage my rules nuget to target netstandard2.0 :-(
The command "dotnet "C:\Code\Github\MSBuild.Sdk.SqlProj\src\MSBuild.Sdk.SqlProj\Sdk\../tools/net8.0/DacpacTool.dll" build -o "obj\Debug\netstandard2.0\TestProjectWithAnalyzers.dacpac" -n "TestProjectWithAnalyzers" -v "1.0.0" -sv Sql150 -i "obj\Debug\netstandard2.0\TestProjectWithAnalyzers.InputFiles.txt" -dp IncludeCompositeObjects=true -an -ar "-SqlServer.Rules.SRD0006;-Smells.*;+!SqlServer.Rules.SRN0002" -aa C:\Users\ErikEjlskovJensen(De\.nuget\packages\erikej.dacfx.sqlserver.rules\1.0.1\analyzers\dotnet\cs\SqlServer.Dac.dll -aa C:\Users\ErikEjlskovJensen(De\.nuget\packages\erikej.dacfx.sqlserver.rules\1.0.1\analyzers\dotnet\cs\SqlServer.Rules.dll" exited with code -1.
I cannot target netstandard2.0 with my rules assembly, as DacFX only supports netstandard2.1 and net6.0
What happens if you target netstandard2.1
in your test project?
@jmezach I will try that next!
@jmezach @jeffrosenberg Do you think this could be possible in any way?
(The NuGet content must be extracted and copied to the SDK NuGet package tools folder before we run dacpactool)