Move FxCop code fixes to their own assemblies

[sharwell]

Analyzers and code fixes cannot be placed in the same assembly. Or more precisely, the analyzers assembly is not allowed to reference Microsoft.CodeAnalysis.Workspaces.dll, which defines the CodeFixProvider type. See DotNetAnalyzers/StyleCopAnalyzers#1674 for the nightmarish problem that occurs if you attempt to do so.

The code fixes which are currently located alongside their associated analyzers need to be moved to a separate assembly which is then located alongside the analyzers assembly.

[srivatsn]

Yes this is a good idea. However it leads to a proliferation of assemblies. Do you think a CodeAnalysisAnalyzers analyzer that detects if you are using something from workspaces would be enough here?

[sharwell]

However it leads to a proliferation of assemblies.

Assuming you are referring to things like DotNetAnalyzers/StyleCopAnalyzers#1624, this was already a problem. I think it's something we should address directly for consumers.

For contributors working on the project, the use of separate assemblies has obvious benefits. It eliminates the need to explain when/where workspace APIs can be used, and provides the strongest guarantees regarding runtime behavior of the analyzer assembly.

[srivatsn]

I agree with the benefits. It would be nice if we had a way of separating the dependencies from the actual analyzers in the UI. Currently we have three dlls for every package (base, C#, VB) and we have one package per contract assembly - when we split the fixers out, it'll be 6 per package and very soon the solution explorer UI will be unwieldy. There are some thoughts around reorganizing the analyzers node a-la ASP.NET 5 and so maybe this won't be a big deal then.

[sharwell]

One thought that comes to mind is making analyzer assemblies that don't contain any analyzers only show in Solution Explorer when Show All Files is checked.

[Evangelink]

With all the new changes coming to this repository, is it still a change/refactoring we want to pursue?

[mavasani]

@Evangelink Let us hold of on this work until

1. The repo has settled down in terms of eventual packages/projects we want to support
2. User submitted issues that can only be addressed with such changes

Let us only do this work when we can certainly demonstrate benefits in terms of user experience, user issues fixed, etc.

[Evangelink]

Sure! @mavasani It would be nice to add the Blocked and remove the help wanted labels.

[Evangelink]

@sharwell @mavasani I just wanted to give a little ping on this subject to see if there was some change. In case there isn't, I would suggest to close the ticket as Won't Fix based on the current inputs.

[sharwell]

The current approach relies on implementation details of the JIT to have the analyzers run during builds. Cases have been observed in the past (no longer have links handy) where analyzer worked on .NET Framework/.NET Core, but silently failed on Mono builds due to differences in this space. There is no good way to predict whether this situation will/will not occur, and the possibility of silent failure makes it unlikely a user would even know it happened.

Most other analyzer projects I've worked with have already split their assemblies to ensure these cases don't happen for users, and the roslyn-sdk templates split them by default.

[Evangelink]

Except for the number of projects (and nuget packages) we will end-up with, I don't see any technical difficulty. Is there anything preventing this change to happen?

[mavasani]

@Evangelink Personally, my stance mentioned in #615 (comment) still holds. I think most of the planned repo changes have been done, but I see 0 user tickets or bug reports that would cause us to invest in such a heavy refactoring. Note that any changes to split assemblies would need follow-up changes to .NET SDK targets as well as all post-build tooling, etc. Additionally, we also have a Roslyn bug which causes these CodeFix only analyzer assemblies to show under the Analyzers node in solution explorer, which is just noise.

Basically, at this point I see 0 value add for doing this work as compared to addressing tons of user submitted analyzer bug reports on this repo, especially given the resource allocation for this repo.

[Evangelink]

Makes total sense :)

[sharwell]

Agree that deprioritization seems better than closing.