Introduction
I find writing CodeDom code kind of like writing assembly. It's like cutting the grass with a pair of scissors or unloading a truck load of sand with a spoon. Its long winded, it can be done, but it is tedious. However, there are advantages in using CodeDom.
Now, it would be nice if you could whip up a class in VB or C# and generate the CodeDom code. CodeDom Assistant does this with the help of SharpDevelop's NRefactory Library in conjunction with writing our own CodeDomProvider to generate C# CodeDom code. The code you get will construct a CodeDom compileunit, and it will definitely be ugly. But what can you expect from a machine?
Background
Code Generation can be done using various techniques. In essence, code generation saves time, and enables you to create code using established patterns.
In the world of .NET, one technique is to use CodeDom. It allows you create a document object model of the code. This can by either compiled into an assembly or used to generate code. Every .NET language should have an implementation of a CodeDomProvider to generate code. The problem is that CodeDom does not implement every syntax construct of every language. In essence, it is a subset, but there are enough operations to emulate most language constructs.
Parsing C# or VB is going to be the toughest part, but luckily one of SharpDevelop's little libraries is NRefactory. This has the machinerary required to parse C# or VB code. The key component for us is the CodeDomVisitor class. Sadly, it is only a partial implementation. They implement enough to run SharpDevelop's form generation. I am not saying I have completed the implementation, rather, I have filled most of the holes in the CodeDomVisitor.
The second part is implementing a CodeDomCodeProvider. This will take a CodeDom compile unit and generate C# code that will create a CodeDom compile unit.
Alternatives To Unsupported CodeDom Constructs
When converting C# to CodeDom, certain constructs will not be able to be mapped directly into a CodeDom element. Rather we have to emulate the intent of the code. I am sure better transformations can be made, but these are sufficient for my needs. For example: int a = b++; is definitely not the same as the transformed CodeDom int a = (b = (b + 1));.
Not all constructs are going to be able to be transformed perfectly into CodeDom; they are merely sufficient for my needs. When I originally wrote the code in C# I did so with these limitations in mind. For example:
The foreach statement is handled using the for iterator and GetEnumerator(). Behold:
foreach (string s in mylist)
{
}
Can be constructed in CodeDom as:
for (System.Collections.IEnumerator _it1 = mylist.GetEnumerator();
_it1.MoveNext(); )
{
string s = ((string)_it1.Current);
}
The do statement is handled using the for iterator. For example:
do
{
}
while (expr);
Can be constructed in CodeDom as:
for (bool _do1 = true; _do; _do = expr)
{
}
The while statement is handled again with the for iterator. For example:
while (expr)
{
}
Can be constructed in CodeDom as
for (; expr; )
{
}
The continue and break statements are handled using the goto statements. For example:
for (int i = 0; i < 5; i++)
{
if (i < 2)
continue;
if (i == 3)
break;
}
Can be constructed in CodeDom as:
for (int i = 0; i < 5; i = i + 1)
{
if (i < 2)
goto continue1;
if (i == 3)
goto break1;
continue1:
}
break1:
Unary operators: i++; ++i; i--; --i; !; can be constructed using the binary operators: i = i + 1; etc..
The switch statement becomes a nested if statement.
switch(expr)
{
case label1:
break;
case label2:
break;
default:
}
Can be constructed in CodeDom as:
object _switch1 = expr;
if (_switch1.Equals(label1))
{
}
else
{
if (_switch1.Equals(label2))
{
}
else
{
}
}
The using(new a()) {} statement can be emulated with:
object _dispose1 = null;
try
{
_dispose1 = new a();
}
finally
{
if (((_dispose1 != null)
&& (typeof(System.IDisposable).IsInstanceOfType(_dispose1) == true)))
{
(System.IDisposable)(_dispose1)).Dispose();
}
}
Constructing CodeDom Using NRefactory
The generate function uses NRefactory parser. NRefactory supports C# and VB. I tend to use C#, and have not tested the VB. The OutputClass is essentially the output combobox selection. There are native C# and VB NRefactory output transformations, which are much more complete than CodeDom. For other languages we use the CodeDomVisitor which maps the NRefactory parser output to CodeDom. The CodeDom CodeCompileUnit is then passed to a CodeDomProvider which generates output.
void Generate(ICSharpCode.NRefactory.SupportedLanguage language,
TextReader inputstream, OutputClass output)
{
ICSharpCode.NRefactory.IParser parser = ParserFactory.CreateParser(
language, inputstream);
parser.Parse();
if (parser.Errors.Count > 0)
{
ICSharpCode.Core.ExceptionDialog dlg =
new ICSharpCode.Core.ExceptionDialog(
null, "Error Parsing Input Code");
dlg.ShowDialog();
return;
}
if (output.CodeDomProvider != null)
{
CodeDomVisitor visit = new CodeDomVisitor();
visit.VisitCompilationUnit(parser.CompilationUnit, null);
for (int i = visit.codeCompileUnit.Namespaces.Count - 1; i >= 0; i--)
{
if (visit.codeCompileUnit.Namespaces[i].Types.Count == 0)
{
visit.codeCompileUnit.Namespaces.RemoveAt(i);
}
}
CodeGeneratorOptions codegenopt = new CodeGeneratorOptions();
codegenopt.BlankLinesBetweenMembers = true;
System.IO.StringWriter sw = new System.IO.StringWriter();
output.CodeDomProvider.GenerateCodeFromCompileUnit(
visit.codeCompileUnit, sw, codegenopt);
this.scintillaOutput.Text = sw.ToString();
sw.Close();
}
else
{
AbstractAstTransformer transformer = output.CreateTransformer();
List<ISpecial> specials =
parser.Lexer.SpecialTracker.CurrentSpecials;
if (language == SupportedLanguage.CSharp &&
transformer is ToVBNetConvertVisitor)
{
PreprocessingDirective.CSharpToVB(specials);
}
else if (language == SupportedLanguage.VBNet &&
transformer is ToCSharpConvertVisitor)
{
PreprocessingDirective.VBToCSharp(specials);
}
parser.CompilationUnit.AcceptVisitor(transformer, null);
IOutputAstVisitor prettyprinter = output.CreatePrettyPrinter();
using (SpecialNodesInserter.Install(specials, prettyprinter))
{
prettyprinter.VisitCompilationUnit(parser.CompilationUnit, null);
}
this.scintillaOutput.Text = prettyprinter.Text;
}
}
The NRefactory CodeDomVisitor class needed to be updated to implement more C# constructs. I am sure I have have missed a few.
Generating C# Code CodeDom
All CodeDom compile units can be passed to any CodeDomProvider to generate code. So, we write a new CodeDom provider that will generate CodeDom code for us. The implementation is quite simple. The main job of the CodeDomCodeProvider is to create an ICodeGenerator.
public class CodeDomCodeProvider : System.CodeDom.Compiler.CodeDomProvider
{
public CodeDomCodeProvider()
: base()
{
}
public override string FileExtension
{
get
{
return "cs";
}
}
public override System.CodeDom.Compiler.ICodeGenerator CreateGenerator()
{
return new CodeGenerator();
}
public override System.CodeDom.Compiler.ICodeCompiler CreateCompiler()
{
return null;
}
}
The CodeGenerator then traverses the CodeDom elements and outputs code that will reconstruct the tree when compiled.
Using Other CodeDomProviders
On initialisation CodeDom Assistant scans the GAC to find assemblies that have an implementation of CodeDomProvider. Since the output of the parsed C#/VB is CodeDom the output can be generated by any CodeDomProvider. So it could act as an effective language Convertor.
Points of Interest
You can only convert code that compiles. It is not very good at telling why it did not compile. The other issue I have found is that it may parse the file, but the CodeDom it produces is incomplete. This may cause the CodeDomProvider CodeGenerator to barf. Usually with some obscure error, like e value is null.
The output of CodeDomCodeProvider is ugly, but assists you in the construction of creating code generators with CodeDom. A lot of our code generation is done through the meta-data of a database. So this code would only be a starting point.
