Find all references on a class name display duplicate records

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

Invoke "Find All References" on a class name MyClass in line 10
Result: Line 7 is displayed 3 times, one at position 4 and two identical records at position 22

namespace ConsoleApp1
{
	class Program
	{
		static void Main(string[] args)
		{
			MyClass obj = new MyClass(); // Line #7
		}
	}
	public class MyClass // Line #10 Invoke Find All References here
	{
		public MyClass()
		{
		}
	}
}

---

Original Comments

Visual Studio Feedback System on 9/25/2019, 01:47 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Visual Studio Feedback System on 10/7/2019, 00:54 AM:

This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.

Dean Jackson on 11/22/2019, 06:03 AM:

I have the same problem! (using version 16.3.x). Yes, the same line (like your #7) is listed 3 times in the results. So, If you really do have 8 references, that will be 24 items in the results list!!

Visual Studio Feedback System on 3/31/2020, 05:38 PM:

Thank you for sharing your feedback! Our teams prioritize action on product issues with broad customer impact. See details at: https://docs.microsoft.com/en-us/visualstudio/ide/report-a-problem?view=vs-2019#faq. In case you need answers to common questions or need assisted support, be sure to use https://visualstudio.microsoft.com/vs/support/. We’ll keep you posted on any updates to this feedback.

---

Original Solutions

(no solutions)

[mavasani]

Tagging @CyrusNajmabadi - the references are theoretically correct - 2 references to type name and 1 reference to ctor invocation. Do we want to show a single type name reference instead (i.e. do not show it as a type name reference when it is used in context of an object creation expression)?

[sharwell]

This should have been fixed by #34617

[sharwell]

Here's the intended design:
#34617 (comment)

[CyrusNajmabadi]

The current behavior is correct and desirable: