EnvDTE.CodeElement.Name doesn't include type placeholder for generics types or methods - by Carlos J. Quintero

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 480951 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 8/5/2009 3:26:04 AM
Access Restriction Public


The EnvDTE.CodeElement class of the automation model (EnvDTE) provides the Name and FullName properties. The FullName is the Name prefixed by the names of parent code elements (namespace, class, etc).

When you have generic code elements such as:

namespace N1
   class C1<T>
       public void f1<Q>()

and you use the file code model to get their full names, you get:


So far so good. However, for names you get:


when you would expect:


since the <...> portion is actually part of the name, that is, C1 and C1<T>, C1<T,U> are totally different types and they can even exist at the same time in a class library.

Notice that the Class View toolwindow, which shows names (and not full names), correctly shows C1<T> and f1<Q>. The CodeElement.Name property should follow suit...
Sign in to post a comment.
Posted by Microsoft on 8/6/2009 at 2:45 PM
Hi Carlos,

As I mentioned in this related CodeModel bug (http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=477937), we're currently working on a longer term investment in a public language model. This API will do a much better job than the existing Code Model in surfacing our compilers and will provide a richer representation of code.

I hear you that the limited generics support in Code Model is a pain though. In fact, we've had both internal and external requests to have generics better supported, but it unfortunately turns out that it's quite expensive to implement. Given that this limitation has been around since previous releases, the non-trivial cost, and my earlier comments about the public language model, I'm going to "Wont Fix" this bug in favor of investing resources in areas such as performance, regression from previous releases, etc. If you have any further questions/comments, feel free to either re-activate the bug or contact me directly at djpark at microsoft.com.

DJ Park
C# IDE, Program Manager
Posted by Microsoft on 8/5/2009 at 11:10 PM
Thanks for your feedback.

We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution.
These specialized experts will follow-up with your issue.