Don’t do Reflection, do DGML

If you are analyzing your solutions and projects via reflection, you can’t do it any better than Microsoft. Even ReSharper does not come close. What did they produce? An XML output called DGML. Why not leverage it?

In their output they provide:

• References
• Dependencies
• Return values
• Call graphs
• …

And it is not meant just for human consumption/interpretation as it is XML with a well published schema.

I bet you can’t get call dependencies via reflection (except for using some FxCop DLLs and/or developing your own Reflector add-on).

But the data is already there if you use VS Ultimate/Premium, and as XML; the only question is how to practically use this output. In a previous article I mentioned my DGML API…

Some use-cases:

• Find all unneeded references in a solution
• Call graphs
• Property usage in functions
• …

You can also just produce your own HTML5 reporting tool via SVG (which I did); no need for Visual Studio, let alone Ultimate.

GAC Viewer

Here is a GAC viewer inside Visual Studio:

If you double-click the assembly it is added to the references of the current project:

Internal To Public

Oftentimes, you need to access internal classes of assemblies for which you don’t have the sources. There are many good arguments why you should not do this:

1. If it is internal, it is for a good reason.
2. It will probably be modified in a subsequent version.
3. It has side-effects that you are not aware of.

Argument 1 is weak; if it is not private, it is for a good reason: because it is re-used in some other part of the assembly. Thus argument 2 is weaker, because the assembly is less maintainable by its manufacturer.

On the other hand, there are many hidden jewels in assemblies that we use every day, especially from Microsoft. So some of the other reasons why classes are marked as internal are:

1. They don’t want to clubber the namespace with unnecessary detail.
2. They don’t want to write documentation for it; in the case of Microsoft, the MSDN documentation is already very weak, even for over-mature things such as EnvDTE, often consisting of text derived from xml comments giving just the name of a method and the names of its parameters. Imagine if they were to write these comments for non-vital parts of the library, let alone document it (which they have already bypassed).

An example of a useful internal class resides in the Microsoft.Build.dll; it is called SolutionParser and parses any .sln file, for which there is no schema, of course.

So, suppose I have the binaries of the following library:

Now suppose I want to access the very much uninteresting property “Property” of the “Class” class. Of course, I have to use reflection and write some code similar to the following:

Then I can access the property that I was going after:

var c = new SampleLibrary.Reflected.Class();
var p = c.Property;

As all this is very tedious to do by hand and quite automatic anyway, so I developed a DSL to do it for me; it is posted on the Visual Studio Gallery.

Idea: Create a repository of useful internal classes in Microsoft’s assemblies.

The property might as well be private:

Or the class itself:

The end result is of course the same.

Here is a screenshot:

And here is the screenshot upon conversion: