This project is read-only.

Where's the best place to ask T4 questions...

Mar 30, 2009 at 11:34 PM
I've got a couple of question on general T4 usage, not specific to the Toolbox.

Where's the best place to ask questions like this?

- T4 isn't picking up 3.5 language features - var, extension methods on framework classes, and LINQ. Is there something I'm overlooking or does this just not work. If it doesn't work, why not? Isn't is using the normal C# or VB compiler once it builds the files?
Mar 30, 2009 at 11:38 PM
My other current question is  that I'm getting a bunch of vertical whitespace at the top of my output, apparently one line for every directive.

Is this normal? How can they be suppressed?
Mar 31, 2009 at 4:30 AM
Hah!!  See, I told you.  I think it's a bug.  It's one of the things that drove me to using WriteLine's.
Mar 31, 2009 at 4:44 AM
I haven't tested yet, but one of the guys at AppVenture that's deep into the T4 stuff told me that if you append v3.5 to the language attribute (C#v3.5 or VBv3.5) you can compile with 3.5 features. It will be interesting to see how smart it is with assemblies.
Mar 31, 2009 at 5:48 AM
It is not true that you cannot use C# v3.5 features in T4 templates - all you have to do is choose "C#v3.5" as language instead of "C#"

George J.
Mar 31, 2009 at 5:55 AM
If you use T4Toolkit T4 templates, the way they are designed, you eliminate white space in output files to minimum.

Generally, you have problem white space in top of T4 templates output; you can put the directives, one next to the other, instead of one in each line, trying to reduce this space. Although, it not always possible to eliminate it completely...

George J.
Mar 31, 2009 at 2:15 PM

Do you mean teh T4Toolbox? I am not using it.

Isn't this whitespace thing an incredible bug? I mean I can easily enough add a postprocessor, but shouldn't we be pushing to get this fixed?

But thank you all (including Brett who answered off line) for the answers. It's not just a personal problem <g>

Mar 31, 2009 at 4:51 PM
I agree the bug should be fixed.  In the meantime, I'm just trying to make them most of what I've got.

I could get on board with running it through a postprocessor, but I don't know of an easy way to do that.  T4 runs as a custom tool inside Visual Studio, in addition to the command line version (probably best for use on the build server).  So I would want the postprocessor to get invoked on both ends.  VS has built-in code formatting, so you just need to figure out how to invoke it.  Maybe if T4 or the T4Toolbox had an option that you could just check, that would cause the VS code formatter to get invoked after the code was generated.  I really like the convenience of running T4 as a custom tool, so how do I retain that convenience and invoke a postprocessor?
Apr 2, 2009 at 10:47 PM
How about this ... what if the T4 Toolbox gave you a method RenderToFileAndReformat(...) in addition to the regular RenderToFile() method.  How would you implement that?  Obviously you'd have to use the VS extensibility API.  Can you marshal the VS formatter to format a file on disk, or do you have to load it into memory?  I don't know.  Let's say you have to load it into memory, reformat, then write it back out.  That's probably doable with the VS API.  You have to do some special case handling ... What if the file is already opened inside VS?  What if the file has been modified?  Do you throw away the changes, or prompt the user?  It's just going to get overwritten by the code generator anyways, so maybe you just throw it away.  Won't all of this cause some annoying flashing on the screen as VS opens the file, reformats it, saves it, and then closes it?  If you're generating a lot of files, won't that be annoying?  Can you hide that from the user?  Etc., etc., etc.

Just thinking out loud.  Hey, I love Kathleen's suggestion of postprocessing it.  Just trying to figure out how to do it.
Apr 2, 2009 at 11:18 PM
I'm afraid I'm living in a different world.

I'm using an external MEF based generator. I've been a few days from posting this publically for a month now. If you want my tales of frustration, I can share...

My MEF based generator will have source code available from day one, and will move officially open source as soon as I have it stable and a community. A few months probably.

I want my generation done in my build, not earlier. I don't templates in my project but organized separately. I'm used to doing it this way and have yet to figure out a really good fit for VS integration (other than the build).

Within VS, I think the answer to your question is a custom tool. Yes, this further fragments an already fragmented space, and yes it means you make a registry change. But custom tools are doable, and Peter Vogel has an article on them in March VSM at

I can send a pre-CTP of my generator to anyone who wants to take a look at it.
Apr 2, 2009 at 11:41 PM
Okay, maybe I can rephrase ... how do you chain two custom tools together in Visual Studio?  T4 already is a custom tool.
Apr 3, 2009 at 1:07 PM
I think adding an option to auto-format the output file is a good idea. Visual Studio can do it for several different types of files according to user preferences. I know where in the code it needs to be done, but not how.Would anyone be interested in researching and implementing this?
Apr 4, 2009 at 2:53 AM
I really need to stay focused on my MEF based generator becuase I really think the build is the better/right place for generation. There the reformat is easy.

However, a custom tool can either create its own T4 host or it could call the existing cutom tool.

Custom tools are associated with the extension in the registry, or can be manually set.

If someone tackles this and wants to know what I know about custom tools and custom T4 hosts (I know more about the latter, but have written, and written about both) you can contact me.
Apr 4, 2009 at 2:55 AM
I really should have said:

"There the reformat is easy to insert"

it is actually somewhat harder to write as I don't really want to open VS during a build.

Also, fair warning to anyone attacking this: VS2010 is a full rewrite. I've heard nothing about changes to the custom host technique, but its really early to know that.
Apr 5, 2009 at 8:28 AM
Kathleen and I are definitely operating in different worlds.  Someday I will figure out what a "MEF based generator" is.  I don't even know what that means!  In fact, I'm not 100% sure I even know what MEF is.  I think she means Entity Framework, and the "M" must stand for Microsoft, but I've just never seen that acronym before.  I must be reading the wrong magazines, or my MSDN Magazine backlog is getting too long.  But I thought Entity Framework was about OR mapping, so I'm just totally confused.

I can understand the motivation for generating code on the build side, but in my view that would be in addition to the generation on the desktop side.  I need the convenience of desktop-based generation so that I can quickly modify a metadata file, regenerate the code, and test/debug it.  I certainly don't want to do round-trips to the build server every time I add new metadata.  The convenience of having T4 run as a custom tool is a great productivity boon, even if it ends up being just a throw-away, with the "real" code generation happening on the build server.

I know how to write custom tools ... I did it with XmlGen#.  I know how to do the registry entries for custom tools.  I haven't done a custom T4 host.  I still don't see an easy way to chain the two custom tools together in an effective way.  I can see how it could be done if a template is generating a single file as output, but with the multi-file output that the T4 toolbox provides, chaining two custom tools together is a much trickier proposition.  In any case, I would hardly characterize any of these approaches as "easy".  With the multi-file output capabilities of T4 toolbox, the only effective way I can see to do the chaining is for the reformatting to be built into T4 toolbox itself, which is what I was thinking when I wrote the suggestion.

Until someone can crack this nut, I'm still sticking to my proposition that formatting and whitespace management inside the template itself isn't such a bad idea.
Apr 6, 2009 at 9:55 PM
Hard as I tried to resist "shiny new thing", curiosity got the better of me and I just had to figure out what MEF is.  It's not Entity Framework.  No wonder why I was so confused. 

MEF stands for Managed Extensibility Framework.  It's an open source project on CodePlex run by Microsoft ...  It's purpose is to create a standardized way for applications to be extended with plug-ins.  It was first CTP'd last June and is currently in alpha stage with the current release "Preview 4", as of this writing (Preview 4 released Jan. 26, 2009).  So it's pretty new, which makes me feel a little better about not knowing what it was.

I'm still trying to grok what it has to do with code generation, but at least I'm catching up a little.
Apr 8, 2009 at 12:34 PM
Thank you for sharing your thoughts, everyone. I think we can say that there are two schools with regard to when the code should be generated. Some of us believe that design-time code generation is the way to go, while others prefer to generate code at build-time. T4 Toolbox currently implements the design-time approach. However, people keep asking about build-time code generation. We are currently discussing how T4 Toolbox could support it here: Please join the discussion if you are interested.