要介绍VSXTra项目不是一个简单的事情。 而且要在上面进行扩展，删减就更不容易。 源码分析的资料几乎没有，可怜的几个示例项目，相较而言，英文已经不是阻碍我前进的步伐了。 本篇只是简单的分析，对于已经使用到的几个接口或类型进行说明，不可能完整的，从全局去介绍VSXTra项目，建议读者还是去啃LearnVSXNow!系列，其中有不少的篇幅在介绍这个项目。

PackageBase

不管是CommandHandlerBase还是PowerCommands，都是简单的封装而已，但是VSXTra里的PackageBase并没有继承于Package，实际上它只是实现了几个接口。

这里首先要说的是IVsPackage这个接口。 VS2010使用MEF做扩展，实现了IVsPackage接口的会首先调用其SetSite方法，其实从PackageBase的InternalInitialize方法就可以看出两个调用的地方，另一个是IVsShellPropertyEvents的OnShellPropertyChange方法。 而并不是VS已启动就会加载VSPackage的，而是当你第一次使用该VSPackage的功能时才会加载，要实现自动加载VSPackage，你需要在你的VSPackage上标注自动运行才行，[ProvideAutoLoad(UIContextGuids.SolutionExists)]大概的意思就是，当解决方案存在的时候，该VSPackage自动加载。 这里没有使用VSXTra里所说的Typed GUID，而是直接使用UIContextGuids的常量定义，其实我现在仍然不知道这样写有什么好处。 之后在用户启动VS，打开某个解决方案时，IVsPackage的SetSite方法才会触发。 而IVsShellPropertyEvents的OnShellPropertyChange方法与IVsPackage的SetSite方法有所区别，SetSite对于每个VSPackage只会加载一次，而OnShellPropertyChange是当用户切换VSPackage时会触发，且里面那句经典的判断，能隔绝大多数情况的触发：

if ((int)__VSSPROPID.VSSPROPID_Zombie == propid)
{
    if ((bool)propValue == false)
    {
    }
}

我已经不记得我如何得出以上结论，当然你肯定能想到，那都是很艰难很艰难的。

Command

我实在不想过多介绍PackageBase，这里借道Command缓冲缓冲。 当初如何实现一个Command以及PowerCommands对命令的简单封装我这里就不再啰嗦了，看看VSXTra里对Command的处理。

[CommandExecMethod]
[CommandId(GuidList.guidVSXtraMenuCommandCmdSetString, 
    CmdIDs.cmdidVSXtraMenuCommand)]
private void MyMenuCommand()
{
    VsMessageBox.Show("Inside VSXtra Menu Command");
}

这是VSXTra里一个经典的实现方式，对于界面关系极少的VSPackage很有用，不需要其他任何代码，只在Package里加一个方法，标注几个Attribute即可，不可谓不方便。 可惜我的项目中，多个VSPackage共同组合，Command每个VSPackage中一大堆，即使使用分部类也过于麻烦。

[Guid(GuidList.guidCompileCmdSetString)]
public partial class BuildTradeGroup : CommandGroup<CompilePackage>
{
    [CommandId(PkgCmdIDList.cmdidBuildTrade)]
    public sealed class BuildTradeCommand : MenuCommandHandler
    {
        protected override void OnExecute(OleMenuCommand command)
        {
        }
    }
}

VSXTra的示例项目中有这么一个例子，介绍了这种PowerCommands的分离方式。 可以看出，不同之处就是原本的CommandId是两个参数，需要传CmdSet的Guid，还要传Cmd的Id，而这里使用了CommandGroup去将其分类，这样以来确实看起来逻辑清楚，怎奈我还是想要每个命令一个文件的形式去做，所以这里使用了分部类，但是Guid只能在一个上面标注让我很是不爽，且每次新建命令，都忘了修改CommandId让人很是抓狂。 我在UnitTest专门对此进行检测。

再回首PackageBase

其实在VSXTra中，实现Command和PowerCommands中没有多大区别，关键代码就在PackageBase中。 在上面介绍的SetSite和OnShellPropertyChange方法中触发了InternalInitialize方法，其中又触发了BindCommandHandlers方法，而从传过来的程序集中就能看出其实现原理。 其实平淡无奇，只是遍历程序集中所有类，然后找出需要的类，通过Activator.CreateInstance方法实例化，进行相应的操作。 所以这里我扩展了对SolutionListeners和Configuration的初始化。 当然，PackageBase不只是对Command做了简化，比如说IVsPersistSolutionOpts接口就是对OptionPage进行的操作，而IVsToolWindowFactory接口就是对ToolWindow进行的操作。

Package中比较重要的一个方法GetService，其实是对IServiceProvider的GetService实现，期间嵌套了对IOleServiceProvider（Microsoft.VisualStudio.OLE.Interop.IServiceProvider）的QueryService实现。 读GetService很具挑战力，太过费心费力，这里不想继续了。

IServiceProvider接口是VSX开发中一个比较重要的接口，所以在PackageBase中对其做了全局实例，包括弹出框、DTE对象等一系列都需要使用IServiceProvider去获取。

PackageBase作为对Package的替代者，很多人只意识到继承关系，而其他诸如静态方法的实现却仍然使用Package提供的。 几乎所有Package实现的东西，PackageBase都能实现，且实现的更为方便快捷。 有一个简单而明显的例子，就是GetGlobalService方法，PackageBase对其做了三个重载，这也是在VSXTra项目中大量出现的一种重载方式，规范了很多调用方法。当然，不排除对于新接触的人各种疑惑。

前面简单的介绍了VSXTra开源框架，至于深究，还是算了，我只是祈祷我做的修改和扩展不会出错就好，而ProjectSystem项目更让我畏惧三分。 使用VSXTra确实能简化开发，而且更重要的是，在参考资料如此少的情况下，这么一个框架给我提供的就不只是简化开发而已，更多的是对VSX开发的进一步认识。

后续文章中可能会继续介绍VSXTra框架，分析其中一些具体的实现方式，以及我对VSXTra框架做的一些扩展。

VSX-4 VSXTra