T4 Parameter Passing: Problem Isolation

I have been tracking down why I could not get my custom host for T4 to work.  I now know the specific condition that causes the failure and that knowledge leads to a short-term work around.  This is the question that I posted on the MSDN forums on Visual Studio extensibility:

--------------------------------------------------------------------------------------

As I noted in an earlier post :Source Code for a Working Implementation of ITextTemplatingEngineHost, I am trying to build a custom host for T4.  The answer to my query about available source code for a working custom host lead to the code in the MSDN documentation.  That code worked.  Using that code as a baseline, I was able to isolate the cause of my problem.

 
My situation is that I want to expose the custom host in the template file.  Following the example in MSDN, I wrote the following code for the ProvideTemplatingAppDomain:

   1: public AppDomain ProvideTemplatingAppDomain(string content)

   2: {

   3:     // This host will provide a new application domain each time the 

   4:     // engine processes a text template.

   5:     // -------------------------------------------------------------

   6:     return AppDomain.CreateDomain("Generation App Domain");

   7: }

This works fine if I supply the current AppDomain and include the "hostspecific=true" parameter on the template directive.  It also works just fine if I supply a new Appdomain but do not include the "hostspecific=true" parameter.  It DOES NOT WORK if I supply a new AppDomain and also include the "hostspecific=true" parameter.  The issue is that the Engine class is not serializable.  Apparently, it must be serializable to move across the AppDomain boundary.

I have to specify the "hostspecific=true" parameter to make the functionality that I am trying to provide work.  In the short term, I can work around this by re-using the AppDomain, but I wonder how that will affect Visual Studio performance.  Am I right in thinking that the custom tool will run in a separate process space?  If it does, the AppDomains will only live for the duration of the code generation process; there would be no accumulation in memory.  But the author of the MSDN sample took some effort to mention that creating a searpate AppDomain was a good idea.  Is there a way to get a new AppDomain and "host specific" at the same time?

Jon Stonecash

--------------------------------------------------------------------------------------

I am going to proceed on the basis of re-using the current AppDomain, keeping an eye out for any performance hits.  Maybe someone will take notice of my question and provide a longer-term approach.