Do you not need to include Roslynator.CodeAnalysis.Analyzers ?

Analyzer from package Roslynator.CodeAnalysis.Analyzers were never included in the VS extension. These analyzers are relevant only for projects that reference Roslyn packages (Microsoft.CodeAnalysis*)

https://josefpihrt.github.io/docs/roslynator/analyzers#groups

While I understand the decision, just wanted to say that this is going to be a big downside for anyone who uses Roslynator with Unity projects, as unity basically has no native way to install nuget packages, and you have to go and manually download DLLs and then often use special scripts that auto-edit unity-generated project files

@orels1 The extension with analyzers will be still available as GH artifact as it can be seen here. Would that do?

@josefpihrt If a line could be thrown into the readme, pointing that out as an option - I think that would be at least much better than not having it at all

@orels1 It will be documented, no doubt about it.

Roslynator has been immensely useful for contributing to OSS and work projects alike for helping rewrite various code patterns to a more performant version without forcing the projects to add them explicitly which would require much more involved approach (because people are opinionated on what goes in, and it needs more configuration effort). This extension has been consistently making VS Code have better code fixes defaults than Rider. Would be sad to see it go.

Roslynator has been immensely useful for contributing to OSS and work projects alike for helping rewrite various code patterns to a more performant version without forcing the projects to add them explicitly which would require much more involved approach (because people are opinionated on what goes in, and it needs more configuration effort). This extension has been consistently making VS Code have better code fixes defaults than Rider. Would be sad to see it go.

Agreed. I'm also sad to hear it will no longer be an IDE extension for similar reasons

We have started adding the deps into the Directory.build.props file, but this is dramatically harder to implement and maintain (and keep updated) across multiple solutions, rather than having a single VS or VS Code extension installed.