So, I’ve released yet another T4 editor for Visual Studio. It’s available to download now on the Visual Studio Marketplace. This blog post gives a bit more context about the release.

First off, if you don’t know what T4 is, I highly recommend skimming through the docs. In a nutshell, it’s a templating engine that lets you use C# to generate text, and it’s very simple (literally, the language only has like three concepts). It’s similar to using a string builder, but instead focusing on the C# and managing the builder yourself, T4 lets you focus on the output, sprinkling in a bit of C# as needed.

I’ve found a lot of great uses for T4 over the years. Here are some examples that I’m particularly proud of:

A legacy

Ok, maybe I’m not particularly proud of that last one since the templates are a bit sloppy and they deal way too much with whitespace. But T4 was a pretty big part of Entity Framework in the past. We used it to generate code from an .edmx file, and eventually (as linked above) to generate code from a model reverse engineered from a database.

The T4 ecosystem has been pretty good over the years, but it has also seen a lot of turnover. The following table shows some of the incredible extensions we’ve seen. The dots show when they were first released, and which subsequent versions of Visual Studio they supported.

  2008 2010 2012 2013 2015 2017 2019
Clarius ●            
Tangible ● ● ● ● ● ● ●
Devart   ● ● ● ● ● ●
Oleg Sych     ● ● ● ●  
Tim Maes             ●

A revival

Recent years have even seen a bit of a revival in the ecosystem. Mikayla Hutchinson has put a ton of work into adding T4 support to Mono and .NET Core, and JetBrains even added T4 support to Rider. Even we, the EF team, hope to keep the momentum going by adding support for T4 templates to scaffolding (again) in the next release.

So why?

Why release yet another T4 editor for Visual Studio? The table seems indicate that Tangible and Devart have a pretty good track record, and Tim Maes only recently entered the mix, so he’ll probably release a version for VS 2022 too, right?

Well, it’s complicated. I certainly hope they all release updated versions for VS 2022! They have way more features than I’ll ever be able to add to my extension by myself. But there are three main reasons why I also wanted to enter the mix.

First, I’ve been using Visual Studio 2022 exclusively for a few months now, and I desperately miss having syntax highlighting for my templates. It’s very easy to go cross-eyed and lose your place without it. I’ve obsessively searched for T4 in the extension manager over the past few months, but the list was always empty. As soon as Visual Studio 2022 RC released and the list was still empty, I decided it was time to take action.

Second, this wasn’t a new idea for me. Way back in 2015 when we were still developing .NET Core, I started thinking about how we could bring T4 to .NET Core. I remember sitting down with Taylor Mullen to learn more about how the ASP.NET Razor editor worked, and how that architecture might be replicated inside a T4 editor. Ever since, I’ve kept tabs on the Razor editor’s development, and watched as they moved to using TextMate grammars and LSP. This has enabled them to work across additional editors like VS Code. All the other T4 extensions I’ve seen for Visual Studio still use the traditional language extensibility APIs. I wanted to build something modern and reusable.

Finally, it was Microsoft’s annual Hackathon. I had three whole distraction-free days to bring my idea to life. I knew I could never compete with the functionality of existing editors, but I could at least provide myself and others with syntax highlighting in the meantime, using modern and reusable technologies.

What now?

So where does it go from here? Well, I don’t know. I may be just another dot on the table above. Or maybe this release can be the catalyst for rich, up-to-date tooling built into Visual Studio. Who knows; only time will tell…