Introduction
If you've ever tried to work at any length with CodeDom, you know that it's verbose and sometimes confusing to work with. For me, the hardest part of working with CodeDom is writing expressions. I find myself trying to limit what happens in my expressions so that I can make the CodeDom easier to write.
After seeing Pascal Ganaye's article (The expression evaluator revisited (Eval function in 100% managed .NET)[^]), I figured that I could use that code and create a CodeDom expression parser. This article presents my results.
Putting It To Use
I've put this parser to work and made an embeddable rules library in .NET 3.0. It stores CodeDom statements in the application configuration. Check it out here: DmRules - A helper library for running rules in .NET 3.0[^].
Features
The parser uses a C#-like syntax and can read all of the following:
- Local variables
- Primitives:
string
, double
, int
, long
, etc. - Operators: +, -, *, /, %, >, >=, <, <=, ==, !=, !, &, &&, |, ||, unary -
- Fields
- Properties
- Methods
- Indexes
- Casting with (Type)
typeof()
- Enums
Using the Code
Let's say I have to write a statement in CodeDom like this:
xr.HasAttributes && xr.MoveToAttribute("xmi.value")
It's a simple enough thing to want to put in an if
condition. Writing the CodeDom would look something like this:
CodeExpression ce = new CodeBinaryOperatorExpression(
new CodePropertyReferenceExpression(
new CodeVariableReferenceExpression("xr"), "HasAttributes"),
CodeBinaryOperatorType.BooleanAnd, new CodeMethodInvokeExpression(
new CodeMethodReferenceExpression(
new CodeVariableReferenceExpression("xr"), "MoveToAttribute"),
new CodeExpression[] { new CodePrimitiveExpression("xmi.value") }));
With this library, you can write this instead:
Parser p = new Parser();
CodeExpression ce = p.ParseExpression(
"xr.HasAttributes && xr.MoveToAttribute(\"xmi.value\")");
Now, I also have other requirements. For instance, I need the parser to know what a field is and to recognize when I do a cast. So, I might want to have the following expression:
(double)Convert.ChangeType(xr.Value, typeof(double))
Here's how it would look in CodeDom:
CodeExpression ce1 = new CodeCastExpression(
new CodeTypeReference(typeof(double)),
new CodeMethodInvokeExpression(new CodeMethodReferenceExpression(
new CodeTypeReferenceExpression(typeof(Convert)), "ChangeType"),
new CodeExpression[] { new CodePropertyReferenceExpression(
new CodeVariableReferenceExpression("xr"), "Value"),
new CodeTypeOfExpression(new CodeTypeReference(typeof(double))) }));
And here's how to write it with the parser:
Parser p = new Parser();
CodeExpression ce = p.ParseExpression(
"(double)Convert.ChangeType(xr.Value, typeof(double))");
The reason that the ParseExpression
method is done as an instance method instead of a static
method is because I want the Parser
object to collect some context. There are two properties exposed on Parser
: Fields
and RecognizedTypes
. By default, anything after a this
reference is considered a property. If the name matches one of the entries in the Fields
collection, then it is treated as a field instead. Also, the parser will check the RecognizedTypes
to see if an identifier should be treated as a variable or as a type. It also helps when using a cast or a typeof
.
In the most recent update of this code, I have included the ability to use enum
s. Each of the enumerations is treated as a field reference of a type, so the parser needs to handle them differently. Just add an enum
type to the Enums
property of the parser.
Parser p = new Parser();
p.Enums.Add("MyEnum", new CodeTypeReference("MyEnum"));
CodeExpression ce = p.ParseExpression("this.Foo == MyEnum.Bar");
Some Other Examples
All of the following are correctly parsed:
-5 // This one actually parses as (0 - 5)
!stream.EndOfFile // Parses as (stream.EndOfFile == false)
!stream.EndOfFile && this.Count > 5
foo[0]
foo.bar()[0] > 2
(int)foo
s == ""
What's Inside
Here's a listing of the files inside:
CodeDomExpParser
- Enums.cs
- Parser.cs
- Token.cs
- Tokenizer.cs
CodeDomExpParser.Test
- This is a test harness for the parser library.
- DogFood.cs - This contains some of the more complicated CodeDom statements I had to do in my XMI CodeDom library and also some examples gathered from the comments. Hence the expression, "eating my own dog food."
- TestParser.cs - Throws a few tests at the parser. Look at this file for examples of what can be parsed.
- TestTokenizer.cs - Runs some tests against the tokenizer.
Summary
I used a lot of the ideas that Pascal was using in his article for the tokenizer and parser. With the basic stuff in place, I pretty much went my own way. It was a cool project to work on. Hopefully, some of you will find it useful.
History
- 0.1 : 2006-06-08 : Initial version
- Handles most of the expressions that I need it to do
- More thorough testing would definitely be nice
- One of the to-do items is to allow the input of an existing CodeDom graph for finding types, fields, and the like
- 0.2 : 2006-06-21
- Added modulus operator and created a .NET 2.0 version
- 0.3 : 2006-07-19
- Fixed a problem where empty strings were not being parsed
- Added the capability to parse enums
- 0.4 : 2009-04-20
- Fixed two bugs mentioned in the comments
- Converted to Visual Studio 2008 solution
- Uses Visual Studio Test Tools instead of NUnit
- DogFood test cases now use a
CompareExpression
method that automates testing