I have made some progress developing a Smalltalk like System Browser for reflecting .NET Types with an IronPython embedded console interpreter to manipulate the reflected Types.  Not as much progress as I would like, but with a few hours a week, what can you do.

 

You can reuse code to increase productivity.  Here is something that seems a relatively simple task to do, I want to add an icon (bitmap actually) to each item in my list boxes that represent assemblies, types, properties, methods and events.  It turned out not to be so simple as a .NET listbox does not have this capability out of the box.  Now what?  As I have suggested in the past, the WWW is an excellent (unstructured) catalog of reusable software.  I make the assumption that each one of the components I am looking for to build this application has already been built by someone.

 

Searching away brought up several specialized listbox implementations, but this one I liked the best is called. .NET Color Listbox.  Alex has done a great job here as his implementation provided not only the ability to add the bitmaps to each item in the listbox, but also uses DoubleBuffering to get rid of the flickers when scrolling looks nice and smooth.

 

Where to get the bitmaps that represents assemblies, classes, methods, etc.?  If you have Visual Studio 2005 installed, you will find them at: C:\Program Files\Microsoft Visual Studio 8\Common7\VS2005ImageLibrary as VS2005ImageLibrary.zip.  So far so good, no reinventing the wheel yet.

 

While I still have more work to do on the System Browser part in the way of trimming namespaces in the listboxes, hiding properties that have public assessors, making the constructor bitmap different than the method bitmap, etc., I am going to move onto code comments.

 

So when I am reflecting an assembly and its Types, I want to include the code comments, if any are supplied, as well.  While I know about the XML Document Comments in C# and have used them for some time, you can use Ndoc for, C# and XML Source Code Documentation. In other words, API documentation ala MSDN style.

 

However, it turns out that the C# comments you put in your source files never gets compiled into the assembly.  I thought maybe the XML document was an embedded resource as indicated by this example of, Working with Embedded Data :

 

Using System.Windows.Forms as myAssembly

string[] names = myAssembly.GetManifestResourceNames();
foreach(string name in names)
{
   Console.WriteLine(name);
}

Nothing in there other than bitmaps, icons and cursors.  While you can embed the XML document as a resource, it is not done at compile time nor included in the .NET FCL.

I am a bit surprised by this.  Having the assembly and the documentation for the assembly in two separate files violates the principle of encapsulation in my mind.  The first thing to get lost when moving an assembly around is the XML documentation file.

 

I wonder why two separate files?  Yes, I know that the XML doc is also used for IntelliSense comments, but what if it was in the assembly and you reflected on it from the assembly?  Is it a size issue?  Looking in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 I see that the largest XML file is mscorlib.xml at approximately 7 meg in size whereas the actual mscorlib.dll is just over 4 megs in size.  However, the majority of other XML files are in the 100Kbyte range.  So maybe memory could be an issue, but at the very least, I would like to have the option of embedding my comments in the DLL so that if other people are reflecting on my Class library, they can also read the comments. 

 

Ok, well, I can still read the comments from the XML document files and load them into the System Browser.  Sounds like more code reuse as I am sure someone has written this before.  And as it turns out, yes in a couple of ways.  One is "XML Comments" which loads the XML documentation based on what you are reflecting on.  I have this implemented in the System Browser with one line of code.  The other code sample is called, Documenting .NET Assemblies which generates code comments directly from an assembly, even if there is no source comment XML dcoumentation.  Looks promising.

 

I know this post does not have much to do with IronPython (yet), but is the setup for embedding the IronPython interactive console interpreter into the System Browser.  The point about using IronPython to dynamically build apps from the .Net FCL and other assemblies requires a System Browser so that we can inspect the Types, grok the meaning and start dynamically building apps all from the same window.

A couple of weeks ago I suggested a way of dynamic programming with IronPython.  Essentially it is a combination of using a Smalltalk like System Browser to browse types using .NET reflection and embedding an IronPython interactive interpreter into the System Browser to manipulate the reflected types.

 

Why would I want to do this?  While I really like Visual Studio, which I use for my day job, sometimes it takes forever to build a simple prototype or experiment with a new class library.  For me, I want to see an app up and running as soon as possible, but at the same time leveraging class libraries and third party components.  And I want to do this dynamically.

 

I am also one of those people that learn best by doing.  While I can read the framework class library documentation till I fall asleep, (.NET 2.0 has 29,000 types in it!), I like to play with the types live and through some experimentation, find out how they work.  Sure I can use Visual Studios Object Browser or Lutzs Reflector (even as an add-in to VS), but it is not suited for how I work.

 

Maybe I am old school, but I like the Smalltalk System Browser approach to software development.  In .NET it is a little harder because the Smalltalk world was really simple, you had classes, instances and methods.  Thats it.  In .NET it is more complicated, but still what I am interested is inspecting an assembly for its types and for each type, what are its public properties, methods and events in other words I am using the System Browser as a way to work with the types, not just browse them.  Having an IronPython console window embedded in the System Browser lets me play with those types dynamically.  To me it is the best of both worlds, leveraging pre-built types to dynamically build my prototype or application.

 

As a side note, this blogs focus is on software industrialization.  I have explained what that means in other posts, but one aspect of software industrialization I would like to point out is simplicity.  The ability to browse libraries using the Smalltalk System Browser paradigm and then use those libraries interactively in the same window is simple.

 

The System Browser is initially built as a C# application, just to get parts of the code design down of what I want and in a language I already know.  I am also mirroring the development of the application as a Python Windows application, which is what the final product will be.  While I have run into a few problems, mostly my own, I have had excellent support from the folks at the IronPython forum.  Of course, I have already made a fool of myself on the forum by repeatedly submitting a chunk of Python code that had a (read: my) mistake in it, which I missed on a couple of occasions.  Maybe if I slow down a bit, I will see it before I submit it   Thanks to Dino, Vagmi and J. M. for being patient.

 

I should also point out that for Windows Forms programmers looking to get a tutorial on creating Windows Forms dynamically using IronPython, should look at Michael Foords excellent tutorials. 

Back to the System Browser - maybe I will have something implemented in a couple of weeks or months.  Stay tuned.