细节决定成败:VS.Net的定制工具机制

因为域名登记的麻烦，Kanas.Net的网站不能正常开张。不过这样正好给了我一个时间来思考和完善。我在设计Scope的时候，发现DataRow其实是一个很好的数据载体，用DataRow来取代数据囊或者用数据囊来实现DataRow有着双重意义：一是自动将DataSet与对象集合的自动同步；另外一个就是将更加节省资源，可以用操作DataSet的方式来操作ObjectSet。在将这个思想与 Teddy在MSN上沟通的时候，他告诉了我一个开源的持久层框架Neo，采用的正是用DataRow作为object的数据载体。我download下来一看，大部分地方设计得比较简陋，我估计只能处理简单的关系。不过有一点思想和我是相同的，就是用一个设计时的XML文档代码运行时的映射配置文档，然后采用VS.Net的 定制工具实现XML文档与自动生成的代码间的同步。

这一点，非常吸引我，我立即着手实现我自己的XML文档定制工具。因为生成代码的工具我早在一年多以前就已经实现，目前仅仅是按照VS.Net定制工具的要求重新组织一下而已。最终的结果非常理想，又一次证实了VS.Net的确是一个扩展性非常强的工具。不过因为文档不够全面，其间也发生过太多让人恼火的事情。现在把它们一一记载下来。

一、Project DOM
要生成代码，显然需要操作项目，添加或者更新一些项目项。这其中发现VS.NET联机文档中许许多多没有提到的内容以及许许多多的错误让我走了不少弯路。要实现生成代码与依赖文档的同步，需要将生成的项目设为依赖文档的子项。看看.csproj文档中的一个片段：

                 < File
                     RelPath  = "Rsm-Biz.erm"
                    BuildAction  = "None"
                    Generator  = "Kanas.ModelBroker"
                    LastGenOutput  = "Rsm-Biz.cs"
                 />
                 < File
                     RelPath  = "Rsm-Biz.cs"
                    DependentUpon  = "Rsm-Biz.erm"
                    SubType  = "Code"
                    BuildAction  = "Compile"
                    DesignTime  = "True"
                    AutoGen  = "True"
                 />

以上Rsm-Biz.cs就是Rsm-Biz.erm的依赖项。这样你不会在你的项目清单中看到Rsm-Biz.cs这个项。令生成的文档自动成为XML文档的一个子项是我最终的目标。对此，Neo的定制工具实现得比较好，那是因为Neo只需要生成一个.cs文件，而我要生成两个(一个是实体类型文档、另外一个是实体词典文档)。最后解决的方案是：只生成一个文档，另外一个文档添加为项目的独立项而不依赖原始XML文档。这样处理得不够好，那是因为目前我能够找到的文档仅仅只是实现IVsSingleFileGenerator接口而不能是IVsMultipleFileGenerator接口，并且IVsSingleFileGenerator的设计思想没有让你操作项目项，仅仅只是生成代码(并且接口方法返回的是byte[]类型)而已，而操作项目项的事情由接口是由调用者来完成的。

二、直接调用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项。

转载于:https://www.cnblogs.com/Barton131420/articles/313833.html