Overview

In CodeSmith Generator 6.0, one of the features we are working on
is to have templates
run in their own process. There are a number of advantages to running the
templates in their own process, the biggest being reliability. Here are some
advantages.

• Reliability
• Unloading
• Framework Control
• Debugging

Reliability

Running the template in its own process improves the reliability of the
hosting process that is running the template. An issue or crash in the
template will not cause the host application to fail. By isolating the
template to its own process, we can ensure that the parent process isn’t affected by the template.

Unloading

One of the long standing issues with CodeSmith Generator has been
that when you
reference a 3rd party DLL in a template, CodeSmith Generator would
load that DLL into its
AppDomain causing the DLL to be locked. If you need to recompile
that DLL,
you’d have to unload CodeSmith Generator to because it was
locked. We solve this
issue in a couple ways in CodeSmith Generator 6. By having the
templates run in a
separate process, we can easily unload or kill the process freeing all
resources. We also solve the issue by doing shadow coping of DLLs.

Framework Control

With the release of .NET 4.0, there are now multiple .NET
frameworks that the
template can be compiled to. Issues quickly arose when we tried to
support compiling to all the different versions of the framework. The
biggest issue being that if the parent process was .NET 2.0, we couldn’t run a
.NET 4.0 dependent template. Now, in CodeSmith Generator 6, all
templates get
compiled to .NET 4.0 as it supports loading assemblies of lower framework
versions. Being the template now runs in its own process, there is no
longer an issue as to what .NET framework version the parent process is.

Debugging

Now that a template is run in a separate process, debugging becomes
easier.
You can use Visual Studio’s ‘attach to process’ feature to attach to
the template
runner. Attaching to just the template runner instead of the parent
process isolates the debugger to just the code you actually want to
debug.
Also, any issue the debugger may cause, like stopping debugging by killing the
process, won’t affect the parent application. In future versions, we will
investigate automatically attaching debugger which wouldn’t have been possible
without the template runner process.

Technical Detail

• For two-way cross-process communication with the host and the
  template runner, .NET remoting based on named pipes is used.
• If the template process fails, it is automatically restarted when
  a template is run again.
• Some user interface dialogs and controls are also created in the
  template runner process.