{"id":695,"date":"2009-10-02T00:00:00","date_gmt":"2009-10-02T00:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/net-reflector-meets-the-codedom\/"},"modified":"2021-05-17T18:36:39","modified_gmt":"2021-05-17T18:36:39","slug":"net-reflector-meets-the-codedom","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/development\/dotnet-development\/net-reflector-meets-the-codedom\/","title":{"rendered":".NET Reflector meets the CodeDom"},"content":{"rendered":"
\n

Introduction<\/h2>\n

Reflector does a wonderful job translating an Assembly into higher level languages.  When you select “Disassemble”, this is what is happening in the background.  The Metadata in the Assembly in translated to an appropriate representation in C# or VB or whatever languages you have installed.  Reflector takes things a step further than this marvel,  providing the mechanisms needed to add virtually any functionality that you find missing.  This includes creating your own “language” to disassemble to.<\/p>\n

For our purposes, we will define a “Reflector Language” as a piece of code that converts an object from the Reflector object model into useful text.   For C#, VB.Net, etc, these objects are translated into the textual representation that will produce the same metadata that was converted.<\/p>\n

Here we will step through creating a “Reflector Language” that will result in the CodeDom code needed to generate the code that was parsed.   <\/p>\n

Anatomy of a Reflector Language<\/h2>\n

When creating a language from scratch you have to create the lexical analyzer and the parser.   The lexical analyzer will separate a character string into valid tokens for your language.  The parser assembles these tokens into something meaningful, based on the grammar for your language.  <\/p>\n

We won’t have to worry about most of this.  Reflector will present us with meaningful objects from the Reflector.CodeModel<\/b> namespace based on the meta data from the Assembly being parsed.  To build our “language”, we need to write code explaining what to do when  each of these objects are encountered.   We don’t really care about how Reflector determined that we have a ConditionStatement<\/b>,; we simply focus on what our language needs to do when a ConditionStatement<\/b> is found.<\/p>\n

There are a handful of objects that you will need to implement in order to define a language.  Remember that an Add-in is just a class library.   In our class library, we must provide an object implementing the Reflector.IPackage<\/b> interface, the Reflector.CodeModel.ILanguage<\/b> Interface, and the Reflector.CodeModel.ILanguageWriter<\/b> interface.   By themselves none of these are too difficult to implement.<\/p>\n

The IPackage<\/b> object will provide the details needed to register our language with Reflector.   Specifically, we need to provide a Load and Unload method that will register our language with the LanguageManagerService<\/b><\/p>\n

public class CodeDomLanguagePackage : IPackage\n    {\n        \/\/ Fields\n        private CodeDomLanguage language;\n        private ILanguageManager languageManager;\n \n        \/\/ Methods\n \n        #region IPackage Members\n \n        public void Load(IServiceProvider serviceProvider)\n        {\n            language = new CodeDomLanguage();\n            languageManager = (ILanguageManager)\n                serviceProvider.GetService(typeof (ILanguageManager));\n            languageManager.RegisterLanguage(language);\n        } } \n \n        public void Unload()\n        {\n            languageManager.UnregisterLanguage(language);\n        } \n \n        #endregion\n    }\n<\/pre>\n
The ILanguage<\/b> object has one method of interest.  GetWriter<\/b> will be called by Reflector as needed and  allow us to associate an IFormatter <\/b>and an ILanguageWriterConfiguration<\/b> to our writer.<\/p>\n
public ILanguageWriter GetWriter(IFormatter formatter,\n                ILanguageWriterConfiguration configuration)\n{\n    return new CodeDomLanguageWriter\n       (formatter, configuration);\n}\n<\/pre>\n
The ILanguageWriter<\/b> provides various methods that will be called by Reflector when different types of code are to be processed.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\n
WriteAssembly<\/p>\n<\/td>\n
\n
Called when you disassemble an Assembly<\/p>\n<\/td>\n<\/tr>\n
\n
WriteAssemblyReference<\/p>\n<\/td>\n
\n
Called when you disassemble the Assembly references<\/p>\n<\/td>\n<\/tr>\n
\n
WriteEventDeclaration<\/p>\n<\/td>\n
\n
Called when you disassemble an Event Declaration<\/p>\n<\/td>\n<\/tr>\n
\n
WriteExpression<\/p>\n<\/td>\n
\n
Called when you disassemble an Expression<\/p>\n<\/td>\n<\/tr>\n
\n
WriteFieldDeclaration<\/p>\n<\/td>\n
\n
Called when you disassemble a Field declaration <\/p>\n<\/td>\n<\/tr>\n
\n
WriteMethodDeclaration<\/p>\n<\/td>\n
\n
Called when you disassemble a Method declaration<\/p>\n<\/td>\n<\/tr>\n
\n
WriteModule<\/p>\n<\/td>\n
\n
Called when you disassemble a Module<\/p>\n<\/td>\n<\/tr>\n
\n
WriteModuleReference<\/p>\n<\/td>\n
\n
Called when you disassemble an embedded reference at a module level<\/p>\n<\/td>\n<\/tr>\n
\n
WriteNamespace<\/p>\n<\/td>\n
\n
Called when you disassemble a Namespace<\/p>\n<\/td>\n<\/tr>\n
\n
WritePropertyDeclaration<\/p>\n<\/td>\n
\n
Called when you disassemble a Property Declaration<\/p>\n<\/td>\n<\/tr>\n
\n
WriteResource<\/p>\n<\/td>\n
\n
Called when you disassemble an embedded Resource<\/p>\n<\/td>\n<\/tr>\n
\n
WriteStatement<\/p>\n<\/td>\n
\n
Called when you disassemble a Statement in isolation<\/p>\n<\/td>\n<\/tr>\n
\n
WriteTypeDeclaration<\/p>\n<\/td>\n
\n
Called when you disassemble a Type Declaration<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
These various methods allow you to customize what gets displayed in the Disassembler window as the user clicks on the various levels in the TreeView.   When you leave a blank implementation then nothing will be displayed at that level in the TreeView.   At a minimum, you should display an informative message about what is being viewed.   For example, this may be all that you need for a minimal implementation of VisitNameSpace<\/p>\n
public void WriteNamespace(INamespace value)\n{\n    formatter.Write (\"Visiting the \" + value.Name + \" namespace\");\n    formatter.WriteLine ();\n    formatter.Write(\"It has \" + value.Types.Count + \" types\");\n    formatter.WriteLine();\n \n}\n<\/pre>\n
As in life, the devil is in the details.   Providing the details for how to process the various language structures is where the complexities come in.<\/p>\n
Languages are Recursive<\/h2>\n
Language components are defined in terms of themselves.   This is true for natural languages like English, French, and Spanish.   It is also true for programming languages like C#, VB, and Java. This makes their definitions recursive.   <\/p>\n
A simple example in English is illustrated through the following series of phrases:<\/p>\n
    \n
  • My car  <\/li>\n
  • My  father’s car  <\/li>\n
  • My  father’s brother’s car  <\/li>\n
  • My father’s brother’s wife’s car etc. <\/li>\n<\/ul>\n
    As prevalent as this is with Natural Languages, it is even more widespread with computer programming languages.   There are two main base Interfaces in the Reflector.CodeModel<\/b> namespace, IStatement <\/b>and IExpression<\/b>.   These show up widely in recursive definitions.   For example, an IBinaryExpression<\/b> is an IExpression<\/b> with two properties, Left and Right.   Both of these properties, are of type IExpression<\/b> and can implement any interface derived from IExpression<\/b>, including IBinaryExpression<\/b>.  This makes the definition recursive.    This also means that while parsing nearly every language structure, you may also encounter nearly any language structure.<\/p>\n
    The Visitor pattern makes it easier to deal with some of the complexities that can arise from the recursive nature of the language definitions.   Instead of having to keep in mind every possibility when we encounter an IExpression<\/b>, we can defer that responsibility to a more generalized VisitExpression<\/b> and let it figure out the specific derived interface the object being visited implements.<\/p>\n
    Instead of adding code to support the various types that you can encounter in each type, we can write the code for each type in its own method and then call the Visitor to “visit” every possibility for the derived types.    <\/p>\n
    A Sample Visitor<\/h2>\n
    The VisitBinaryExpression<\/b> may have an implementation similar to this:<\/p>\n
     \npublic override void VisitBinaryExpression(IBinaryExpression value)\n{\n    if (value != null)\n    {\n        System.CodeDom.CodeBinaryOperatorExpression exp =\n            new System.CodeDom.CodeBinaryOperatorExpression();\n        string name = \"binaryExpression\";\/\/ +value.ToString();\n        formatter.Write(\"System.CodeDom.CodeBinaryOperatorExpression \"\n            + name +\" = new System.CodeDom.CodeBinaryOperatorExpression();\");\n        formatter.Write (MethodTarget.BuildCodeString(name));\n        formatter.WriteLine();\n        codeStack.Push(new CodeStackItem(name, \"Left\", false));\n        VisitExpression(value.Left);\n        codeStack.Pop();\n        formatter.WriteLine ();\n        switch (value.Operator)\n        {\n            . . .\n        }\n        formatter.WriteLine();\n        codeStack.Push(new CodeStackItem(name, \"Right\", false));\n        VisitExpression(value.Right);\n        codeStack.Pop();\n        formatter.WriteLine();\n    }\n}\n \n<\/pre>\n
     Inside the switch statement, we handle the various values in the BinaryOperator<\/b> enumeration.   The key things to note here are the two calls to VisitExpression<\/b>, the use of codeStack<\/b>, and the call to MethodTarget<\/b> BuildCodeString<\/b>.   The code stack allows us track context for what we are visiting.   The CodeStackItem<\/b> includes the name of the object that triggered  the visitation (the ActiveBlock<\/b>), the name of the property that we are visiting (the ActiveCollection<\/b>), and an indicator for whether or not this is to be a collection or a single item (IsCollection<\/b>).<\/p>\n
    VisitExpression<\/b>, is a long but simple method blindly calling every visitor derived from IExpression<\/b> looking for matches:<\/p>\n
    public void VisitExpression (IExpression value)\n{\n    if (value != null)\n    {\n        VisitAddressOfExpression(value as IAddressOfExpression);\n        VisitAddressOutExpression(value as IAddressOutExpression);\n        VisitAddressReferenceExpression(value as\n             IAddressReferenceExpression);\n        VisitAnonymousMethodExpression(value as IAnonymousMethodExpression);\n        VisitArgumentListExpression(value as IArgumentListExpression);\n        VisitArgumentReferenceExpression(value as\n             IArgumentReferenceExpression);\n        VisitArrayCreateExpression(value as IArrayCreateExpression);\n        VisitArrayIndexerExpression(value as IArrayIndexerExpression);\n        VisitAssignExpression(value as IAssignExpression);\n        VisitBaseReferenceExpression(value as IBaseReferenceExpression);\n        VisitBinaryExpression(value as IBinaryExpression);\n        VisitBlockExpression(value as IBlockExpression);\n        VisitCanCastExpression(value as ICanCastExpression);\n        VisitCastExpression(value as ICastExpression);\n        VisitConditionExpression(value as IConditionExpression);\n        VisitDelegateCreateExpression(value as IDelegateCreateExpression);\n        VisitDelegateInvokeExpression(value as IDelegateInvokeExpression);\n        VisitEventReferenceExpression(value as IEventReferenceExpression);\n        VisitExpressionCollection(value as IExpressionCollection);\n            . . . .\n    }\n}\n \n<\/pre>\n
    If value is not of the correct type, the as operator will return null.   Each method will verify that null was not passed in adding marginal extra complexity to each method, but dramatically lowering the complexity of the VisitExpression<\/b>.    We use  a similar method for VisitStatement<\/b> and VisitType<\/b>.<\/p>\n
    MethodTarget<\/b> is a property of type CodeStackItem<\/b> that standardizes accessing the top item  in the CodeStack.<\/b><\/p>\n
    public CodeStackItem  MethodTarget\n{\n    get\n    {\n        CodeStackItem returnValue = null;\n        if (codeStack.Count > 0)\n        {\n            returnValue = codeStack.Peek();\n        }\n        else\n            throw new System.Exception(\"No code items in the stack\");\n        return returnValue;\n    }\n}\n \n<\/pre>\n
    The BuildCodeString<\/b> method from the CodeStackItem<\/b> class handles the interpretation of a CodeStackItem<\/b> and produces a string suitable for adding to our code:<\/p>\n
    public string BuildCodeString(string value)\n{\n    string returnValue = \"\";\n    if (isCollection)\n    {\n        returnValue = ActiveBlock + \".\" + ActiveCollection + \".Add(\"\n            + value + \");\";\n    }\n    else\n    {\n        returnValue = activeBlock + \".\" + ActiveCollection\n            + \" = \" + value + \";\";\n    }\n    return returnValue;\n}\n \n<\/pre>\n
    Pulling it All Together<\/h2>\n
    The visitor pattern makes our code easier to structure.   It also allows us to have a nice structure to produce a usable language even as we are adding support for more features.   We can provide visitor methods for features that we have not yet implemented that will simply announce that a given feature is not yet supported and then have a convenient place to add the missing functionality as we are ready.    When you get started writing a language, many of the visitor methods may be as simple as this:<\/p>\n
    public override void VisitAddressDereferenceExpression\n      (IAddressDereferenceExpression value)\n{\n    if (value != null)\n    {\n        WriteUnsupported(value);\n    }\n}\nThe WriteUnsupported method could be similar to this.\n \nprivate void WriteUnsupported(IExpression value)\n{\n    if (value != null)\n    {\n        formatter.WriteLiteral(\"\/\/ Unsupported expression \"\n            + value.GetType().Name + \":\");\n        formatter.WriteLine();\n        formatter.WriteLiteral(\"\/\/\" + value);\n        formatter.WriteLine();\n    }\n}\n<\/pre>\n
    Now you are free to implement the language features that are important to you.<\/p>\n
    One important language feature to implement is a property declaration.  Our property declaration visitor may look similar to this:<\/p>\n<\/p>\n
    public override void VisitPropertyDeclaration(IPropertyDeclaration value)  \n{\n    formatter.WriteKeyword(\"public void\");\n    WriteWhitespace();\n    formatter.WriteDeclaration(\"CreateProperty\" + value.Name+\"()\");\n    formatter.WriteLine();\n    using (new IndentedCodeBlock(formatter))\n    {\n       formatter.Write(\"System.CodeDom.CodeMemberProperty \"\n            + value.Name\n            + \" = new System.CodeDom.CodeMemberProperty();\");\n        codeStack.Push(new CodeStackItem(value.Name, \"Type\", false));\n        VisitType(value.PropertyType);\n        codeStack.Pop();\n        formatter.WriteLine();\n        formatter.Write(value.Name + \".Name = \\\"\" + value.Name + \"\\\";\");\n        formatter.WriteLine();\n        if (value.GetMethod != null)\n        {\n            codeStack.Push(new CodeStackItem(value.Name,\n                \"GetStatements\", true));\n            VisitMethodReference(value.GetMethod, false);\n            codeStack.Pop();\n        }\n        if (value.SetMethod != null)\n        {\n            codeStack.Push(new CodeStackItem(value.Name,\n                \"SetStatements\", true));\n            VisitMethodReference(value.SetMethod, false);\n            codeStack.Pop();\n        }\n        formatter.WriteLine();\n   }\n}\n \n<\/pre>\n
    There are a couple of key things to note here, the use of a new class IndentedCodeBlock<\/b>, the declaration of CodeDomTypes<\/b>, and the call to VisitType <\/b>to create the code necessary to initialize the data type for the property.<\/p>\n
    VisitType<\/b> is a function similar to the VisitExpression<\/b> that we saw earlier.  This method will be able to process type specification in all its forms.<\/p>\n
    When dealing with one of the Declaration methods, we will be outputting a method that will produce the CodeDom<\/b> code to create the corresponding object.   In this case, we output the method CreateProperty<\/b><PropertyName>.   We call VisitType<\/b> passing in the context of the CodeMemberProperty<\/b> and the Type property specifying that this is not a collection.   We then call VisitMethodReference<\/b> passing in the context of the CodeMemberProperty<\/b> and the GetStatements<\/b> and SetStatements<\/b> specifying that these are collections.   This will handle generating the details for the property implementation. <\/p>\n
    The IndentedCodeBlock<\/b> is a class that I borrowed from the implementation of the PowerShell language.  It is a very simple class consisting of only a constructor and the Dispose method, but simplifies formatting our code.   We use this class whenever our outputted code adds a level of indention.<\/p>\n
    private class IndentedCodeBlock : IDisposable\n{\n    private readonly IFormatter formatter;\n \n    public IndentedCodeBlock(IFormatter formatter)\n    {\n        this.formatter = formatter;\n        formatter.Write(\"{\");\n        formatter.WriteLine();\n        formatter.WriteIndent();\n    }\n \n \n    public void Dispose()\n    {\n        formatter.WriteOutdent();\n        formatter.Write(\"}\");\n        formatter.WriteLine();\n    }\n}\n<\/pre>\n
    By declaring the IndentedCodeBlock<\/b> in a using statement, we don’t have to worry about explicitly calling the dispose.  The IndentedCodeBlock<\/b>  will go out of scope as soon as the using statement is out of context and the Dispose method will be called automatically.   <\/p>\n
    There are a couple of lines worth noting here.  We call some new functions from the formatter to control the layout of the code.   There are various methods that we can call to facilitate color coding and make our outputted code more visually engaging.   The actual results will depend on the implementation of the IFormatter<\/b> object.   Providing your own IFormatter<\/b> is yet another way to customize Reflector.   Here are the important methods in the IFormatter<\/b> interface:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
    \n
    Write<\/p>\n<\/td>\n
    		\n
    Called to write out a string with no special formatting.<\/p>\n<\/td>\n<\/tr>\n
    \n
    WriteComment<\/p>\n<\/td>\n
    		\n
    Called to write out a string formatted as a comment.   This will generally be a light gray.   These are not the comments from the original code but comments that the language added while translating.<\/p>\n<\/td>\n<\/tr>\n
    \n
    WriteDeclaration<\/p>\n<\/td>\n
    		\n
    Called to write out the keywords in a declaration.<\/p>\n<\/td>\n<\/tr>\n
    \n
    WriteIndent<\/p>\n<\/td>\n
    		\n
    Called to write out a new level of indentation in your code.<\/p>\n<\/td>\n<\/tr>\n
    \n
    WriteKeyword<\/p>\n<\/td>\n
    		\n
    Called to write out a Keyword.<\/p>\n<\/td>\n<\/tr>\n
    \n
    WriteLine<\/p>\n<\/td>\n
    		\n
    Called to write out a new line.  This signals to the formatter that this is the end of one line and that futures calls should display text on a new line.<\/p>\n<\/td>\n<\/tr>\n
    \n
    WriteLiteral<\/p>\n<\/td>\n
    		\n
    Called when you need to write out a literal value such as a string, a number, a Boolean value, etc.<\/p>\n<\/td>\n<\/tr>\n
    \n
    WriteOutdent<\/p>\n<\/td>\n
    		\n
    Called to end the most recent level of indentation in your code.<\/p>\n<\/td>\n<\/tr>\n
    \n
    WriteProperty<\/p>\n<\/td>\n
    		\n
    Called to write out a property reference<\/p>\n<\/td>\n<\/tr>\n
    \n
    WriteReference<\/p>\n<\/td>\n
    		\n
    Called to write out a function reference<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    Taking this Further<\/h2>\n
    Here we showed how to create a language that will produce the CodeDom code to represent the code being disassembled.  Other possibilities may include using this framework to create a language to provide static code analysis.   You have the pieces needed to build a rules engine similar to FxCop.   You could complain about methods with too many parameters.   Warn about methods with too many conditional branches.   Raise red flags when a switch statement does not include a “default”.    <\/p>\n
    You could also use this approach to build a language that would write stubs for your unit testing.   As your language visits language structures such as an IConditionStatement<\/b>, ISwitchCase<\/b>, or IForEachStatemen<\/b>t that would indicate the need for a new unit test, your language could output a comment describing the new test that would be needed.<\/p>\n
    In the approach outlined here, we mainly used the Write and WriteLine methods.  The other methods provided by IFormatter<\/b> can be used to provide syntax highlighting for your language output.    Using these methods will not add any functionality to our language or change its implementation, but it will improve the readability and look of your generated code.<\/p>\n
    Also WriteComment <\/b>can be used to add critiques of the code being parsed.<\/p>\n
    Screen Shots <\/h2>\n
    Here is how our new language looks in Reflector.  We load this add-in like we would an add-in.   Once added, our “language” shows up in the language drop down.<\/p>\n
    \"829-image002.jpg\"<\/p>\n
    \"829-image004.jpg\"<\/p>\n
    Conclusion<\/h2>\n
    Creating your own Reflector language should not be seen as daunting task.  The goal is not to create a new industrial grade language and compete with C# and VB.   The goal is to provide a new way to translate IL into something useful.    Here we discussed examples of what you may do with your own language.   As you get comfortable with these techniques, you will find more uses and new ways to have fun with a remarkable tool: .NET Reflector.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
    .NET Reflector was the first .NET tool to allow assemblies to be disassembled back into the high level language that produced them. Moreover, it has a plug-in architecture that allows you to disassemble to any language for which you have a plug-in, or are prepared to write one. Nick Harrison takes it one further step, and creates a plug-in that produces the CodeDom code needed to create the contents of the assembly. Nick explains, gently.…<\/p>\n","protected":false},"author":221853,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143538],"tags":[4143,4229,5058,4885],"coauthors":[],"class_list":["post-695","post","type-post","status-publish","format-standard","hentry","category-dotnet-development","tag-net","tag-net-framework","tag-example-sample-code-net-reflector-plug-in-plugin-codedom","tag-reflector"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/695","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/221853"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=695"}],"version-history":[{"count":5,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/695\/revisions"}],"predecessor-version":[{"id":91132,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/695\/revisions\/91132"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=695"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=695"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=695"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=695"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}