Saturday, June 30, 2007

ANTLR 3 C# runtime - source code found!

> Does anyone know why the source code is not available? Is it closed
> source? What's the licence?

While these questions remain unanswered, I have found an amazingly good tool called "Reflector" and a disassembly helper. For more information see

I have discovered that the assembly contains full symbol information including local variable names, and the tool outputs suprisingly high-level code. If you don't want to reconstruct it yourself, you can get it here:

The add-in even creates a project file! Right on!

Monday, June 04, 2007

SharpDevelop add-in system

I'm having tremendous difficulty understanding SharpDevelop's add-in system. Although they offer a free book (Dissecting a C# Application: Inside SharpDevelop), I find its explanation of Codons/addins/etc. to be almost incomprehensible. So I'll investigate them and put my tentative findings here.

The add-in tree: Basics

See below for locations (in the source code distribution) of classes mentioned here.
  1. All extensions to #develop (and most core features including the entire GUI, except the splash screen) are add-ins. All addins are stored in C:\Program Files\SharpDevelop\2.1\AddIns\AddIns, except one whose XML file is in the parent folder.
  2. Each add-in must have an XML file that describes it, with an .addin extension. Addins use "XCopy deployment"; to add an addin to SharpDevelop, simply create a folder that contains the add-in, then copy your folder to any appropriate subfolder of the AddIns folder mentioned above. The code of an addin is placed in one or more DLLs.
  3. The AddIn tree is a tree of AddInTreeNode objects. Informally, a distinction is sometimes made between nodes that have "Codons" and those that don't: An AddInTreeNode is called a "path" if there is no "Codon" attached or a "node" if there is. However, this is confusing terminology because a route to a AddInTreeNode is often called a "path" regardless of whether the object at that path has a codon; meanwhile, according to its name, an AddInTreeNode is a node (even if it lacks a codon).
  4. The AddInTreeNode.ChildNodes property returns the child nodes as a Dictionary{string, AddInTreeNode}. The AddInTreeNode class lacks a link to its parent node.
  5. "Codon" appears to refer to the code of an add-in, whereas an AddIn seems to refer to (a) the XML file that contains the codon and (b) an instance of ICSharpCode.Core.AddIn which represents the XML file in memory. Ironically, AddInTreeNodes do not contain add-ins, only Codons. An add-in can contain multiple codons (at different places in the add-in tree). Also, an add-in can have "conditions" and "doozers" (discussed later).
  6. ICSharpCode.Core.AddInTree (a static class) contains the root of the Add-In tree, which can be reached by calling AddInTree.GetTreeNode(null). However, usually you want to look up something deep in the tree, so call AddInTree.AddInTreeNode("/path/to/the/node"). The path to use is specified in an addin's XML file.
  7. All codons are stored in the add-in tree, whereas all AddIns are stored in a flat list returned by the AddInTree.AddIns property.
  8. According to doc\technotes\AddInTree.rtf (in the souce distro), "In the ICSharpCode.Core implementation, the AddInTreeNode class has a Codon property which is null for paths and points to a Codon instance for nodes." But in fact, the Codon property returns a List{Codon} and I don't know why.
  • ICSharpCode.Core.AddInTree: src\Main\Core\Project\Src\AddInTree\AddInTree.cs
  • ICSharpCode.Core.AddInTreeNode: src\Main\Core\Project\Src\AddInTree\AddInTreeNode.cs
  • ICSharpCode.Core.AddIn: src\Main\Core\Project\Src\AddInTree\AddIn