在这之前，我写了一系列关于代码生成和T4相关的文章，而我现在也试图将T4引入我们自己的开发框架。在实践中遇到了一些问题，也解决了不少问题。如果你也在进行T4相关的开发，相信你也一定会遇到这些问题。为此，特意将这些问题和解决方案与朋友们分享，希望在遇到这些问题的时候少走弯路。本篇文章介绍的是两个重要的话题：程序集锁定和调试。

目录
一、程序集引用导致的编译问题
二、T4引擎对引用程序集的锁定
三、Debugger.Break导致VS 2010的Crash
四、在Debugger.Break之前加上Debugger.Launch

一、程序集引用导致的编译问题

如果你看过我上一篇文章，你应该知道我们至少具有解决T4模板的程序集引用的五种方案，在这里我们采用的是VS宏的解决方案，即将引用程序集文件的路径设置成通过$(SolutionDir)表示的解决方案目录的相对路径。HelloWorld.tt定义如下，引用的程序集路径为Lib项目在Debug模式下编译生成的目录（$(SolutionDir)LibBinDebug）。

<#@ template debug="true" hostSpecific="true" #>

<#@ output extension=".cs" #>

<#@ Assembly name="$(SolutionDir)LibBinDebugArtech.T4Template.Lib.dll" #>

using System;

{

    static void Main()

    {    

        <# foreach( var person in Artech.T4Template.HelloWorldHelper.GetPersons())

        {#>

        Console.WriteLine("Hello,{0}!","<#=person#>");    

        <# } #>

    }

}

当你保存该T4模板，T4引擎将触发并进行代码生成工作，但是此时如果你试图编译被引用（实际上是生成的程序集被引用）的Lib项目，将会出现如下所示的编译错误。错误信息为：“Unable to copy file "objDebugArtech.T4Template.Lib.dll" to "binDebugArtech.T4Template.Lib.dll". The process cannot access the file 'binDebugArtech.T4Template.Lib.dll' because it is being used by another process.”，即之前生成的程序集正在被使用，所以不能将生成的程序集拷贝到编译目标目录下。

二、T4引擎对引用程序集的锁定

实际上这个程序集的使用者正是T4引擎。出于提高性能考虑，T4引擎在进行基于代码生成的模板转换（Template Transformation）的时候，会始终重用同一个AppDomain。由于该AppDomain不会自动卸载，这就会导致该AppDomain始终锁定所有被它加载的程序集。如果我们需要释放程序集，我们不得不重启VS。但是，对于T4模板的开发调试阶段，这种通过重新启动VS的方式去释放程序集以确保我们的项目能够成功编译是不能接受的。

那么，是否有一种解决方案既能够确保T4引擎能够进行正常的模板转换，又能避免它强行锁定引用程序集呢？如果你采用T4 ToolBox，你可以通过<#@ VolatileAssembly…#>这个指令轻松地解决这个问题。下面的T4模板中，我们将通过<#@Assembly…#>指令的程序集引用方式替换成了<#@ VolatileAssembly…#>（<#@ VolatileAssembly processor="T4Toolbox.VolatileAssemblyProcessor"? name="$(SolutionDir)LibBinDebugArtech.T4Template.Lib.dll" #>），我们的Lib项目在任何时候都可以自由地编译。

<#@ VolatileAssembly processor="T4Toolbox.VolatileAssemblyProcessor"  name=创建一个新的程序集拷贝。


三、Debugger.Break导致VS 2010的Crash

VS和一些T4编辑器虽然给了基本的智能感知支持，但是在绝大部分我们相当于在编写纯文本的脚本，所以对于一些比较复杂的模板转换逻辑，我们需要通过Debug的方式去发现一些无法避免的问题。关于T4模板的Debug，你Google一下会搜出一大堆。在这些“大众化”的Debug解决方案中都包含两点：



在<#@ template…#>指令中将debug属性设置为true； 

  
在需要设置断点的地方执行Debugger.Break方案 

按照这两点，我们改写了我们的T4模板，在foreach语句之前加上<# Debugger.Break(); #>，并通过<#@import…#>指令导入System.Diagnostics命名空间。我不知道在VS 2008下这种解决方案是否可行，但是如果你使用的是VS 2010，这肯定会导致整个VS的崩溃。当你保存TT文件的时候，如右图所示的对话框弹出来，随之伴随整个VS的Crash。


  
<#@ import namespace="System.Diagnostics" #>

class HelloWord

{

    {    

        <# Debugger.Break(); #>

}

四、在Debugger.Break之前加上Debugger.Launch

为了避免Debugger.Break导致的VS崩溃，只需要在之前多加一句代码即可，既Debugger.Launch。为此我们对我们的T4模板略加修改

        Debugger.Launch();

        Debugger.Break();

                <#} #>

}

现在如果你保存该TT文件，VS会弹出如下一个对话框让你选在是否进行Debug。如果需要进行Debug，选择“Yes,debug devenv.exe”。

然后创建一个新的VS实例，或者选择已经打开的VS程序进行Debug，这个对话框我们应该很熟悉。最后程序将会执行到我们设置的断点（Debugger.Break），我们就可以像Debug普通托管程序一样对T4模板进行Debug了。实际上，你也可以直接通过Attach进程的方式进行Debug,不过这里的进程就是VS的进程devenv.exe。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!