-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Analyzer packages are hard to create and do right #24885
Comments
The main problem here is that NuGet doesn't know what an analyzer package is -- NuGet Pack task doesn't have any switch to build analyzer package. We do also have a custom script that generates the nuspec file and custom target that invokes it. |
I've added a couple more issues with analyzer packaging to the description. Yes, I know NuGet pack doesn't know. But evidently something knows enough about it to customize how installing analyzer packages should do, since that has a very different result. But regardless of nuget knowing what packing is doing, .targets can be written to make it do it right (as each analyzer author eventually figures out). Why not package that up and encourage analyzer authors to use it? |
@AArnott To make it actually work for arbitrary analyzers we would need to reimplement NuGet's logic for determining dependencies. It would be better done in NuGet Pack. |
Sounds like we need to do the following:
@AArnott i you agree I'll move this issue to https://github.com/dotnet/roslyn-sdk and file a separate issue on https://github.com/dotnet/roslyn-analyzers |
@jmarolf I wasn't even aware of the project templates. Where can I find those in pre-compiled form? The source for it looks like it already embodies much of what I was asking for. That's great. Yes, your proposal for closing the gap between them and what I'm asking for here by moving issues around sounds good. But what about the other issues like targeting multiple versions of Roslyn? |
Issue moved to dotnet/roslyn-sdk #105 via ZenHub |
@AArnott from the VS installer choose ".NET Compiler Platform SDK" to get the templates and the syntax visualizer |
Properly packaging up analyzers is not automatic. .NET SDK projects that contain analyzers pack themselves with the analyzer assembly in the lib folder instead of the
analyzers\cs
folder. Fixing this requires suppressing default lib folder placement then writing a custom target to output the right set of assemblies. Care is required to properly suppress all (or most) package dependencies including to Roslyn itself.StyleCop.Analyzers discovered and others later did as well, the little known fact that analyzers must not reference the roslyn Workspaces package although their code fixes are required to. To do this reliably, one must split these into two assemblies, yet we want to package them up together, which again the .NET SDK pack target makes awkward. Consider a package called My.Analyzers with these assemblies:
My.Analyzers.dll
My.Analyzers.CodeFixes.dll
I tend to want My.Analyzers.CodeFixes.dll to reference My.Analyzers.dll (so that the code fixes can reference the analyzer Id property, share utilities, etc.) But that means I have to make my CodeFixes project do the actual packaging. This is particularly awkward because the package will be given the name of the first project, which NuGet doesn't like unless I give the first project an artificial package ID that won't matter since I need to set IsPackable=false on the analyzer project so that I don't get an analyzer-only package too. Gah! So many things to do. You can see this all in the VSSDK-Analyzers PR that I link to above.
We also have satellite assemblies for some of our analyzers.
Then we have versioning: what version of Roslyn should an analyzer compile against? We want to compile against the latest so we do the right thing when C# 7.1 syntax is encountered, but then we want to keep working on VS2015. Can the package layout include analyzer versions (ala target frameworks) so we can offer analyzer\cs71 and analyzer\cs60 folders side-by-side in the package?
Can all this be simplified, both in build authoring, and with a (multi-)project template in VS?
The text was updated successfully, but these errors were encountered: