Download Source Code: InstanceBrowser.zip - 36.23KB
 |  |  |
| Open-source code of a generic Instance Browser, a true "object" browser which, like other metadata browsers, dynamically discovers and presents metadata from loaded assemblies, but also allows single-click instantaneous and immediate object instantiations. Drill-down navigation across collections and objects, returned by runtime execution of their properties or methods. | ||
 | |  |
Overview
I've always wondered why metadata browsers are sometimes improperly named "object" browsers. No big deal, you might say. However, this may create some confusion in the years to come, as metadata presentation tools will continue to evolve. Today's metadata browser are rather static class or type browsers, because they represent just physical containers (assemblies, components, modules) and object model abstractions (classes, types and members).
Just look at the Watch Window in break mode, after you selected a variable, from your Visual Studio. Here you have a runtime object, with all its property and field values. What's interesting in latest versions of this IDE, you can drill-down through associations or derivations of this objects, and discover aggregations or related objects.
Metadata is auto-discovered, no need to know the property names or the associations between classes. At the other end, look at your Object Browser. You navigate through the hierarchy of assemblies, namespaces, types and type members. But you cannot dynamically instantiate class objects from here. It's just static metadata.
A "real" Object browser should also show objects (or class instances), dynamically created at runtime. A veritable object browser (or Instance Browser) would combine metadata auto-discovery with the dynamic drill-down navigation facilities we have now in Visual Studio, but only in debug mode. No need to enter in break mode and watch a certain variable. We should be able to navigate through metadata to a constructor or static member, and invoke that member with a single click.
Instance Browser Design
Let's design such a simple Instance Browser. We'll stick to the hierarchical tree-based structure. Traditionally, most browser also present list elements in a grid or list view, individual property values for a single-selected object and some textual documentation. We might exclude, the list for now, and expand collection elements as child nodes. For single-selections, we already have a rich and interesting .NET control: the PropertyGrid!
As starting point, we should be able to look for a type. Like Visual Studio's Object Browser, we'll present top-level nodes for loaded assemblies and namespaces. One folder node will expose all loaded assemblies and their namespaces. Another top folder node will show all namespaces, no matter which assemblies implement them. We should be able to load external assemblies in our browser, but we will also load by default a couple of .NET Framework assemblies.
Under each namespace node, we'll expose types. It would make sense to present only "navigable" types, from which we can create instances, or with static members. For this reason, we will exclude interfaces (always abstract), generic types (used only as templates for definition of concrete types), delegates and event arguments, exception and attribute classes. Primitive types, including enums and strings, are also too "simple" to explore in depth, and there is no huge interest to instantiate these types.
We may exclude inherited members, but we will add another interesting feature: "virtual" cast members, to the base types. They will be represented by member nodes that look like properties, but will perform a "cast" to one of the base types or implemented interfaces.
Another powerful feature: automatic recognition of "collection" instances, that auto-expand into their containing objects. Collection instances are easily identified in .NET, because they all implement at least the IEnumerable interface. This stands for arrays, lists, regular collections and dictionaries. It's true, in our tree-oriented view, that collections with large number of objects may take longer time to expand, and this isn't good. Anyway, the view offered by a collection object is complemented by the PropertyGrid, which has a similar child-oriented look.
Instance Navigation on .NET Framework Classes
Many .NET Framework classes offer immediate information and we should get it instantly, without writing one single line of code. Take, for instance, the System.Diagnostics.Process class, which is a wonderful entry point for a small but useful browsable model.
You can either start with the current process, or get all running processes. From each Process you can get the collection of running Threads or the physical Modules.
Another example with immediate results is File System's DriveInfo --> DirectoryInfo --> FileInfo hierarchy, classes implemented in System.IO. The starting point is the static method DriveInfo.GetDrives(). From each drive, you get the RootDirectory, then go down on subdirectories and files, from each folder.
Both these object models are great to navigate on, and their class associations reflect the natural structure of the Process or File System models.
Unfortunately, not all .NET Framework Classes have been implemented with a natural object-oriented approach in mind. Take the Registry-related classes from Microsoft.Win32. We'll not go into details here, but we will show in another article how you can easily build some wrapper classes that better reflect the natural model of the Registry, and allow instant drill-down navigation in our Instance Browser.
WARNING! While this single-click generic drill-down object navigation may look great (and it is!), be careful what methods you select and instantaneously execute. In this initial prototype, we selected only members with no parameters, but many object models expose classes with no-parameter methods that can harm your computer or delete precious information without warning.
Even the two friendly models presented before (Process and File System) have methods that can immediately kill processes, close windows or delete files and folders. "Get" properties should never change the state of an object - this would be very bad design - but this exists. Unless you are very familiar with the classes you go through, be careful when you click and expand nodes with members you don't know much about! Whenever you find names like Delete, Remove, Change, Close, Kill, think twice before you click! Do not expect friendly confirmation messages like "Do you really want to delete this?", because they are not usually implemented at this low level. This is a tool for software developers, supposed to be more careful and know what they do...
Subscribe and Share: 
