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

IMPORTANT: Remove analyzers from Visual Studio/VS Code extensions #1172

Open
josefpihrt opened this issue Aug 18, 2023 · 9 comments · May be fixed by #1303
Open

IMPORTANT: Remove analyzers from Visual Studio/VS Code extensions #1172

josefpihrt opened this issue Aug 18, 2023 · 9 comments · May be fixed by #1303

Comments

@josefpihrt
Copy link
Collaborator

Summary

At the beginning it seemed like a good idea to include analyzers in the IDE extensions. Analyzers were available in every project/solution without necessity reference in every project/solution.

The main issue is that the analyzers are "bound" only to the IDE, diagnostics will be displayed in the IDE but not during build, command-line build or CI build.

The desired state is that analyzers are "bound" to the project/solution, regardless of the IDE or extension installed.

Best Practice

  • Install extension to have refactoring and code fixes for compiler diagnostics.
  • Install NuGet package(s) with analyzers.
    • Add package reference to your Directory.Build.props file which is located at the root of your repository.

Directory.Build.props

<ItemGroup>
  <PackageReference Include="roslynator.analyzers" Version="<VERSION>">
    <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    <PrivateAssets>all</PrivateAssets>
  </PackageReference>
  <PackageReference Include="roslynator.formatting.analyzers" Version="<VERSION>">
    <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    <PrivateAssets>all</PrivateAssets>
  </PackageReference>
</ItemGroup>

When it will be removed?

Probably the best opportunity would be a moment when a new major version of Visual Studio is released. It usually means that major version of Roslynator is released as well.

Depending on when the next major version of VS will be released, analyzers could be removed from extension earlier, but not at least several months after this announcement.

@josefpihrt josefpihrt pinned this issue Aug 18, 2023
@josefpihrt josefpihrt changed the title Remove analyzers from Visual Studio/VS Code extensions IMPORTANT: Remove analyzers from Visual Studio/VS Code extensions Aug 18, 2023
@dylanvdmerwe
Copy link

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

@josefpihrt
Copy link
Collaborator Author

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

@josefpihrt josefpihrt linked a pull request Nov 30, 2023 that will close this issue
@orels1
Copy link

orels1 commented Feb 3, 2024

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

@josefpihrt
Copy link
Collaborator Author

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

@orels1
Copy link

orels1 commented Feb 4, 2024

@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

@josefpihrt
Copy link
Collaborator Author

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

@neon-sunset
Copy link

neon-sunset commented Feb 15, 2024

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.

@mejobloggs-cw
Copy link

mejobloggs-cw commented Apr 15, 2024

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

@dylanvdmerwe
Copy link

dylanvdmerwe commented Apr 16, 2024

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.

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

Successfully merging a pull request may close this issue.

5 participants