Dela via


VS2010 SP1: T4 no longer locks assemblies in memory

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):

HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Microsoft\VisualStudio\10.0\TextTemplating

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

Enjoy…

Technorati Tags: T4,Visual Studio 2010 SP1,Assembly Locking

Comments

  • Anonymous
    December 10, 2010
    Any work being done to replace code nuggets (<#, <#%, <#=)  with a more Razor like syntax?

  • Anonymous
    December 11, 2010
    Superb. Is there a fix or work around for the locking issue for Visual Studio 2008?

  • Anonymous
    December 12, 2010
    Any news about supporting T4 inside the editor?

  • Anonymous
    December 12, 2010
    So Fl: Your best bet on 2008 is the VolatileAssembly directive that's part of the T4Toolbox community project. Tony: I'm not seeing a way to generalize Razor at present cos it relies on knowing the generated language to distinguish.  If you'[re generating C# from C# (T4's most common use case right now) that's pretty hard.  I'll be spending time noodling with the Razor folks to see what we can come up with though.

  • Anonymous
    December 12, 2010
    Thanks!  This will definitely help in a couple of places where this was a blocking issue.  

  • Anonymous
    December 13, 2010
    Is this basically the same as the VolatileAssembly directive described here: www.georgemk.com/.../t4-template-reference-to-frequently.html I'm using a derivative of that, modified to also copy .pdb files.  Works well.