title: Why use ttinclude instead of compiled assemblies?
body: <p>I have been writing an assembly to simplify much of my POCO type generation. I have one core assembly which multiple tt files include and use to generate the code. </p>
  
  <p>The reason  I have done this is because no matter which extension I try (Devart T4, Tangible-T4 or Visual T4) none are as good as the intellisense and support offered by Visual Studio's C# editor, so writing the code generation in pure C# improves the experience a lot.</p>
  
  <p>The biggest issue I am facing is the fact that the entity framework helper classes (e.g. <code>Accessibility</code>, <code>CodeGenerationTools</code>, <code>MetadataTools</code> etc) are defined inside a ttinclude file and not an assembly; currently I am having to rewrite a lot of the functionality these classes provide so that it is usable from an assembly.</p>
  
  <p>My question is, why did the entity framework team decide to use a ttinclude file rather than some compiled assemblies? Using the assemblies approach seems like it would have been much more usable in more circumstances and still would not have affected T4 code generation (as instead of using <code>&lt;#@ include #&gt;</code> it would be <code>&lt;#@ assembly #&gt;</code>).</p>
  
  <p>I am wondering what the best approach to resolve this would be, I have contemplated running <code>EF.Utility.CS.ttinclude</code> through <code>TextTransform.exe</code> and then taking the generated C# and compiling this, would this be advisable?</p>
  
  <p>Thanks, Luke</p>
  
  <p><strong>Update</strong></p>
  
  <p>Currently what I did was add <code>EF.Utility.CS.ttinclude</code> to my project, set the custom tool on the file to <code>TextTemplatingFilePreprocessor</code>. This will generate the code containing the classes. I then copied this cs file, removed the class responsible for writing output (it has the method <code>TransformText()</code>) and compiled into an assembly. I can now use the entity framework utility classes in my assembly.</p>