{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet/roslyn-sdk/issues/105","repository_url":"https://api.github.com/repos/dotnet/roslyn-sdk","labels_url":"https://api.github.com/repos/dotnet/roslyn-sdk/issues/105/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/roslyn-sdk/issues/105/comments","events_url":"https://api.github.com/repos/dotnet/roslyn-sdk/issues/105/events","html_url":"https://github.com/dotnet/roslyn-sdk/issues/105","id":298014894,"number":105,"title":"Analyzer packages are hard to create and do right","user":{"login":"jmarolf","id":9797472,"avatar_url":"https://avatars2.githubusercontent.com/u/9797472?v=4","gravatar_id":"","url":"https://api.github.com/users/jmarolf","html_url":"https://github.com/jmarolf","followers_url":"https://api.github.com/users/jmarolf/followers","following_url":"https://api.github.com/users/jmarolf/following{/other_user}","gists_url":"https://api.github.com/users/jmarolf/gists{/gist_id}","starred_url":"https://api.github.com/users/jmarolf/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jmarolf/subscriptions","organizations_url":"https://api.github.com/users/jmarolf/orgs","repos_url":"https://api.github.com/users/jmarolf/repos","events_url":"https://api.github.com/users/jmarolf/events{/privacy}","received_events_url":"https://api.github.com/users/jmarolf/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-02-17T16:02:24Z","updated_at":"2018-02-18T05:51:25Z","closed_at":null,"author_association":"MEMBER","body":"@AArnott commented on [Thu Feb 15 2018](https://github.com/dotnet/roslyn/issues/24885)\n\nProperly 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.\r\n\r\n[StyleCop.Analyzers](https://github.com/DotNetAnalyzers/StyleCopAnalyzers/pull/1674) discovered and [others](https://github.com/Microsoft/VSSDK-Analyzers/pull/23) 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:\r\n\r\nMy.Analyzers.dll\r\nMy.Analyzers.CodeFixes.dll\r\n\r\nI 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.\r\n\r\nWe also have satellite assemblies for some of our analyzers.\r\n\r\nThen 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?\r\n\r\nCan all this be simplified, both in build authoring, and with a (multi-)project template in VS?\n\n---\n\n@tmat commented on [Fri Feb 16 2018](https://github.com/dotnet/roslyn/issues/24885#issuecomment-366370035)\n\nThe 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.\r\n\r\nWe do also have a [custom script](https://github.com/dotnet/roslyn-analyzers/blob/master/build/GenerateAnalyzerNuspec.csx) that generates the nuspec file and [custom target](https://github.com/dotnet/roslyn-analyzers/blob/master/build/GenerateAnalyzerNuspec.targets) that invokes it.\n\n---\n\n@tmat commented on [Fri Feb 16 2018](https://github.com/dotnet/roslyn/issues/24885#issuecomment-366370428)\n\n@rrelyea @diverdan92\n\n---\n\n@AArnott commented on [Fri Feb 16 2018](https://github.com/dotnet/roslyn/issues/24885#issuecomment-366399170)\n\nI've added a couple more issues with analyzer packaging to the description.\r\n\r\nYes, 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?\n\n---\n\n@tmat commented on [Fri Feb 16 2018](https://github.com/dotnet/roslyn/issues/24885#issuecomment-366403530)\n\n@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.\n\n---\n\n@jmarolf commented on [Sat Feb 17 2018](https://github.com/dotnet/roslyn/issues/24885#issuecomment-366431213)\n\nSounds like we need to do the following:\r\n- Change the templates on https://github.com/dotnet/roslyn-sdk so that they create separate projects for analyzers and codefixers\r\n-  Add analyzers to https://github.com/dotnet/roslyn-analyzers/tree/master/src/Microsoft.CodeAnalysis.Analyzers that warn when you reference the workspace layer from an analyzer.\r\n\r\n@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\n\n---\n\n@AArnott commented on [Sat Feb 17 2018](https://github.com/dotnet/roslyn/issues/24885#issuecomment-366448586)\n\n@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.\r\n\r\nYes, 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?\n\n"},"comment":{"url":"https://api.github.com/repos/dotnet/roslyn-sdk/issues/comments/366494418","html_url":"https://github.com/dotnet/roslyn-sdk/issues/105#issuecomment-366494418","issue_url":"https://api.github.com/repos/dotnet/roslyn-sdk/issues/105","id":366494418,"user":{"login":"sharwell","id":1408396,"avatar_url":"https://avatars1.githubusercontent.com/u/1408396?v=4","gravatar_id":"","url":"https://api.github.com/users/sharwell","html_url":"https://github.com/sharwell","followers_url":"https://api.github.com/users/sharwell/followers","following_url":"https://api.github.com/users/sharwell/following{/other_user}","gists_url":"https://api.github.com/users/sharwell/gists{/gist_id}","starred_url":"https://api.github.com/users/sharwell/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sharwell/subscriptions","organizations_url":"https://api.github.com/users/sharwell/orgs","repos_url":"https://api.github.com/users/sharwell/repos","events_url":"https://api.github.com/users/sharwell/events{/privacy}","received_events_url":"https://api.github.com/users/sharwell/received_events","type":"User","site_admin":false},"created_at":"2018-02-18T05:51:25Z","updated_at":"2018-02-18T05:51:25Z","author_association":"MEMBER","body":"I'm having a hard time figuring out where to reply to this discussion. For now I've replied primarily in dotnet/roslyn-analyzers#1588."}}
{"actor":{"display_login":"sharwell"}}