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

Analyzer packages are hard to create and do right #24885

Closed
AArnott opened this issue Feb 16, 2018 · 8 comments
Closed

Analyzer packages are hard to create and do right #24885

AArnott opened this issue Feb 16, 2018 · 8 comments

Comments

@AArnott
Copy link
Contributor

AArnott commented Feb 16, 2018

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?

@tmat
Copy link
Member

tmat commented Feb 16, 2018

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.

@tmat
Copy link
Member

tmat commented Feb 16, 2018

@rrelyea @diverdan92

@AArnott
Copy link
Contributor Author

AArnott commented Feb 17, 2018

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?

@tmat
Copy link
Member

tmat commented Feb 17, 2018

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

@jmarolf
Copy link
Contributor

jmarolf commented Feb 17, 2018

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

@AArnott
Copy link
Contributor Author

AArnott commented Feb 17, 2018

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

@jmarolf
Copy link
Contributor

jmarolf commented Feb 17, 2018

Issue moved to dotnet/roslyn-sdk #105 via ZenHub

@jmarolf
Copy link
Contributor

jmarolf commented Feb 17, 2018

Where can I find those in pre-compiled form?

@AArnott from the VS installer choose ".NET Compiler Platform SDK" to get the templates and the syntax visualizer

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants