Skip to content
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

Consume rules from a Nuget package #569

Closed
ErikEJ opened this issue Jun 27, 2024 · 21 comments · Fixed by #625
Closed

Consume rules from a Nuget package #569

ErikEJ opened this issue Jun 27, 2024 · 21 comments · Fixed by #625
Labels
enhancement New feature or request

Comments

@ErikEJ
Copy link
Collaborator

ErikEJ commented Jun 27, 2024

@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)

@jmezach
Copy link
Member

jmezach commented Jun 28, 2024

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.

@ErikEJ
Copy link
Collaborator Author

ErikEJ commented Jun 28, 2024

They need to be in the same folder as the dacpactool.

Either way I think we can make this work

That would be amazing!

@ErikEJ
Copy link
Collaborator Author

ErikEJ commented Jun 30, 2024

NuGet/Home#6301 seems helpful

@ErikEJ
Copy link
Collaborator Author

ErikEJ commented Jul 1, 2024

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?)

@jmezach
Copy link
Member

jmezach commented Jul 1, 2024

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.

@ErikEJ
Copy link
Collaborator Author

ErikEJ commented Jul 1, 2024

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.

@jmezach
Copy link
Member

jmezach commented Jul 1, 2024

We are using that already for resolving the PackageReference to the actual .dacpac file, see

<PhysicalLocation>$(Pkg%(_ResolvedPackageReference.PackageName))</PhysicalLocation>

@ErikEJ
Copy link
Collaborator Author

ErikEJ commented Jul 1, 2024

Ah! Just proves how bad I am at MsBuild 😄

@jmezach
Copy link
Member

jmezach commented Jul 2, 2024

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.

@ErikEJ ErikEJ added the enhancement New feature or request label Jul 2, 2024
@ErikEJ
Copy link
Collaborator Author

ErikEJ commented Aug 6, 2024

@jmezach FYI - microsoft/DacFx#479

@ErikEJ
Copy link
Collaborator Author

ErikEJ commented Sep 22, 2024

image

With the latest DacFX we now have this.

@jmezach
Copy link
Member

jmezach commented Sep 23, 2024

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.

@ErikEJ
Copy link
Collaborator Author

ErikEJ commented Sep 23, 2024

Correct, hoping for some help with the msbuild part. 😅

@ErikEJ
Copy link
Collaborator Author

ErikEJ commented Sep 23, 2024

Could it be as simple as this?

SqlCodeAnalysisAssemblyPaths="$(SqlCodeAnalysisAssemblyPaths);@(Analyzer);"

@jmezach
Copy link
Member

jmezach commented Sep 23, 2024

I guess that depends on what is in @(Analyzer) ;).

@ErikEJ
Copy link
Collaborator Author

ErikEJ commented Sep 23, 2024

Let me try to give it a go, and I will find out 😅

@ErikEJ
Copy link
Collaborator Author

ErikEJ commented Sep 23, 2024

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.

@ErikEJ
Copy link
Collaborator Author

ErikEJ commented Sep 23, 2024

I cannot target netstandard2.0 with my rules assembly, as DacFX only supports netstandard2.1 and net6.0

@ErikEJ
Copy link
Collaborator Author

ErikEJ commented Sep 23, 2024

image

@jmezach
Copy link
Member

jmezach commented Sep 24, 2024

What happens if you target netstandard2.1 in your test project?

@ErikEJ
Copy link
Collaborator Author

ErikEJ commented Sep 24, 2024

@jmezach I will try that next!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants