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

Support for extensions containing Roslyn features (analyzers, refactorings) #6790

Open
josefpihrt opened this issue Jan 7, 2024 · 11 comments

Comments

@josefpihrt
Copy link

Context

I have an extension that contains custom Roslyn analyzers, refactorings and code fixes. I use OmniSharp settings to configure it:

{
    "RoslynExtensionsOptions": {
        "EnableAnalyzersSupport": true,
        "LocationPaths": [
        ]
    }
}

OmniSharp is now not used by default, so now I have to:

  • Set dotnet.server.useOmnisharp to true
  • Disable C# Dev Kit

Question

Is it possible to configure custom Roslyn analyzers and refactorings without using OmniSharp?

Versions used

VS Code: 1.85.1
C# extension: 2.14.8
C# Dev Kit: 1.2.5

@dibarbet
Copy link
Member

dibarbet commented Jan 9, 2024

@josefpihrt we should already support the scenario where the analyzer or refactoring is shipped as nuget package that you reference on your project. This is generally the way we would recommend consuming analyzers and refactorings.

For example, this is how an analyzer package should be authored - https://learn.microsoft.com/en-us/nuget/guides/analyzers-conventions

We do not currently support loading analyzers manually into the server (how O# settings worked). I'll leave this issue open to track that request.

@josefpihrt
Copy link
Author

Thanks for answer.

Analyzers

I agree that analyzers should be consumed through nuget packages.

Refactorings

I didn't know that refactorings could be distributed as a part of nuget packages. The documentation page you shared says nothing about refactorings. Could you please point me to docs that describe how to configure nuget so it can contain refactorings? Or is it just about including dll with refactorings?

I strongly believe that whereas analyzers are "project-bound", refactorings are "IDE-bound" so it makes sense to distribute them as a part of IDE extension (unless it's some specialized set of refactorings for some specific library).

Code Fixes

By the way I also created a set of code fixes for compiler diagnostics (CSxxxx) and in this case it makes no sense to distribute them as a part of nuget package. Only reasonable way is to distributes them as a part of an extension.

@dibarbet
Copy link
Member

dibarbet commented Jan 9, 2024

It was implemented as part of this PR - dotnet/roslyn#35685
@sharwell do we have any docs on shipping code actions as part of a nuget package? I couldn't find anything obvious.

By the way I also created a set of code fixes for compiler diagnostics (CSxxxx) and in this case it makes no sense to distribute them as a part of nuget package. Only reasonable way is to distributes them as a part of an extension.

Hmm, mind expanding on that? To me it seems reasonable to include them on the project.

@sharwell
Copy link
Member

sharwell commented Jan 9, 2024

do we have any docs on shipping code actions as part of a nuget package

We have the project templates, but not sure what the question here is. Everything should just work for refactorings the same way they do for code fixes.

@sharwell
Copy link
Member

sharwell commented Jan 9, 2024

... and in this case it makes no sense to distribute them as a part of nuget package ...

We on the Roslyn team ship code fixes for CS* diagnostics via NuGet packages, and third parties do the same. I would consider it a normal practice and you install the fixes relevant to your solution into your solution using package references.

@josefpihrt
Copy link
Author

The question is not whether it should be possible to distribute refactorings as a part of nuget. The question is whether it should be possible to distribute them as a part of IDE extension.

Example

You have a set of general refactorings that are not specific to any particular project and you have a set of general code fixes for CS diagnostic that are not specific to any particular project. Why to publish them as nuget package?

Use case 1

A developer works on a PR for some open source project. This open source project do not reference refactoring/fixes nuget so these refactoring/fixes are not available and a developer cannot use them.

Use case 2

A developer works in a company on some project. Company makes decision (for some reason) not to reference refactoring/fixes nuget so these refactoring/fixes are not available and a developer cannot use them.

In both use cases, if refactorings and/or code fixes would be available as a part of some IDE extension, a developer could use them and would be satisfied.

@sharwell
Copy link
Member

sharwell commented Jan 10, 2024

@josefpihrt You could probably create an MSBuild targets file in one of the extension locations that adds a reference to the refactorings DLL to all projects that get loaded. It's not a direct solution to this issue but could be a viable workaround.

@josefpihrt
Copy link
Author

Why to make these workarounds when it could be supported by VS Code just as it's supported by Visual Studio?

What is the argument to prefer distributing common refactorings/fixes as nuget?

@sharwell
Copy link
Member

Why to make these workarounds when it could be supported by VS Code just as it's supported by Visual Studio?

It's less about whether it should/shouldn't work and more about prioritization and how long it would take to deliver the feature. I suggested a workaround for the interim period.

@josefpihrt
Copy link
Author

@josefpihrt You could probably create an MSBuild targets file in one of the extension locations that adds a reference to the refactorings DLL to all projects that get loaded. It's not a direct solution to this issue but could be a viable workaround.

@sharwell Could you please elaborate more on this idea, provide some code sample or a link to a docs page?

@marcospgp
Copy link

we should already support the scenario where the analyzer or refactoring is shipped as nuget package that you reference on your project

unfortunately this is not possible with Unity:

Unity doesn’t support the installation of Roslyn Analyzers or source generators through NuGet directly

https://docs.unity3d.com/Manual/roslyn-analyzers.html

@JoeRobich JoeRobich self-assigned this Aug 27, 2024
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

5 participants