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

Adding Analyzers Via a Project Reference #18093

Open
JasonBock opened this issue Mar 23, 2017 · 12 comments

Comments

@JasonBock
Copy link

commented Mar 23, 2017

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

This comment has been minimized.

Copy link
Member

commented Mar 31, 2017

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 👍

@Pilchie

This comment has been minimized.

Copy link
Member

commented Apr 3, 2017

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.

@Pilchie Pilchie added this to the Unknown milestone Apr 3, 2017

@heejaechang

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2017

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

@MartinJohns

This comment has been minimized.

Copy link

commented Jul 14, 2017

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

This comment has been minimized.

Copy link
Member

commented Jul 16, 2017

Not yet I'm afraid :(

@heejaechang

This comment has been minimized.

Copy link
Contributor

commented Jul 17, 2017

tagging @jinujoseph

@jinujoseph jinujoseph modified the milestones: 16.0, Unknown Jul 17, 2017

@jinujoseph

This comment has been minimized.

Copy link
Contributor

commented Jul 17, 2017

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

@kierenj

This comment has been minimized.

Copy link

commented Oct 18, 2017

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

This comment has been minimized.

Copy link
Member

commented Jul 17, 2018

Have you tried doing:

    <ProjectReference Include="..\ProjectB\ProjectB.csproj">
      <ReferenceOutputAssembly>false</ReferenceOutputAssembly>
      <OutputItemType>Analyzer</OutputItemType>
    </ProjectReference>
@trigger-segfault

This comment has been minimized.

Copy link

commented Oct 25, 2018

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

@jinujoseph jinujoseph modified the milestones: 16.0, Backlog Jan 18, 2019

@jinujoseph jinujoseph added this to Backlog in IDE: InternalPriority via automation Jan 18, 2019

@ProductiveRage

This comment has been minimized.

Copy link

commented May 14, 2019

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!

@jinujoseph jinujoseph moved this from Backlog to Priority 4 in IDE: InternalPriority Jun 7, 2019

@jinujoseph jinujoseph moved this from Priority 4 to Priority 1 in IDE: InternalPriority Jun 7, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.