The latest update to my template for generating LINQ to SQL classes from DBML is now available.

If you want to customize the LINQ to SQL code generation phase in your project without additional tool dependencies this could be what you’re looking for.

New in this version

• Inheritance - generates subclasses with all properties and code mappings.
• VB.NET - CSharpDataContext.tt is joined by a VB.NET emitting VBNetDataContext.tt.
• DataContract SP1 – additional mode to emit SP1-compatible DataContract serialization via Roger Jennings.
• Composite keys – both as the primary key and as a foreign key in an association.
• Type attributes – the data context and entity types can now be sealed or abstract as well as public, private, protected, internal or protected internal.
• Associations – prevents foreign key values changing once the object association is made and updates parent side of one-to-many associations.
• Stored procedures – generates method wrappers and associated methods to facilitate insert/update/delete with concurrency support.

Functionality compared to designer

A primary goal in developing the template was to allow for easy switching between the template and the LINQ to SQL designer so things are very similar.

Missing

• Comprehensive sanity checking on the DBML.
• The Custom Tool Namespace and project namespaces are not pulled in when the DBML namespaces not specified.

Fixed

The designer has a few bugs which helpfully this template doesn’t suffer from.

• Modifying a table via a stored procedure using original values for concurrency will throw ChangeConflictException and not silently fail.
• Protected internal virtual property doesn’t forget to be virtual.
• Checks all associations based on a foreign key are not loaded before allowing change and not just the first one.

Improved

• Fully customizable with full source.
• Serialization mode to support DataContract improvements in .NET 3.5 SP1
  To use uncomment the line // data.Serialization = SerializationMode.DataContractSP1; in xDataClasses.tt
• CanBeNull attribute generated for value types (useful when working with metadata).

Source compared to designer

The designer generated code can be difficult to read and isn’t well suited to template generation so the output from this template is different in a number of ways:

Sequence

Everything related to a column mapping – the storage variable, event signatures, attribute and the property itself – is batched together so it can be hit with a single loop making the template shorter and easier to work with.

#regions

Opinion may be divided on the usefulness of #regions in your own code but for code generation of large files I found it invaluable. There are regions for the logical parts of the data context and within each entity such as construction, column mapping, associations and serialization.

Style

The code generated should be a little easier to follow – if/else ordering, no redundant casts or extra brackets etc.

Namespace

I don’t believe adding “this” everywhere or fully qualifying attributes and exceptions makes things easy to read. I realize this might cause some name conflicts for some people but it is easy to change yourself and means the code is shorter and easier to work with for the majority.

Getting started

Although I work on the LINQ to SQL team this template should be treated as a third-party sample and is not supported by Microsoft.

Download LINQ to SQL for T4 v0.72 (12 KB)

1. Add the L2ST4.tt and either CSharpDataContext.tt or VBNetDataContext.tt to your project
2. Rename the xDataContext.tt to match your DBML file but with .tt extension instead of .dbml
3. Set the Build Action to None for both the DBML file and for L2ST4.tt

Note that the template will only regenerate when it has been changed so use Run Custom Tool from the template’s right-mouse button menu in Solution Explorer when you’ve changed the DBML.

If you wish to switch back to using the designer code then set the DataContext.tt Build Action to None and the .dbml file Build Action to Compile.

Customization

The template runtime built into Visual Studio 2008 is called T4 and requires no additional tools however if you do a lot of editing you might want to install the Clarius T4 Editor for syntax highlighting and also check out the treasure trove of T4 material that is Oleg Sych’s blog.

The template is simple to follow, it loads the DBML file as an XML document then uses LINQ to XML to instantiate wrapper objects over the elements. This gives you a simple way to change default naming and behavior while making the template simpler to work with.

Let me know how you get on by leaving a comment here.

[)amien

A newer version of this LINQ to SQL template is available.

The topic of modifying the code generation phase of LINQ to SQL comes up quite often and the limited T4 template I published here last month was good at showing the potential but wasn’t a practical replacement for the code generation phase.

I am please to make available the next version, which now…

• Runs from the DBML therefore keeping the designer in the loop
• Generate all the attributes for columns and tables including UpdateCheck, IsDbGenerated etc.
• Supports associations including those with a foreign key
• Generates appropriate attributes and code for both serialization modes

In short it generates code that is now functionally equivalent to SQL Metal with the following caveats:

• C# only – VB.NET can be added if there is some interest
• Stored procedures – not yet supported
• Table inheritance - incomplete
• DBML changes require you open and re-save the T4 template so it regenerates the code
• Unidirectional serialization requires you add System.Runtime.Serialization to your project references (thanks Roger!)

Download LINQ-to-SQL-T4-0.3.zip (5 KB)

To use the template :

• Extract the archive and add the two files to your project
• Right-click on the L2ST4.tt file, choose Properties and set the Custom Tool to blank
• Rename DataClasses1.tt to the same name as your DBML file (but keeping the .tt extension) and open it
• Click save and watch a freshly generate C# DataContext pop out
• Switch off the LINQ to SQL designer generated C# by either setting the Custom Tool on the DBML to blank or setting the Build Action on the generated C# to None.

L2ST4.tt contains a lightweight wrapper around the DBML which is processed using LINQ to XML making the template easier to work with and providing a central for naming rules etc.

This code should be treated as a sample and hasn’t received much testing yet so feel free to leave comments or feedback here.

Some places you could take this template:

• Generate an interface for your data context to improve mocking
• Alternative naming and defaults
• Splitting output into multiple files
• New languages

The guys over on the AnkhSVN team have acquired new members and burnt the midnight oil to deliver a great 2.0 release with:

• Subversion 1.5 merge & tracking support
• Wizards to help step through tasks like merging
• Now a source code control package (SCC) for smoother, faster integration
• Pending changes window providing change summary
• Easier to get up and running with the source
• Property editor
• Automatic update check

Despite all these great features it's absolutely free and still works with older versions of Subversion and both Visual Studio 2005 and 2008.

What are you waiting for, go download AnkhSVN 2.0 already!

[)amien

Microsoft's MVC for ASP.NET is still under serious development but at the moment support for localization is a little weak. Here's one approach that works with the 04/16 source-drop.

LocalizingWebFormViewLocator class

This class helps by trying to identify language-specific versions of views, user controls and master-pages where they exist, falling back to the generic one where necessary.

public class LocalizingWebFormViewLocator : ViewLocator
{
	public LocalizingWebFormViewLocator() : base()
	{
		ViewLocationFormats = new[] { "~/Views/{1}/{0}.{2}aspx", "~/Views/{1}/{0}.{2}ascx",
			"~/Views/Shared/{0}.{2}aspx", "~/Views/Shared/{0}.{2}ascx" };
		MasterLocationFormats = new[] { "~/Views/{1}/{0}.{2}master", "~/Views/Shared/{0}.{2}master" };
	}

	protected override string GetPath(RequestContext requestContext, string[] locationFormats, string name)
	{
		string foundView = FindViewLocation(locationFormats, requestContext, name, CultureInfo.CurrentUICulture.Name + ".");
		if (String.IsNullOrEmpty(foundView))
			foundView = FindViewLocation(locationFormats, requestContext, name, "");
		return foundView;
	}

	protected string FindViewLocation(string[] locationFormats, RequestContext requestContext, string name, string cultureSuffix)
	{
		string controllerName = requestContext.RouteData.GetRequiredString("controller");
		foreach (string locationFormat in locationFormats) {
			string viewFile = string.Format(CultureInfo.InvariantCulture, locationFormat, name, controllerName, cultureSuffix);
			if (HostingEnvironment.VirtualPathProvider.FileExists(viewFile))
				return viewFile;
		}
		return null;
	}
}

Using the class

To use the class you must set the ViewLocator on the WebFormViewEngine to a new instance of LocalizingWebFormViewLocator (either in the constructor or in your common controller subclass) and ensure that any master pages are specified on the RenderView calls to ensure the localized version is detected.

public class HomeController : Controller
{
	public HomeController() {
		((WebFormViewEngine)ViewEngine).ViewLocator = new LocalizingWebFormViewLocator();
	}

	public ActionResult Index() {
		return RenderView("Index", "Site");
	}

	public ActionResult About() {
		return RenderView("About", "Site");
	}
}

You must also ensure the thread's current UI culture is set. The easiest way to do this is to specify the following in your web.config file's system.web section which will pick it up automatically from the user's browser settings via the HTTP language-accept header.

<globalization responseEncoding="UTF-8" requestEncoding="UTF-8" culture="auto" uiCulture ="auto" />

Then all you need to do is create views and master pages that have the culture name appended between the name and .aspx, e.g:

/Views/Home/Index.aspx (common fall-back for this view)
/Views/Home/Index.ja.aspx (Japanese view)
/Views/Home/Index.en-GB.aspx (British English view)

/Views/Shared/Site.Master (common fall-back for this masterpage)
/Views/Shared/Site.ja.Master (Japanese masterpage)

Caveats

There are some limitations to this solution:

Only primary language is attempted

Only the user's primary language specified in their browser is attempted despite browsers having a complete list in order of preference. Ideally we would scan down this entire list before giving up but that would need more code and there is the issue of whether scanning for several languages across several folders could be too much of a performance hit.

Specifying the masterpage on RenderView

It would be nice if you didn't have to specify the masterpage on renderview but if you do not then the ViewLocator never gets called to resolve the actual masterpage address. This may be for backward compatibility within MVC.

Creating files in Visual Studio

Visual Studio 2008 seems to get a little confused if you create a Index.ja.aspx or Site.ja.aspx - whilst the files are created okay the names are not and you will need to adjust the class names to ensure they don't conflict and make sure the opening declaration on the .aspx file points to the right code-behind page and inherits from the correct name.

Of course the beauty of this approach is you can mix-and-match using dedicated views where required and localising labels in the fall-back view when it isn't.

[)amien