This project is read-only.

Future of T4Toolbox

Mar 14, 2009 at 1:53 PM

I was having a peek to the latest code commits; I checked out that in the latest revisions, refers to T4Toolbox.dll.

I feel both happy and unhappy about it:

  • As an End-User I am happy, because this will make T4Toolbox faster, and I hope to see a Host to match the Toolbox...
  • As a open-source project owner, I choose T4Toolbox, because it permits to create "clean" code easily and there was no need to include .dll files that had to be registered to GAC, is order to generate code - all you need is just .tt templates. I am unhappy now, because it would not be easy to keep up with the newer versions of T4Toolbox, and take advantage of its new features.

George J.

Mar 14, 2009 at 4:15 PM

The next version of T4 Toolbox will support generation of output files in different folders and different projects. This was the main reason for moving some code from .tt files to the T4Toolbox.dll. It turned out that some types of projects, like Database and WiX are implemented with .NET classes and cannot be accessed from the templating AppDomain. As a workaround we have to load a shared assembly in both templating and main AppDomain and execute code that accesses Visual Studio automation model in the main AppDomain. I don't know of a way to accomplish this without a "static" .NET assembly.

What are the specific concerns you have about placing T4Toolbox.dll in the GAC?

Mar 15, 2009 at 5:16 PM

What I was telling before is that I am glad that T4Toolbox is evolving... As an end user I have no doubts that it will become better and better. I will have no problem use the new version or install its assembly at GAC.

But, as an open source owner, I don't feel that good. I want to be able to keep the agility of my project as I please - I don't feel that my project has to have an installer, I want it to have "copy & paste" deployment, I want it "quick & dirty". While T4Toolbox was based only on .tt templates I had that freedom - now with an assembly needed to be installed in GAC, I don't.

George J.
Mar 16, 2009 at 1:28 PM
It doesn't feel right presenting a problem, without offering any solution: I think that T4Toolbook, should also maintain its original architecture. A "Lite" version of the toolkit, certainly with fewer features, could be the solution...

George J.
Mar 16, 2009 at 9:52 PM
Thank you George. I understand your concern and appreciate you taking time to explain it.

I didn't realize that having an installer for a third-party open source project could be an issue. My assumption was that it wouldn't be a big deal for a project without installer to include T4Toolbox.msi as a pre-requisite. Project with existing installer could run the MSI in silent mode, so it wouldn't be a problem.

Unfortunately, xcopy deployment of T4 toolbox was never practical, among other reasons, because it relies on registry (IncludeFolders key) to work around the limitation of relative path resolution in T4. I honestly didn't want to have an installer, no offense to WiX, but authoring an MSI package is not for the faint of heart; it still doesn't work the way I want it to. If you have an idea on how T4 Toolbox can be deployed with an xcopy approach, I would be happy to provide a light version of the core framework.


Mar 17, 2009 at 12:48 AM
In SubSonic3, only the core files of T4Toolbox are used - see here: ( Subsonic3 needs no deployment, and T4Toolbox works just fine with these templates. If these files, could be offered as once, I think it that it would be better; they will only be updated to newer versions of T4Toolbox.

I know that S#arpAchitecture project ( is using T4Toolbox and its side project MindMelder ( Perhaps it would be a good idea to ask these guys if they have something in mind...

George J.
Mar 17, 2009 at 11:11 PM
Thank you for compiling the list, George. I will follow up with the Subsonic and S#arpArchitecture teams.