Roslyn: Adding Analyzers Via a Project Reference

[JasonBock]

Version Used:

Visual Studio 2017 (though this applies to 2015 as well)

Steps to Reproduce:

I'd like to be able to add analyzers to a project via a project reference. For example, let's say I have this solution setup:

• Solution
  
  
  
  • ProjectA
  
  
  • ProjectB
  
  

ProjectB contains analyzers that are only used for code in ProjectA. I can only add analyzers from an assembly reference, not a project reference. I can do this now by referencing the DLL created by building ProjectA (e.g. bin\Debug\ProjectA.dll) but then I run into weird rebuilding and locking issues from Visual Studio. I could get around this by using this approach to version the assembly (https://stackoverflow.com/questions/826777/how-to-have-an-auto-incrementing-version-number-visual-studio#826850) but then I can't really control its version number. It would be far simpler to have the ability to right-click on "Analyzers", select "Add Analyzers" and have the ability to reference a project.

Expected Behavior:

Being able to add analyzers via a project reference.

Actual Behavior:

That option doesn't exist.

(Note, this is more of a feature request than a bug, but I tried to conform to the given format)

[sharwell]

Getting this to work on the command line probably wouldn't be too difficult. The UI for adding the reference is almost complete as well - it's just that "Projects" section you see in the Add→Reference... dialog is not visible on the Add→Analyzer... dialog.

With that said, the implementation for the overall experience is very hard. In theory, typing a change in one file of your solution can affect the way the IntelliSense compiler behaves for other files in your solution. I don't have any specific proposal for the way it should behave at this time; I just wanted to point out which part of this feature request makes it particularly challenging.

But I have to admit. This would be one of the coolest features ever, so for that :+1:

[Pilchie]

I'm pretty sure @heejaechang has thought about using the second process for this in the long term, but it's unfortunately not likely to happen anytime soon.

[heejaechang]

great idea but that kind of dynamic analyzer change would be hard to track... my idea was little bit simpler version which make writing new analyzer easier. this idea if scoped down to special context of writing new analyzer then, could be done... actually.

[heejaechang]

@mavasani @jinujoseph how do you think? this seems good idea on our analyzer pad idea we had before.

[MartinJohns]

I would absolutely love this feature. Would make integrating custom analyzer much nicer without having the hassle of integrating a custom private NuGet feed first.

@heejaechang @Pilchie Did you make any progress or had any more discussions on this by chance?

[Pilchie]

Not yet I'm afraid :(

[heejaechang]

tagging @jinujoseph

[jinujoseph]

Very valuable , not sure we can fit this for 15.5 , lets target for dev16

[kierenj]

This would be awesome. Currently we use "sanity check" unit tests, which use reflection and NCrunch to give feedback about certain classes not being serialisable, missing unit test classes, and hope to extend this to look at architecture rules.

I don't think many would mind if it's realtime or not (per-keypress on the analyser project): using the last-built version should be fine

[ericstj]

Have you tried doing:

    <ProjectReference Include="..\ProjectB\ProjectB.csproj">
      <ReferenceOutputAssembly>false</ReferenceOutputAssembly>
      <OutputItemType>Analyzer</OutputItemType>
    </ProjectReference>

[trigger-segfault]

    <ProjectReference Include="..\ProjectB\ProjectB.csproj">
      <ReferenceOutputAssembly>false</ReferenceOutputAssembly>
      <OutputItemType>Analyzer</OutputItemType>
    </ProjectReference>

This works, but when it seems to produce an unsightly warning on the Dependencies item due to it internally having some issue with the referenced project. The analyzer does work correctly though.

[ProductiveRage]

Does the 16.0 milestone mean that hopefully it will land in a release of Visual Studio 2019 one day?

I've used the suggested "ProjectReference" approach above and I don't get any "unsightly warning" (which I'm very happy about!). When I rebuild the Analyzer project, I have to unload any target project and then rebuild it but that's not too bad. It would be amazing if this _was_ built into VS, though!

[alrz]

With that said, the implementation for the overall experience is very hard. In theory, typing a change in one file of your solution can affect the way the IntelliSense compiler behaves for other files in your solution

@sharwall Can this be reconsidered along with generators? I think implementation challenges are somewhat similar.

(Also the same thing can be applied to generators -- a project reference to a generator project)