I wrote the assembly to simplify most of my POCO generation. I have one main assembly, which includes several tt files and is used to generate code.
The reason I did this is because no matter what extension I try (Devart T4, Tangible-T4 or Visual T4), nothing is as good as the intellisense and support offered by the Visual Studio C # editor, therefore, writing code generation in pure C # greatly improves the experience.
The biggest problem I came across is that helper classes of the entity frame (like Accessibility , CodeGenerationTools , MetadataTools , etc.) are defined inside the ttinclude file, not the assembly; I currently have to rewrite a lot of the functionality provided by these classes so that they can be used from the assembly.
My question is: why did the entity framework team decide to use the ttinclude file, and not some compiled assemblies? Using the assembly approach seems like it would be much more convenient in any circumstances and still would not affect the generation of T4 code (instead of using <#@ include #> it would be <#@ assembly #> ).
I am wondering what the best approach to solving this would be, I intended to run EF.Utility.CS.ttinclude via TextTransform.exe , and then take the generated C # and compile it, would it be appropriate?
Thanks Luke
Update
Currently, what I did has added EF.Utility.CS.ttinclude to my project, installed a custom tool in the TextTemplatingFilePreprocessor file. This will generate code containing the classes. Then I copied this cs file, deleted the class responsible for writing the output (it has the TransformText() method) and compiled into the assembly. Now I can use the entity utility classes in my assembly.
source share