T4 – Text Template Transformation Toolkit#
matrix

Chances are you have never heard of T4.  Don’t worry, most haven’t.  This tool was introduced when the DSL tools hit the market.  As the name implies, it’s a code generation engine.  It’s my understanding, T4 is used under the scenes by the DSL tools to generate out it’s artifacts. This is also the tool that things like Linq to SQL and the Entity framework use to generate its artifacts.  Very Cool, and a bit daunting at first.

There are a number of great resources on Code Generation. I don’t want to recover what has been written better than I could but I do want to talk about the start of my journey with T4.  So like anyone I hit the ole WWW in search for answers.  The following resources got me rolling:

Needless to say you don’t really need anything to get started.  I don’t want to rehash anything already stated above, but I do want to cover a few good little hints I have learned so far.

  • You can include other TT files.
    • <#@ include file="core.tt" #>
  • “Class level functions”.  These have listed at the bottom of the TT file in a <=+ => if there are other code blocks in the TT file.
  • Set your output file type.  While you don’t really need it in VS if you are using the command line it will still save a few headaches. It can be whatever type of file type you want. 
    • <#@ output extension="XML" #>
  • Assembly References.  Just like a normal .NET program you have to reference what you need.  I was a bit surprised I had to reference System.Core for some Linq Queries.
    • <#@ assembly name="System.Core" #>
  • Imports.  Nothing different from a using statement in C#
    • <#@ import namespace="System.Xml.Linq"#>
  • You can’t pass in parameters into the T4 Engine. Well you can, but not with the host that ships out of the box.  Kathleen Dollard is actually working on a host that will address that situation but I have cheated in the meantime.  I have an settings file ( like a config ) which I set the setting file from my own host which in turn calls the T4 Engine.  The the templates just read that file getting whatever dynamic settings they need.
  • I have been driving my templates with Powershell. 
  • You can specify template framework versions, although you don’t have to.
    • <#@ template language="C#v3.5" HostSpecific="true" #>

I will indeed post more on T4.  It’s just amazing and we all should use it more.  As I do it more and more I find myself coming up *MUCH* more creative ways to generate the same artifact with less.

More to come…..

Sunday, May 31, 2009 9:59:09 PM (Central Daylight Time, UTC-05:00) #    Comments [0]  | 

 

May I borrow $25#

A man came home from work late, tired and irritated, to find his 5-year old son waiting for him at the door.

SON: “Daddy, may I ask you a question?”

DAD: “Yeah sure, what it is?' replied the man.

SON: “Daddy, how much do you make an hour?”

DAD: “That's none of your business. Why do you ask such a thing?” the man said angrily.

SON: “I just want to know. Please tell me, how much do you make an hour?'

DAD: “If you must know, I make $50 an hour.'

SON: “Oh,” the little boy replied, with his head down.

SON: “Daddy, may I please borrow $25?”

The father was furious, “If the only reason you asked that is so you can borrow some money to buy a silly toy or some other nonsense, then you march yourself straight to your room and go to bed. Think about why you are being so selfish. I don't work hard everyday for such childish frivolities.”

The little boy quietly went to his room and shut the door.

The man sat down and started to get even angrier about the little boy's questions. How dare he ask such questions only to get some money? After about an hour or so, the man had calmed down , and started to think: Maybe there was something he really needed to buy with that $25.00 and he really didn't ask for money very often The man went to the door of the little boy's room and opened the door.

“Are you asleep, son?” He asked.

“No daddy, I'm awake,” replied the boy.

“I've been thinking, maybe I was too hard on you earlier” said the man. “It's been a long day and I took out my aggravation on you. Here's the $25 you asked for.”

The little boy sat straight up, smiling. “Oh, thank you daddy!” he yelled. Then, reaching under his pillow he pulled out some crumpled up bills.

The man saw that the boy already had money, started to get angry again.

The little boy slowly counted out his money, and then looked up at his father.

“Why do you want more money if you already have some?” the father grumbled.

“Because I didn't have enough, but now I do,” the little boy replied.

“Daddy, I have $50 now. Can I buy an hour of your time? Please come home early tomorrow. I would like to have dinner with you.”

The father was crushed. He put his arms around his little son, and he begged for his forgiveness.

It's just a short reminder to all of you working so hard in life. We should not let time slip through our fingers without having spent some time with those who really matter to us, those close to our hearts. Do remember to share that $50 worth of your time with someone you love.

Saturday, May 23, 2009 7:49:56 AM (Central Daylight Time, UTC-05:00) #    Comments [0]  | 

 

Blogging again????#

You know sometimes it’s just sad how fast time can go by.  Looking back it’s been well over a year maybe two since I last blogged.  WOW, that’s not cool.  So what the hell happened, well LIFE I guess.  Let’s see:

question-mark1a.jpg

  • I had my second child ( girl, Addison ).  We are blessed to have one of each and both healthy. 
  • I got to meet Bill Gates, Steve Ballmer and all of the rest of the Microsoft executives
  • Bought a Honda ( needed a 4 door with 2 kids )
  • This fiscal year I will have billed over 2300 hours which doesn’t account for my other job.  Can you say Year of the Death March!!!
  • Ran into Sieg from the Deadliest Catch at SeaTac
  • Learned how to make the perfect Margarita!

Regardless a lot has happened and it’s time to talk technology again.  I love it and really miss doing it. With all of the great stuff here upon us now, it’s time to start sharing. I was reading MSDN Magazine the other day when I ran across an article about MSBuild and best practices which really got me thinking.  There were two items that really stuck out for me:

  1. Compilation of large source trees.  I think it’s a must read but caution readers that “large” can mean many different things. 
  2. Reference Management

While both were explained pretty well, lets put #2 into practice.  *I’M LAZY* ( in a good way of course ). I would much rather write something once rather than screw with it time and time again, especially the stuff you have to do like build work. 

So lets talk assembly references….

Assembly references can be easy as you want it to be but sometimes a little prep work will go a long way. The .NET compilers and runtime both have a specific order in which they look for references.  If you look in your framework folder for Microsoft.Common.Targets you will find the following:

The SearchPaths property is set to find assemblies in the following order:  legos

  1. Files from current project - indicated by {CandidateAssemblyFiles}
  2. $(ReferencePath) - the reference path property, which comes from the .USER file.
  3. The hintpath from the referenced item itself, indicated by {HintPathFromItem}. 
  4. The directory of MSBuild's "target" runtime from GetFrameworkPath.  The "target" runtime folder is the folder of the runtime that MSBuild is a part of.
  5. Registered assembly folders, indicated by {Registry:*,*,*}
  6. Legacy registered assembly folders, indicated by {AssemblyFolders}
  7. Look in the application's output folder (like bin\debug)
  8. Resolve to the GAC.
  9. Treat the reference's Include as if it were a real file name.

So what if your not one of those nine?!?!?

Since it’s all just angle brackets we can extend the “out of the box” search paths.  As it was explained in the article you can override the property AssemblySearchPaths.  Aaron had a great post on MSBuild Property Evaluation, it’s something you should read.  Overriding a property is as simple as importing your own target file into the stack and then resetting the property ( for most cases ).  You could also just add a the same property further down the stack in the same file.  Both are essentially the same. With MSBuild the *stack is always important*.  If you were to import your target file or override a property to early you might change the way the entire build system works.  There are a number of properties that work like:

This is a very common practice throughout MSBuild implementations.  As you can tell it’s just a way or protecting yourself from a change in behavior upstream. Remember MSBuild parses top down to you have no influence what might be done afterwards.  In our case what we want to do is import our targets file after the Microsoft.Common.Targets file in the csproj or vbproj file(s).

*NEW*

By doing so AssemblySearchPaths will be “” and initialize itself as expected.  So if we want to add to it it’s as simple as ( snip from MyTargets.Targets ):

....
   

     
          $(AssemblySearchPaths);
          C:\binaries\;
     

   
....

  1. Define a Property Group
  2. Define the Property ( AssemblySearchPaths )
  3. Set it to itself and add to itself

Important point, Reference Paths are folders not files.  So now if you compile from the cmd line or from VS you will have your paths in the stack. The easiest way to see what is going in is to simply run msbuild.exe /t:rebuild /v:diag on your sln file.  That will dump everything that took place during the execution from MSBuild. Even the order of folders it searched for.  You will actually be able to see the reference pats listed that it couldn't find.

But we are not done yet.  We have a hardcoded path and remember, I’m lazy. How about we bootstrap ourselves into the build process and read the file system building the search paths based on a “root” folder you specify?  Then any machine should work without any change.



    
        $(SolutionDir)..\MyBinaries\**\*.*
    

    
   
    
      
    
    
    

  
      
        $(AssemblySearchPaths);
        @(binariesFound->'%(RootDir)%(Directory)');        
      
    
  

Important points:

  1. InitialTargets was set. This gives us the ability to run *first*.  Why? Well we want to read the file system and build the list of folders.
  2. We create an item during the execution of the target rather than statically.
  3. We later transform that target just adding the folder rather than the whole file path.

Team Build has a similar concept but much easier.  At the bottom of any tfsbuild.proj fiile there is a commented collection called AdditionalReferencePath. It works the same it’s just that the Team Build process does it all for you already.

Friday, May 22, 2009 8:56:03 AM (Central Daylight Time, UTC-05:00) #    Comments [0]  | 

 

All content © 2010, Clark Sell
On this page
This site
Calendar
<September 2010>
SunMonTueWedThuFriSat
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789
Archives
Sitemap
Blogroll OPML
Disclaimer

Powered by: newtelligence dasBlog 2.3.9074.18820

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

Send mail to the author(s) E-mail

Theme design by Jelle Druyts


Pick a theme: