Support for extensions containing Roslyn features (analyzers, refactorings)

[josefpihrt]

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]

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

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]

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]

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]

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

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]

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

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]

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]

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