5

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.

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.

The biggest issue I am facing is the fact that the entity framework helper classes (e.g. Accessibility, CodeGenerationTools, MetadataTools 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.

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 <#@ include #> it would be <#@ assembly #>).

I am wondering what the best approach to resolve this would be, I have contemplated running EF.Utility.CS.ttinclude through TextTransform.exe and then taking the generated C# and compiling this, would this be advisable?

Thanks, Luke

Update

Currently what I did was add EF.Utility.CS.ttinclude to my project, set the custom tool on the file to TextTemplatingFilePreprocessor. 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 TransformText()) and compiled into an assembly. I can now use the entity framework utility classes in my assembly.

Dariusz Woźniak
  • 9,640
  • 6
  • 60
  • 73
Lukazoid
  • 19,016
  • 3
  • 62
  • 85

1 Answers1

3

The reason for using ttinclude instead of assembly is the same as using T4 instead of custom tool for class generation (which is what you are actually doing and what most of designer used previously). T4 and ttinclude can be changed. You can copy ttinclude and create small change and include it in the main T4 per project basics.

Btw. do you know that there are tens of thousands of programers who can write a code without any intellisense ;) Worse support of intellisense is not reason to giving up using T4 templates.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • 2
    I never said I couldn't write code without intellisense, but I do understand the benefits which intellisense (and code refactoring, go to reference etc) provides. I am still partially using T4 templates, my assembly defines classes derived from TextTransformation. Having to change a ttinclude file per situation indicates to me that the classes contained weren't designed or implemented well enough, if we started copying and changing code for every situation it's like saying polymorphism doesn't exist. – Lukazoid Jan 25 '12 at 10:34
  • Having lots of classes in one ttinclude file seems to go against the .NET adopted philosophy of one class per file, if we split each class into its own ttinclude file, then we have lots of `<#@ include #>` at the top. Which is especially bad if attempting to re-use code (i.e. having to use relative paths which can get too long, or having to edit the registry to get it working). The other problem is the whole diamond problem with the includes, FileA includes FileB and FileC, FileB and FileC both include FileD, now text transform fails as the same classes (from FileD) are declared twice. – Lukazoid Jan 25 '12 at 10:53
  • I think using an assembly which contains the shared classes is much more preferable. (I'm sorry if I seem to be ranting, just trying to explain my reasoning) – Lukazoid Jan 25 '12 at 10:53
  • 2
    I don't think that purpose of T4 and its includes is to offer .NET philosophy. IMHO the purpose is to have C# or VB.NET as scripting language where script modification instead of ultra-mega-hyper reusable single script is preferable. – Ladislav Mrnka Jan 25 '12 at 11:59
  • 2
    I've read and thought through what you've been saying and have finally agreed with it. I don't want to lose the T4 scripting syntax so I've changed the approach I'm going for. I'll accept your answer for making me re-think the problem :) – Lukazoid Jan 30 '12 at 14:32