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