I’m pleased to say that we made a few nice improvements to our T4 text templating engine in Visual Studio 2010 SP1 (you can find the beta here).
Chief among them is resolving an assembly locking issue that more than a few customers have told us has caused them pain.

The most typical cases for folks to run across this are:

  1. when you have a library of code gen helper functions that you want to use from various templates scattered across your solution
  2. when you’re using reflection inside a template to generate one part of your solution from the output of another part.

The problem manifests when you use the <#@ assembly #> directive to load one of your assemblies into a template.  You find yourself stuck next time you try to build your solution.  The template has locked that assembly in memory and when you make a change to update a helper, you get a build error as the locked assembly can’t be overwritten.

In Service Pack 1, we’ve borrowed the ASP.NET assembly shadowing technique, so a temporary copy of your assembly is always loaded rather than the original binary – hey presto, your build should always work now.

Are there any gotchas?

For most folks, the shadowing behavior should just work invisibly.  However, if your template happens to take a dependency on the exact physical path of a referenced assembly (perhaps to sneakily load another assembly in a related directory), then you’re going to find a change in behavior.  You’ll now be getting a path somewhere under %TEMP%, which is probably not what you were expecting.  If it’s not convenient to refactor your logic, you can turn off shadowing by setting a value under the following registry key (the Wow6432Node piece is only for 64-bit OSes):


Set the string value ShadowCopy=false and you’ll be returned to the pre service pack behavior.