Home Dashboard Directory Help
Search

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


Status: 

Closed
 as Won't Fix Help for as Won't Fix


0
0
Sign in
to vote
Type: Bug
ID: 480951
Opened: 8/5/2009 3:26:04 AM
Access Restriction: Public
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

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:

N1.C1<T>
N1.C1<T>.f1<Q>

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

C1
f1

when you would expect:

C1<T>
f1<Q>

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

Thanks,
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.
Sign in to post a workaround.