On option is to use the Automation interfaces. Look up the FileCodeModel interface and it's related interfaces. FileCodeModel is
a property of the ProjectItem interface. A ProjectItem represents a node in you project tree.
In your add-in or package, you can get the selected ProjectItem by calling
ProjectItem item = serviceProvider.GetService(typeof(ProjectItem))
You can get the Project interface of your hierarchy by calling:
GetProperty((uint)VSConstants.VSITEMID_ROOT, (int)__VSHPROPID.VSHPROPID_ExtObject, out extObj));
EnvDTE.Project project = extObj as EnvDTE.Project;
Then from the Project interface, you can enumerate all the ProjectItem objects, and their respective FileCodeModel.
I don't think the Object Browser uses the FileCodeModel - I believe it is using reflection and metadata directly from the assemblies.
The SVsObjectManager looks promising, but I have not used it.
Cheers,
Stu
> I'm trying to find a way to get object information very similar to what
> can be found in the object browser. I found the SVsObjBrowser service,
[quoted text clipped - 10 lines]
> reflected information stored in it, and if so, how can I query it for
> information?
slush_puppy - 24 Apr 2006 13:38 GMT
Yeah, I'm using the code model right now for the "in-project" stuff,
but I want to be able to get the same type of information for all of
the included references, etc... just like intellisense has at its
fingertips. It seems like a huge waste of memory for all of the
features that need that information to all have their own cache/lookup
for them, so I figured that VS would have some sort of package that
offered that service. It seems like such a good idea for a service,
something that lots of other packages need.
FWIW, Class View, Solution Explorer and Objects Browser all give full
reflection details without the existence of any assemblies, so they
must use the code model as well. I believe that CV and SE use
UIHierarchy and OB is just it's own service.