这一点,非常吸引我,我立即着手实现我自己的XML文档定制工具。因为生成代码的工具我早在一年多以前就已经实现,目前仅仅是按照VS.Net定制工具的要求重新组织一下而已。最终的结果非常理想,又一次证实了VS.Net的确是一个扩展性非常强的工具。不过因为文档不够全面,其间也发生过太多让人恼火的事情。现在把它们一一记载下来。
一、Project DOM
要生成代码,显然需要操作项目,添加或者更新一些项目项。这其中发现VS.NET联机文档中许许多多没有提到的内容以及许许多多的错误让我走了不少弯路。要实现生成代码与依赖文档的同步,需要将生成的项目设为依赖文档的子项。看看.csproj文档中的一个片段:
二、直接调用BaseCodeGeneratorWithSite?
CodeProject上面也有一些使用VS.Net的Custom Tool写插件的一些文章。他们都是非常听MS的,调用MS在GotNotNet上发布的BaseCodeGeneratorWithSite包。当然这个没有问题。但是由于这个包仅仅是一个Sample,所以是没有强名称的,不可能被我的强名称所引用。这样就让我觉得MS这样的发布方式非常不正规。结果自然是直接将源代码拿过来嵌入到我自己的项目中。这与NeoVSTool所使用的方式是不同的,那也是因为NeoVSTool不需要强名称。
三、版本同步
MSDN杂志上的文章上已经讲过了如果部署这些定制工具了。由于部署后需要继续做一些修改,包括对所调用的代码进行修改。如果仅仅只是修改代码而没有修改调用接口,一切都好办。一旦修改了Assembly之间的调用接口就会出错。我知道这是COM互操作方面的原因,因为定制工具插件不是以CLR Hosting方式工作,而是以COM方式工作,而我的定制工具是用C#写的。解决的方式非常简单:在关闭VS.Net后直接删除C:\Documents and Settings\Administrator\Local Settings\Application Data\assembly\dl2下所有的文件夹和文件即可。如果VS.Net更加人性化一点的话,我就可以看到VS.Net当前有哪些Cached的项,并且由我来决定是否清除或更新这些Cached项。