Loading the EmptyProject

Let’s look at these individual pieces one at a time, starting with loading the empty project, as shown in Listing 6-2.

Listing 6-2. Loading the Empty Project

private static Project LoadEmptyProject( MSBuildWorkspace work)
{
     var solution = work.OpenSolutionAsync(PATH_TO_SOLUTION).Result;
     var project = solution.Projects.FirstOrDefault
                (p => p.Name == "EmptyProject");
     if (project == null)
         throw new Exception("Could not find the empty project");
     return project;
}

This method will be standard across most code generation approaches. The only thing likely to change is the name of the project you want to add your code to—not everyone will want to call it EmptyProject—and the path to the solution where this project is located. You may want to even pull this value from a configuration file.

Safely Add a New Document

SafeAddDocumenthas a couple of subtle nuances that you need to be aware of. We call it SafeAddDocument because it can safely handle the scenario in which the document being added is already in the project. Without this safety net in place, the same document will be added to the project, which will cause errors when you try to compile the project. Listing 6-3 shows the full implementation of SafeAddDocument.

Listing 6-3. Safely Adding a New Document to a Project

private static Document SafeAddDocument( Project project,
    SyntaxTree tree, string documentName)
{
    var targetDocument = project.Documents
        .FirstOrDefault(d => d.Name.StartsWith(documentName));
    if (targetDocument != null)
    {
        project = project.RemoveDocument(targetDocument.Id);
    }
    var doc = project.AddDocument(documentName, tree.GetRoot()
        .NormalizeWhitespace());
    return doc;
}

You can start by searching for a document matching the name that you are looking for. If you find one, explicitly remove it. Then you can safely add the document. Once the document has been added to the project, you must use the workspace to apply the changes to the project. Remember that Roslyn objects are immutable.

Specifying Compilation Options

With Roslyn, you can specify every compiler option you want. Listing 6-4 shows how to add options to specify a release build for a DLL running on any CPU.

Listing 6-4. Adding the Compilation Options

private static Project AddCompilationOptions(Project project)
{
    var options = new CSharpCompilationOptions(
             OutputKind.DynamicallyLinkedLibrary)
               .WithOptimizationLevel(OptimizationLevel.Release)
               .WithPlatform(Platform.AnyCpu)
               .WithModuleName("GeneratedCode");
    project = project.WithCompilationOptions(options);
    return project;
}

This will cover most scenarios you are likely to encounter for generating business logic, but the Roslyn libraries are complete with support for every potential scenario. CSharpCompilationOptions has methods to support such obscure scenarios as:

• Allowing unsafe code

• Concurrent builds

• Options for signing the assembly

• Disabling overflow checks

Once the compiler options are specified, you are ready to get the compilation results. This is potentially a long running method so it is set up to be run asynchronously, but you don’t really have anything else to run while you are waiting on the method to finish. You can make it run synchronously by immediately accessing the Result property of the resulting task:

var compiler = project.GetCompilationAsync().Result;

Reviewing the Diagnostic Messages

The result is a compilation that you can use to review any diagnostic messages as well as output the resulting assembly if there were no errors. Listing 6-5 shows a generalized process for reviewing error messages.

Listing 6-5. Reviewing the Diagnostic Messages from the Compiler

private static bool ReviewDiagnosticMessages(Compilation compiler)                
{                
    var results = compiler.GetDiagnostics();            
    var returnValue = true;            
    foreach (var item in results.Where(i => i.Severity == DiagnosticSeverity.Error))            
    {            
        returnValue = false;            
        Console.WriteLine(item.GetMessage() + item.Location);            
    }            
    return returnValue;            
}                

If there are no errors, you can successfully emit an assembly. If there are errors, it shows the diagnostic message as well as the details for the code that caused the problems.

Using the code generator from Chapter 5, you will get some error messages. This is not surprising. Code rarely compiles the first time (see Listing 6-6).

Listing 6-6. Original Compiler Error Messages

The type or namespace name 'ILoanCodes' could not be found (are you missing a using directive or an assembly reference?)
        SourceFile(UnderwritingRules[161..171))            
The type or namespace name 'ILoanCodes' could not be found (are you missing a using directive or an assembly reference?)
        SourceFile(UnderwritingRules[783..793))            
The type or namespace name 'ILoanCodes' could not be found (are you missing a using directive or an assembly reference?)
        SourceFile(UnderwritingRules[1337..1347))            
'int[]' does not contain a definition for 'Contains' and no extension method 'Contains' accepting a first argument of type 'int[]' could be found (are you missing a using directive or an assembly reference?)
        SourceFile(UnderwritingRules[268..276))            
'int[]' does not contain a definition for 'Contains' and no extension method 'Contains' accepting a first argument of type 'int[]' could be found (are you missing a using directive or an assembly reference?)
        SourceFile(UnderwritingRules[376..384))            

The full error messages have been truncated for brevity. It is common to see the same error message repeated dozens or hundreds of times. Don’t let this overwhelm you. In this case, there are only two problems. You need to add a couple of using statements to the beginning of the class declaration.

You can resolve these compiler errors by changing the GenerateRules method in UnderwritingRuleGenerator to reflect the changes shown in Listing 6-7.

Listing 6-7. Revised GenerateRules

public SyntaxTree GenerateRules()
  {
      var code = @"using CommonProject;            
                   using System.Linq;            
                   public class UnderwritingRules{}";            
      var method = @"public bool Rule(ILoanCodes data)
          {
              var target = new []{0};
          }";
      var syntaxTree = CSharpSyntaxTree.ParseText(code).GetRoot();
      var classDeclaration =
           syntaxTree.DescendantNodes().OfType<ClassDeclarationSyntax>()
          .FirstOrDefault();
      var originalClass = classDeclaration;
      foreach (var rule in GetUnderwritingRules())
      {
          var methodSyntaxTree =
              CSharpSyntaxTree.ParseText(method).GetRoot();
          var underwritingRule = methodSyntaxTree.DescendantNodes()
              .OfType<MethodDeclarationSyntax>().FirstOrDefault();
          underwritingRule = RenameRule(rule.RuleName, underwritingRule);
          underwritingRule = underwritingRule
              .WithLeadingTrivia(new SyntaxTrivia[] {
                 SyntaxFactory.Comment("// " + rule.ShortDescription) });
          underwritingRule =
                 underwritingRule.WithBody(ProcessLoanCodes(rule,
                    underwritingRule.Body));
          var currentBlock = underwritingRule.Body;
          currentBlock = currentBlock.AddStatements(new StatementSyntax[]
                  { ReturnTrue() });
          underwritingRule = underwritingRule.WithBody(currentBlock);
          classDeclaration =
               classDeclaration.AddMembers(underwritingRule);
      }
      var newNode = syntaxTree.ReplaceNode(originalClass,
          classDeclaration);
      return newNode.SyntaxTree;
  }

Emitting an Assembly

With these code changes in place, you can run the compiler and this time you won’t see any error messages. With no error messages reported, you can emit the assembly from the compiler (see Listing 6-8).

Listing 6-8. Emitting an Assembly

if (ReviewDiagnosticMessages(compiler))
   compiler.Emit("UnderwritingRules.dll");

Emitting an assembly to a file is not the only option, but it will be the one that we will follow most often. You could also emit it to a stream, as shown in Listing 6-9.

Listing 6-9. Emitting to a Memory Stream

private static Assembly EmitMemoryStream(Compilation compiler)
{
    using (var ms = new MemoryStream())
    {
        compiler.Emit(ms);
        ms.Seek(0, SeekOrigin.Begin);
        return Assembly.Load(ms.ToArray());
    }
}

This can be helpful if you plan to generate the assembly and immediately run it without preserving it to disk. This may be appropriate in some situations where the generated code is extremely volatile or when the overhead of tracking when to regenerate the assembly is cumbersome.