Visual T4 Blog

Visual T4 beta 1 for VS 2010 is now available!

noreply@blogger.com (Visual T4) — Mon, 08 Nov 2010 06:42:00 +0000

During the last month we have been receiving a constant flow of daily emails like “where the heck is the VS2010 version???” so we are pleased to announce the public availability of the beta 1 bits which you can download from the Extension Manager dialog or by hand from the Visual Studio Gallery.

Visual T4 for VS 2010 is an almost complete re-write from the VS 2008 version. We wanted to take advantage of the new WPF-based editor and MEF introduced in VS 2010 to offer the best possible experience you can have when editing T4 files.

As a result of this most 3rd party extensions out there in the VS Gallery should be compatible with Visual T4 thus improving your productivity even when writing T4 code.

You can see below the very handy Quick Add Reference in action, working from inside a C# embedded code block:

Or the Regex Editor, used to edit a regular expression inside a C# code block:

The beta 1 bits are pretty stable although there are a few nasty issues that we are working on fixing for beta 2 but we didn’t want to hold on releasing the bits as there were LOTS of you interested in early trying them.

PLEASE share your feedback with us: bugs, suggestions, etc., everything is welcomed and we try to reply to every email we receive. You can follow us @visualt4, reach us at visualt4@clariusconsulting.net, or use the comments on this posts, or the QA section in the VS Gallery entry.

Visual T4 for Visual Studio 2010

noreply@blogger.com (kzu) — Sat, 21 Aug 2010 06:40:00 +0000

It’s been a long time since our last post. I just wanted to let you know about the amazing progress we’ve been making on Visual T4 for VS2010. What’s new in short? A major overhaul to take full advantage of all the benefits of the brand new WPF-based core text editor as well as the new language services to provide the absolutely unique and long-time praised Intellisense integration.

We’ll go into the details on another post, but here’s a bunch of screenshots to get you excited, using the ADO.NET C# POCO Entity Generator templates.

Colors honor your favorite C# editor settings:

Tooltips as usual in C#:

Intellisense on APIs as usual in C#:

Parameter info as usual in C# code :)

Pretty good indenting!

Full support for VERY complex includes! (the EF one has 2200+ lines)

Full T4 directives intellisense with tooltips, as you’d expect:

Can add arbitrary assemblies an get their intellisense too:

Can build any LINQ query you fancy with full intellisense:

Use your favorite code snippets as usual in C#:

With even full anonymous types support:

And Intellisense of course:

A BIG kudos to the Visual T4 team for such an amazing integration into VS2010. We’ll be sharing the bits more broadly very soon. We’re beta testing it at this very moment.

Buy Visual T4 Pro, Get Free Pro ASP.NET MVC Book!

noreply@blogger.com (Visual T4) — Mon, 29 Jun 2009 18:24:00 +0000

Yes, the best T4 Editor meets the best ASP.NET MVC book.

If you’re into ASP.NET MVC and want to play and customize the MVC T4 templates with wonderful support getting full Preview, IntelliSense, syntax coloring and more for both T4 and C# embedded code this deal is for you!

Buy here the Visual T4 Editor Professional and you will get the book for free.

This promotion is only valid till July, 3rd, 2009 or until we ran out of our 100 books stock, whatever comes first.

As we know no one wants to wait a week for a book we will ship it using a 2nd-day service to get you the book really quick.

Please note we can only ship to an US address, sorry.

Visual T4 in the news!

noreply@blogger.com (Visual T4) — Tue, 21 Apr 2009 01:02:00 +0000

Our Visual T4 products continue to be mentioned by pretty much everyone out there working with T4. You already know our tools were used in MIX09 (besides other major conferences in the past) and that pretty big teams at Microsoft recommend it.

We did google a bit and these are the most “remarkable” mentions we’re getting (it’s just great to see we have built the “standard” tool for editing T4 files!):

Scott Hanlseman (Principal Program Manager, Microsoft) on T4 (Text Template Transformation Toolkit) Code Generation - Best Kept Visual Studio Secret:

"if you want really get the most out of T4, first, head over to Clarius Consulting and get their "T4 Editor Community Edition." That'll get you some basic coloring. They have a pay version that gets you more if you want."

Oleg Sych, uses Visual T4 Editor in his must-read series of T4 articles mentions:

“…Instead, the approach used by Clarius in their implementation of this directive included with T4 Editor relies on CallContext, is a lot more robust and elegant…”

“…Text editing and debugging support for T4 templates is currently rather limited. T4 Editor (a free download) from Clarius Consulting provides IntelliSense and syntax highlighting in Visual Studio text editor for .tt files…”

Miguel de Icaza, on Mono's Text Template Transformation Toolkit (T4):

“To my surprise T4 thing is wildly used by lots of people. Daniel Cazzulino's company has a product just to improve Visual Studio's support for editing .tt files.”

Redmond Developer News , on Code Generation Made Easy :

"There are a lot of tools out there that do code generation," Conery says. "Great tools like CodeSmith and Clarius Consulting's T4 Editor”

Gareth Jones (Visual Studio team member, Microsoft) , on Clarius take T4 editing to the next level :

“…I see that Clarius have now got to an alpha stage for the next stage of their T4 editing toolset.

As well as their Community Edition and Pro Edition, they're now going to offer a full-featured code generation environment they're calling Visual T4 Code Generator, including tight integration with server explorer, database tables and XML as well as a multi-file generation implementation out of the box and lots more beside…”

Pedro Silva (Visual Studio team member, Microsoft) , on T4 Editor Beta Released:

“The folks at Clarius have an update to their T4 template editor. They're now in Beta. It's a very useful editor for anyone doing large amounts of T4 template editing with good factoring of template code vs script and color coding of keywords.”

Kathleen Dollard (Microsoft MVP) , on What’s Wrong with T4?:

“There’s good news here. Clarius provides a colorizing editor as a community edition to get you started. If you want fancier features, their main product is just $100”

Hanselminutes on Code Generation

noreply@blogger.com (Visual T4) — Tue, 21 Apr 2009 00:47:00 +0000

In case you missed this (as we did) Scott interviews Kathleen Dollard (Microsoft MVP) on code generation in .Net and Visual Studio.

It’s an interesting chat on the past and current state of code gen, with emphasis on T4. You can listen to the podcast here.

Make sure you don’t miss the audio @ 19m:43s where Clarius Visual T4 Editor is recommended if you are into serious editing of T4 templates :)

The process of building a Code Generation template

noreply@blogger.com (Visual T4) — Fri, 27 Mar 2009 02:46:00 +0000

More often than not, you’ll have several related classes and you’ll want to turn them into generated code. There is a process I like to use to make a generation template that’s based on this idea. You can also use the process even if you don’t have the classes, by building them manually.

First, you’ll need a class. For example, we’re going to use generation to create a strongly type representation of a directory structure and files on disk. In the example, these files will be configuration files spread throughout a few directories, but we’ll open them as simple strings to make the sample easier. Let’s look at the code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;

namespace MyCompany.MyProduct
{
    class Configuration
    {
        private string baseDir = "Configuration";

        public Configuration(string baseDir)
        {
            this.baseDir = string.Concat(baseDir, "\\Configuration");
        }

        public Network Network
        {
            get
            {
                return new Network(baseDir);
            }
        }
    }

    class Network
    {
        private string baseDir;

        public Network(string baseDir)
        {
            this.baseDir = string.Concat(baseDir, "\\Network");
        }

        public string ProxiesConfig
        {
            get
            {
                return File.ReadAllText(string.Concat(baseDir, "\\Proxies.Config");
            }
            set
            {
                File.WriteAllText(string.Concat(baseDir, "\\Proxies.Config"), value);
            }
        }

        public string HostsConfig
        {
            get
            {
                return File.ReadAllText(string.Concat(baseDir, "\\Hosts.Config");
            }
            set
            {
                File.WriteAllText(string.Concat(baseDir, "\\Hosts.Config"), value);
            }
        }
    }

    class Security
    {
        private string baseDir;

        public Security(string baseDir)
        {
            this.baseDir = string.Concat(baseDir, "\\Security");
        }

        public string RolesConfig
        {
            get
            {
                return File.ReadAllText(string.Concat(baseDir, "\\Roles.Config");
            }
            set
            {
                File.WriteAllText(string.Concat(baseDir, "\\Roles.Config"), value);
            }
        }
    }
}

Notice that this code already has a “generated” look and feel. The idea is to create a Configuration object with the base path for configuration, and to go down from there to all the configuration items. Network and Security will be directories within Configuration, and the other properties will refer to files in the directories. Notice also that at this point it’s not very important to have complete classes. A rough layout is enough.

The next step is to find varying parts. This is really simple: variables will generally be present as constants or as variable properties. Constants is far more common. In this step, we’ll replace the constants with representative code blocks:

    class Configuration
    {
        private string baseDir = <#= baseDirectoryName #>;

        public Configuration(string baseDir)
        {
            this.baseDir = string.Concat(baseDir, “<#= baseDirectoryPath #>”);
        }

        public Network Network
        {
            get
            {
                return new Network(baseDir);
            }
        }
    }

    class Network
    {
        private string baseDir;

        public Network(string baseDir)
        {
            this.baseDir = string.Concat(baseDir, “<#= baseDirectoryPath #>”);
        }

        public string ProxiesConfig
        {
            get
            {
                return File.ReadAllText(string.Concat(baseDir, “<#= configFileName #>”);
            }
            set
            {
                File.WriteAllText(string.Concat(baseDir, “<#= configFileName #>”), value);
            }
        }

        public string HostsConfig
        {
            get
            {
                return File.ReadAllText(string.Concat(baseDir, “<#= configFileName #>”);
            }
            set
            {
                File.WriteAllText(string.Concat(baseDir, “<#= configFileName #>”), value);
            }
        }
    }

Then we’ll also replace the varying property names (and class and method names if necessary) with code blocks too:

    class <#= baseDirectoryName #>
    {
        private string baseDir = <#= baseDirectoryName #>;

        public Configuration(string baseDir)
        {
            this.baseDir = string.Concat(baseDir, “<#= baseDirectoryPath #>”);
        }

        public <#= childDirectoryName #> <#= childDirectoryName #>
        {
            get
            {
                return new <#= childDirectoryName #>(baseDir);
            }
        }
    }

    class <#= baseDirectoryName #>
    {
        private string baseDir;

        public <#= baseDirectoryName #>(string baseDir)
        {
            this.baseDir = string.Concat(baseDir, “<#= baseDirectoryName #>”);
        }

        public string <#= configFileName #>
        {
            get
            {
                return File.ReadAllText(string.Concat(baseDir, “<#= configFileName #>”);
            }
            set
            {
                File.WriteAllText(string.Concat(baseDir, “<#= configFileName #>”), value);
            }
        }

        public string <#= configFileName #>
        {
            get
            {
                return File.ReadAllText(string.Concat(baseDir, “<#= configFileName #>”);
            }
            set
            {
                File.WriteAllText(string.Concat(baseDir, “<#= configFileName #>”), value);
            }
        }
    }

At this point, you should have some duplication. The next step is to remove that duplication by looping through duplicated constructs:

<#
  for (int classes = 0; classes < n; classes++)
  {
#>
    class <#= baseDirectoryName #>
    {
        private string baseDir;

        public <#= baseDirectoryName #>(string baseDir)
        {
            this.baseDir = string.Concat(baseDir, “<#= baseDirectoryName #>”);
        }

<#
      for (int props = 0; props < n; props++)
      {
#>
        public string <#= configFileName #>
        {
            get
            {
                return File.ReadAllText(string.Concat(baseDir, “<#= configFileName #>”);
            }
            set
            {
                File.WriteAllText(string.Concat(baseDir, “<#= configFileName #>”), value);
            }
        }
<#
      }
#>
    }
<#
  }
#>

You should also add whatever’s left behind (in this case, the “directory” properties:

<#
  for (int classes = 0; classes < n; classes++)
  {
#>
    class <#= baseDirectoryName #>
    {
        private string baseDir;

        public <#= baseDirectoryName #>(string baseDir)
        {
            this.baseDir = string.Concat(baseDir, “<#= baseDirectoryName #>”);
        }

<#
      for (int childClasses = 0; childClasses < n; childClasses++)
      {
#>
        public <#= childDirectoryName #> <#= childDirectoryName #>
        {
            get
            {
                return new <#= childDirectoryName #>(baseDir);
            }
        }
<#
      }
#>
<#
      for (int props = 0; props < n; props++)
      {
#>
        public string <#= configFileName #>
        {
            get
            {
                return File.ReadAllText(string.Concat(baseDir, “<#= configFileName #>”);
            }
            set
            {
                File.WriteAllText(string.Concat(baseDir, “<#= configFileName #>”), value);
            }
        }
<#
      }
#>
    }
<#
  }
#>

At this point, you should have a pretty good skeleton. The point now is to make it work:

<#
  foreach(string directory in Directory.GetDirectories("myconfigurationdir"))
  {
#>
    class <#= directory #>
    {
        private string baseDir;

        public <#= directory #>(string baseDir)
        {
            this.baseDir = string.Concat(baseDir, "<#= directory #>");
        }

<#
      foreach (string childDirectory in Directory.GetDirectories(directory))
      {
#>
        public Network <#= childDirectory #>
        {
            get
            {
                return new <#= childDirectory #>(baseDir);
            }
        }
<#
      }
#>
<#
      foreach (string file in Directory.GetFiles(directory))
      {
#>
        public string <#= file #>
        {
            get
            {
                return File.ReadAllText(string.Concat(baseDir, "<#= file #>");
            }
            set
            {
                File.WriteAllText(string.Concat(baseDir, "<#= file #>"), value);
            }
        }
<#
      }
#>
    }
<#
  }
#>

At this point you should be added any imports that are needed for the generation code to work (System.IO in this case). You may also need to separate processes in methods, as to make them recursive. For instance, our classes need to be generated for each directory in the hierarchy. Finally, you must solve generation-specific problems. For instance, this generation will probably have many invalid class and property names (“Proxies.Config” is not a valid class name). You can change that by using the CleanName procedure that we already reviewed in this blog. The result will look something like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;

<#
  GenerateClass("myconfigdir");
#>
<#+
void GenerateClass(string directoryName)
{
  foreach(string directory in Directory.GetDirectories(directoryName))
  {
#>
    class <#= CleanName(directory) #>
    {
        private string baseDir;

        public <#= CleanName(directory) #>(string baseDir)
        {
            this.baseDir = string.Concat(baseDir, "<#= directory #>");
        }

<#+
      foreach (string childDirectory in Directory.GetDirectories(directory))
      {
#>
        public <#= CleanName(childDirectory) #> <#= CleanName(childDirectory) #>
        {
            get
            {
                return new <#= CleanName(childDirectory) #>(baseDir);
            }
        }
<#+
      }
#>
<#+
      foreach (string file in Directory.GetFiles(directory))
      {
#>
        public string <#= CleanName(file) #>
        {
            get
            {
                return File.ReadAllText(string.Concat(baseDir, "<#= file #>");
            }
            set
            {
                File.WriteAllText(string.Concat(baseDir, "<#= file #>"), value);
            }
        }
<#+
      }
#>
    }
<#+
    GenerateClass(directory);

  }
}

string CleanName(string)

   {

	//some code cleaning here

	}
#>

The final step is to separate the code into modules. For instance, you can put the CleanName procedure in an include T4 file to be used as a helper, put the header in a “main” T4 and the methods in generation T4 files, separate the properties into its own include, or whatever feels good to you.

--

Written by Joaquin, joj AT clariusconsulting DOT net. Disclaimer: opinions expressed in this post are my own and not necessarily reflect those of Clarius Consulting.

Visual T4 @ MIX09

noreply@blogger.com (Visual T4) — Tue, 24 Mar 2009 05:06:00 +0000

We’ve been catching up on web techs watching MIX09 videos and guess what…?

Scott Hanselman in his File|New -> Company: Creating NerdDinner.com with Microsoft ASP.NET Model View Controller (MVC) and Phil Haack in his Microsoft ASP.NET Model View Controller (MVC): Ninja on Fire Black Belt Tips talks both mention the Clarius Visual T4 Editor for editing T4 templates!

Here is a screenshot of Phil, on stage, using the Visual T4 Editor Professional edition:

Good to see Visual T4 being used everywhere!!

NHibernate: Why override GetHashCode and Equals?

noreply@blogger.com (Visual T4) — Tue, 24 Mar 2009 04:53:00 +0000

When using NHibernate collections, or when comparing two objects that are configured via NHibernate configuration, NHibernate code will use the Equals and GetHashCode methods in the class. It is very important to implement this methods in a way that will make two different entities return different values and to identical entities return identical values. That’s the only condition. The value doesn’t need to be related to anything in the table at all as long as it passes that test. This is both easy and hard. Let me show you why.

The point here is to always generate a value that will represent a row in the table. In a normal table, any candidate key (that is, a unique index or a primary key) will serve this role. In the samples that come with Visual T4 Editor Professional edition we use the primary key to generate these methods:

        public override int GetHashCode()
        {
            int hashCode = 0;
            hashCode = hashCode ^ CustomerID.GetHashCode();
            return hashCode;
        }
        
        public override bool Equals(object obj)
        {
            Customers toCompare = obj as Customers;
            if (toCompare == null)
            {
                return false;
            }
            if (this.CustomerID != toCompare.CustomerID)
            {
                return false;
            }
            return true;
        }

The Equals method is fairly simple to override. Just compare keys, and if everything matches return true. GetHashCode is a little different. You must return an integer value tailored to the needs of the two rules. For the sample, we have chosen to use xor to compare, due to a high success rate. For production code, you should choose to “shift and or” or to concatenate and get the hash code of the string. Both methods will give you a 100% success rate, on varying levels of complexity and performance.

There is an additional problem here, specially for code generation: if you have a transient object (that is, one that is not yet saved to the database) and identity value will always be a bad choice. The problem is that until NHibernate saves the object to the database, the value of the identity (or primary key, depending on configuration) will be the default value for the datatype (0 in this case). Hence, two unsaved values will be equal. Although this is technically correct (unsaved values may be considered “null” for some purposes) it is highly impractical.

In this case, the best solution is to take an alternate key (an unique non-null key) and use that for the comparison. As long as the user actually fills that value when constructing the object, everything should be fine. A code generator may find a candidate key and use it. It will not, however, be able to know if this candidate key will be filled when needed. As a default solution both primary key and a candidate key may work. As a definitive solution, you should use the class knowing that you may run into this issue and manually override (as explained in Extending Code Generation with Partial Classes and Inheritance) when needed. To be 100% sure, you should always create the GetHashCode manually, and override equals with this:

        public override bool Equals(object obj)
        {
            Customers toCompare = obj as Customers;
            if (toCompare == null)
            {
                return false;
            }
            return (this.GetHashCode() != toCompare.GetHashCode())
        }

--

Written by Joaquin, joj AT clariusconsulting DOT net. Disclaimer: opinions expressed in this post are my own and not necessarily reflect those of Clarius Consulting.

Transforming Type Names

noreply@blogger.com (Visual T4) — Tue, 24 Mar 2009 04:41:00 +0000

There are many situations in code generation where you may need to render the name of a Type in the generated file. For instance, you may have a method somewhere that translates a data type in a specific format to a Type, and then you want to render that type. The easy way to do it is obviously

    Type.ToString()

but this has many drawbacks. The first problem, and this is mostly aesthetic, is that standard types like “int”, “long”, “double”, etc will be rendered as “System.Int32”, “System.Int64”, “System.Double”. Although this will work, the resulting code will have a “generated” look and feel. Your code should always be as “not-generated” as possible. That will make it easier to read and debug.

The second problem is that there are types that will simply not translate to your preferred language easily. For instance, “List<string>” will be translated as “System.Collections.Generic.List’1[System.String]”. There is no way for that text to be useful in a generation context!

There are a few ways to work around this. You may code a few methods that will translate from the Type to your language. This is not a trivial task, but there are a few implementations readily available. For instance, the class ContractNameServices.cs in MEF (http://www.codeplex.com/MEF/SourceControl/changeset/view/26383#370431) has a method named GetDefaultContractName which does just that, and it is very cleanly implemented.

The easiest way is to use a CodeDomProvider for your language. The following few lines of code illustrate this concept:

CodeTypeReferenceExpression type = new CodeTypeReferenceExpression(typeof(System.Collections.Generic.List<float>));
CodeDomProvider csProvider = Microsoft.CSharp.CSharpCodeProvider.CreateProvider("C#");
CodeDomProvider vbProvider = Microsoft.VisualBasic.VBCodeProvider.CreateProvider("VB");
StringWriter writer = new StringWriter();
csProvider.GenerateCodeFromExpression(type, writer, new CodeGeneratorOptions());
writer.Write(writer.NewLine);
vbProvider.GenerateCodeFromExpression(type, writer, new CodeGeneratorOptions());
Console.WriteLine(writer.ToString());

The output of this code will be:

System.Collections.Generic.List<float>
System.Collections.Generic.List(Of Single)

which is both useful and language independent at the same time.

--

Written by Joaquin, joj AT clariusconsulting DOT net. Disclaimer: opinions expressed in this post are my own and not necessarily reflect those of Clarius Consulting.

Visual Web Developer Team @ MS highly highly recommends Visual T4 Editor

noreply@blogger.com (Visual T4) — Wed, 18 Mar 2009 17:40:00 +0000

We really love each time we see our Visual T4 products used inside Microsoft.

The Visual Web Developer Team in T4 Templates: A Quick-Start Guide for ASP.NET MVC Developers says:

If you open a .tt file inside Visual Studio, you may notice they look a bit flat – like a wall of black text. We highly highly recommend you download T4 Editor, an add-on to Visual Studio made by Clarius Consulting, to provide you with syntax highlighting and some basic T4 statement completion. They have a free version called the ‘Community Edition’, as well as a much more powerful ‘Professional Edition’ – check out the feature comparison if you are interested. This add-on really makes a big difference in template authoring, as you can see below.

While the bigger font size and strident red-on-yellow colors are ours the ‘highly highly’ is theirs :-)

Where did my Visual T4 IntelliSense go?

noreply@blogger.com (Visual T4) — Mon, 09 Mar 2009 14:45:00 +0000

If you're using Refactor! or Resharper you will notice that the IntelliSense provided by the Visual T4 Editor for embedded C# code blocks doesn’t work as expected.

The reason for this is the above mentioned tools replace the built-in Visual Studio C# IntelliSense and provide their custom ones.

This doesn’t play well with any other tool expecting the built-in IntelliSense to be there, as it is the case for our Visual T4 Editor and the built-in ASP.NET editor which won’t also behave well if you have any of the two refactoring tools installed.

The cure? Download and install this patch.

Then: open Visual Studio and go to Tools -> Options, open the tree at Text Editor\T4 Editor\Miscellaneous and check the Intellisense replacement item.

This is a new experimental feature that tries to mitigate Refactor! and Resharper “hacky manners” of replacing the built-in IntelliSense and will get back to normal the IntelliSense support while editing a C# embedded code block in a T4 template.

We’ve also detected that these refactoring tools don’t do a great job of restoring previous settings after uninstalling them, so it may be the case that you once used them but you currently don’t have any of them installed and you still don’t get proper IntelliSense. This can be fixed this way: go to Tools –> Options, browse the tree at Text Editor\C#\General and make sure Auto list members is checked.

We want to thank all of our customers that are also Refactor! or Reshaper customers and have reported this, you can all now enjoy the fix!.

Now supporting ASP.NET MVC code generation!

noreply@blogger.com (Visual T4) — Thu, 05 Mar 2009 07:41:00 +0000

UPDATE: added correct download link

After teasing you a bit here we took a couple of weeks to test this and have now added support for nice integration between the ASP.NET MVC bits and our Visual T4 Editor.

If you are an existing customer who bought your copy before 03/03/09 you can download for free the patch to add support for this (and a few more other goodies) from here.

If you buy the Visual T4 Editor today, you will get this support right into the box, without having to install anything else.

As you can see, we do care for keeping our Visual T4 products updated up-to-the-minute to support all the new stuff that will be coming out from Microsoft and other companies regarding T4 adoption.

NHibernate configuration: Xml, Fluent or Attributes

noreply@blogger.com (Visual T4) — Mon, 02 Mar 2009 04:00:00 +0000

When using NHibernate, you need to map tables to objects. Without this mapping, there is no way to reconcile the two models. The mapping can be done in three very different ways: Attributes, Xml or Fluent syntax. Each model has its pros and cons. Let’s review them one by one.

Fluent

This is the newest way of doing OR/M in NHibernate. It works by providing a constructor that will establish the mappings using a Map() method, and by inheriting from a NHibernate provided class, like this:

public CustomerMap : ClassMap<Customer>  
{  
  public CustomerMap()  
  {  
    Id(x => x.ID);  
    Map(x => x.FirstName);  
    Map(x => x.LastName);  
    HasMany<Address>(x => x.Addresses)  
      .AsBag();  
  }
}

You can find more information about this type of mapping in James Gregory’s blog.

Fluent mapping is cool, and it’s the newest way of mapping. This way of mapping is not officially supported, and it doesn’t cover every possible mapping, but it’s type safe (as it’s fluent), it’s really simple and it doesn’t use Xml. Also, since the mapping class is outside of the “Model” class, the model integrity is preserved.

Attributes

Attributes are also a very effective way of mapping without using Xml. When you use attributes, NHibernate creates the Xml for you on runtime. That is, you may not be using the xml config files, but the files are being generated and used anyway. Attributes are used like this:

[NHibernate.Mapping.Attributes.Class]    
public class Customer    
{        
    [NHibernate.Mapping.Attributes.Id(0, TypeType=typeof(int))]
    public int ID;
    [NHibernate.Mapping.Attributes.Property]        
    public string FirstName;   
    [NHibernate.Mapping.Attributes.Property] 
    public string LastName;   
}

The cool thing about attributes is that you don’t violate the DRY principle. You do violate it (a lot) when using xml files. The bad thing about attributes is that they are all over your model. That pushes NHibernate all over the place instead of leaving it in your persistance layer (where it should be). Also, the attributes require a certain order, which is counterintuitive to the way attributes are generally used.

Xml

Xml is the standard format for configuration. It looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
    namespace="MyNamespace" assembly="MyAssembly">

    <class name="Customer" table="Customers">
        <id name="ID">
            <generator class="identity" />
        </id>

        <property name="FirstName" />
        <property name="LastName" />

        <bag name="Addresses" table="Addresses">
            <key column="CustomerID"/>
            <one-to-many class="MyNamespace.Address, MyNamespace"/>
        </bag>
    </class>
</hibernate-mapping>

This format is slightly more complex than the others, and it’s inherently not safe as it’s Xml and not code. It also forces you to repeat information already stated (class names, property names, etc). On the other hand, it’s completely transparent to your code, allowing you to take NHibernate out of the picture at any time, or adding it with no changes to your model.

How this affects code generation

If you’re generating your DAL using T4, your perspective on some of these issues may change a little. First, even though DRY is an important principle, it isn’t as important in code generation. You’re not repeating yourself, the generated code is. There’s a difference there: only one set to maintain (not two), and if the code is being regenerated in each build, then there’s nothing to maintain. That eliminates the main advantage of using attributes.

Also, type safety isn’t that important because in generated code you’re not actually writing the code. Compile time safety is cool, but if your code is being properly generated you don’t have a big error-prone surface in the configuration. That eliminates the main advantage of using Fluent configuration.

In code generated code, I always try to make the code as close as possible as code I would have written by hand. That is, no weird names, standard data types, regular patterns. Both Fluent (to a lesser extent) and Attributes provide a very strong binding to NHibernate. Also, Fluent is not (yet) fully functional and fully supported. Xml is still ugly, but it’s being generated automatically and it shouldn’t be modified by the developer.

That’s why in the context of code generation I prefer to use Xml configuration instead of Attributes or Fluent.

--
Written by Joaquin, joj AT clariusconsulting DOT net. Disclaimer: opinions expressed in this post are my own and not necessarily reflect those of Clarius Consulting.

Visual Studio 2010: we’re getting there.

noreply@blogger.com (Visual T4) — Mon, 02 Mar 2009 01:17:00 +0000

We’ve received a couple of emails now from (very) early adopters guys asking us if we do have a VS 2010 compatible version of our Visual T4 Editor and Visual T4 Code Generator.

The answer is no, we don’t have one just yet.

The reason is publicly available Visual Studio 2010 CTP bits are not ready yet to support the basics we need to make an early release of our tools.

So, when can you expect our Visual T4 bits running on Visual Studio 2010? We’re working –a lot– on having some early bits that we will make available by when Visual Studio 2010 beta 1 goes out.

And… when is Visual Studio 2010 beta 1 going out? Well, this is a question you should ask to Microsoft! :)

Extending code generation with partial classes and inheritance

noreply@blogger.com (Visual T4) — Mon, 09 Feb 2009 23:14:00 +0000

One of the bigger problems with Code Generation is changeability. Generated code should never be modified. Anything that you modify on a generated class will be lost when you run the generation again. The problem is that if you need to extend/alter your generated class, you cannot do it without taking it out of the generation process (which is sometimes acceptable, but mostly not).

Gladly, C# 2.0 introduced the concept of “partial” classes a long time ago. You must have seen it. When you create a new Windows Form, you get two classes; one is for the generated code in InitializeComponents and the other is for you to use. If your architecture is similar to this case, you can do the same: generate a partial class with all the generated code and have a partial class with any extra code the developer may need to add.

Most of the times, though, the need is to replace the generated code with something completely different in some specific cases. That is, almost all the generated code is ok, but one or two methods in one or two classes need to be replaced. In this case, you can use a different approach: the “double-derived” pattern introduced in Microsoft DSL. It works like this:

When you generate code, you generate 2 classes instead of one. The first class (MyGeneratedClassBase) will have all the methods implemented and marked as virtual. The second class (MyGeneratedClass) will inherit from the first class, and will be marked as partial. This will be transparent to whoever needs to use the class and it will allow you to change the implementation of the methods you need via overriding. If you regenerate the classes afterwards, nothing breaks.

Let me show you in an example. Say you are generating classes from a database. You generate each table with properties for the fields and CRUD methods. Something like this:

public class Customer
{

    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }

    public int Create() 
    {
        //some implementation
    }

    public void Update() 
    {
        //some implementation
    }

    public void Delete() 
    {
        //some implementation
    }

    public void Retrieve() 
    {
        //some implementation
    }

}

Now, let’s suppose you need to override the Delete method so you will not be allowed to delete customers (let’s assume this makes sense just for the sample). If you change the generated class directly, you’ll loose your changes when the class is regenerated. In the double-derived pattern, you’ll have this instead:

public class CustomerBase
{

    public virtual int Id { get; set; }
    public virtual string FirstName { get; set; }
    public virtual string LastName { get; set; }

    public virtual int Create() 
    {
        //some implementation
    }

    public virtual void Update() 
    {
        //some implementation
    }

    public virtual void Delete() 
    {
        //some implementation
    }

    public virtual void Retrieve() 
    {
        //some implementation
    }

}

public partial class Customer : CustomerBase
{
}

A developer will use the Customer class as before, but now you can create a new partial class for Customer, overriding the Delete method like this:

public partial class Customer
{
    public override void Delete()
    {
    }
}

Notice that this class is not the same as the generated class, but a new partial class created by you. Also notice that you cannot change the return value for the method. You can change the parameters of the method by creating a new overload for it.

This way you’ll be able to change standard implementation on a need-to-change basis while still using your code generation for most of your code. Also, you can regenerate on every build if needed.

Registry-based configuration

noreply@blogger.com (Visual T4) — Mon, 09 Feb 2009 17:17:00 +0000

When you need to design your system’s configuration options, one of the available options is to use the Windows Registry. The Registry has several advantages and disadvantages over an xml-based .config file. Let’s go through them:

Pros
- Windows Standard
- Strongly-typed data
- User Configuration
- Atomicity
- Remote Administration
Cons
- Difficult to manipulate / Bad tools
- Difficult to backup
- May leave unused data behind
- Can’t easily move settings to a different computer

All of this makes registry-based configuration a good choice for two types of configuration: advanced settings (of the type that no normal user should be touching, but an advanced user may need to change) and user settings (such as last position of a window on the screen, last search parameters, etc).

The focus is to do this:

configuration.WindowsPosition.Top = top;
configuration.WindowsPosition.Left = left;

instead of this:

windowPositionKey = Registry.CurrentUser.OpenSubKey(@"Software\MyCompany\MyProgram\1.0\WindowsPosition", true);
windowPositionKey.SetValue("Top", top);
windowPositionKey.SetValue("Left", left);

When using the registry for configuration, it makes code more explicit and simpler, which is always a plus.

So, how does this work? First, the generated class will look like this:

public class WindowPositionKey
{
    private Microsoft.Win32.RegistryKey registry;
    
    public override string KeyName
    {
        get
        {
            return @"WindowPosition";
        }
    }
    
    public WindowPositionKey()
    {
        registry = Registry.LocalMachine.OpenSubKey@"Software\MyCompany\MySoftware\1.0\Configuration\WindowPosition", true);
    }

    public int Top
    {
        get
        {
            return (int) registry.GetValue(@"Top");
        }
        set
        {
            registry.SetValue(@"Top", value);
        }
    }

    public int Left
    {
        get
        {
            return (int) registry.GetValue(@"Left");
        }
        set
        {
            registry.SetValue(@"Left", value);
        }
    }
}

It looks pretty simple, and it can even be made manually. And that is generally true for any code generation task. The point here is quantity. When you have several configuration values in different keys, it makes sense to have a tool generate all that code for you. Also, you can do some fancy stuff. For instance, the key named “Configuration” may have several subkeys (let’s say, WindowPosition and ConnectionProxy for this sample). That code will look like this:

public class RootRegistryKey : RegistryGen.RegistryKey
{
    private Microsoft.Win32.RegistryKey registry;
        
    public override string KeyName
    {
        get
        {
            return @"Configuration";
        }
    }
        
    public RootRegistryKey()
    {
        registry = Registry.LocalMachine.OpenSubKey(@"Software\MyCompany\MySoftware\1.0\Configuration", true);
    }

    public WindowPositionKey WindowPosition
    {
        get
        {
            return new WindowPosition(registry);
        }
    }

    public ConnectionProxyKey ConnectionProxy
    {
        get
        {
            return new ConnectionProxyKey(registry);
        }
    }

    public override IList<RegistryGen.RegistryKey> GetSubKeys()
    {
        IList<RegistryGen.RegistryKey> keys = new List<RegistryGen.RegistryKey>();

        keys.Add(WindowPosition);
        keys.Add(ConnectionProxy);
        return keys;
    }
}

There are a few changes in WindowPositionKey that must be implemented for this to work. First, we need a constructor with a Microsoft.Win32.RegistryKey parameter. Also, it should inherit from RegistryGen.RegistryKey for the GetSubKeys() method. As you add levels of complexity, manually coding the classes gets more complex.

The code generation task, though, is almost exactly the same. We have a GenerateClass() method that receives all the necessary information to generate a single registry class (className, fullName, etc). For the first change, you only need to change this:

public class <#= CleanName(className) #>Key

to this:

public class <#= CleanName(className) #>Key : <#= Namespace #>.RegistryKey

The second change is as easy. Just change this:

public <#= CleanName(className) #>Key()
{
    registry = Registry.<#= GetRootString(registryParts) #>.OpenSubKey(@"<#= fullName #>", true);
}

to this:

internal <#= CleanName(className) #>Key(Microsoft.Win32.RegistryKey registry)
{
    this.registry = registry.OpenSubKey(@"<#= lastPart #>", true);
}

and you’re all set!

If you’re interested, you can review the RegistryGen sample in Visual T4 Code Generator alpha for the full sample.

Creating valid C# identifiers

noreply@blogger.com (Visual T4) — Mon, 09 Feb 2009 01:14:00 +0000

In code generation, it’s very common to need to create a valid identifier. For instance, you may need to create a class name, field, property, method, etc based on the name of a table, a file name, a registry key. The problem with this type of generation is that the rules that make one valid may not apply to the other. For instance, “1st File.txt” is a perfectly valid file name, but it’s not a valid C# identifiers.

Valid identifiers in C# are defined in the C# Language Specification, item 2.4.2. The rules are very simple:

- An identifier must start with a letter or an underscore
- After the first character, it may contain numbers, letters, connectors, etc
- If the identifier is a keyword, it must be prepended with “@”

Applying these rules is pretty straightforward. The following code validates items 1 and 2:

private string CleanName(string name)

{ //Compliant with item 2.4.2 of the C# specification
System.Text.RegularExpressions.Regex regex = new System.Text.RegularExpressions.Regex(@"[^\p{Ll}\p{Lu}\p{Lt}\p{Lo}\p{Nd}\p{Nl}\p{Mn}\p{Mc}\p{Cf}\p{Pc}\p{Lm}]");
string ret = regex.Replace(name, "_"); //The identifier must start with a character if (!char.IsLetter(ret, 0))

ret = string.Concat("_", ret);
return ret;
}

To validate item 3, you can use the C# provider as follows:

ret = Microsoft.CSharp.CSharpCodeProvider.CreateProvider("C#").CreateEscapedIdentifier(ret);

This code will generate an underscore for each space in the identifier. For instance, “c:\1st file.txt” will be generated as “c__1st_file_txt”. If you want to prevent that, change the regex.Replace(name, “_”) with regex.Replace(name, “”). You may also consider capitalizing the first letter after each “_” and then eliminating the “_”.

Finally, you may prefer to have the “keyword” identifiers named with a prefix different from “@”. If that’s the case, use IsValidIdentifier in the CodeDomProvider to know which identifiers are keywords. A full corrected code snippet is below:

private static string CleanName(string name)
{
//Compliant with item 2.4.2 of the C# specification

System.Text.RegularExpressions.Regex regex = new System.Text.RegularExpressions.Regex(@"[^\p{Ll}\p{Lu}\p{Lt}\p{Lo}\p{Nd}\p{Nl}\p{Mn}\p{Mc}\p{Cf}\p{Pc}\p{Lm}]");
string ret = regex.Replace(name, "");
//The identifier must start with a character or a "_"
if (!char.IsLetter(ret, 0)  !Microsoft.CSharp.CSharpCodeProvider.CreateProvider("C#").IsValidIdentifier(ret))
  
ret = string.Concat("_", ret);
return ret;
}

The only problem you may find after this is with duplicated identifiers. “c:x” will generate the same identifier as “c.x”, which may be a problem depending on your particular code generation needs. If you run into this, use a list to store already used identifiers. When you find that an identifier has been used, add a number at the end and check again.

Customizing generated code in ASP.NET MVC

noreply@blogger.com (Visual T4) — Wed, 04 Feb 2009 15:15:00 +0000

Just in case you missed the news, the ASP.NET MVC team is using T4 to generate code (yeah!)
The way they have integrated T4 in their own product is not what we would have expected (they wrote their own T4 host) so we took our Visual T4 Editor and Visual T4 Code Generator bits and added them knowledge about this custom host in order to offer the best possible tooling experience.

You can now see properties of their templates appearing in the Properties window, easily set them and preview how the generation will look like with a single click.

Adrian has recorded a quick video of how this is looking like already, watch it here.

We added this support last week so it is not there yet on the public bits, but I promess it will be there soon!

New Blog About Code Generation With T4 in Visual Studio!

noreply@blogger.com (Visual T4) — Tue, 03 Feb 2009 22:36:00 +0000

While developing the Visual T4 Code Generator edition my team and I are constantly having discussions on how the best code generation tool in earth should look like and also about more “abstract” code generation chores not necessarily related to the product we’re developing.

So it occurred to me (yes, I’m that clever…) that we should take our internal document drafts from our internal wiki and put all this stuff into a blog (of course we will remove the bad language first) to make our plans more public and gather community feedback while we’re at it.

In this new blog you will find posts by Adrian, Joaquin, Jose and me (and if I get lucky I may get other Clarius people to blog too)

Please subscribe and let us know what do you think, thanks!