把SD 的源码工程转换到VS 的工程，在工程中查找 Application.Run()方法，在StartWorkbenchCommand 类的 Run 方法中发现：
Application.Run(f); ???
这里的 f 应该是SD 的主界面，再看f 的定义—也在StartWorkbenchCommand类的Run方法中：
Form f = (Form)WorkbenchSingleton.Workbench;
从这里看来，WorkbenchSingleton 是一个 Form 的扩展，不然那不会用到强制转换 J ~~
在由WorkbenchSingleton这个名字看来，它是一个Singleton模式的实现！嗯，是时候该去看看WorkbenchSingleton了。
哎？？？不好！！！！ WorkbenchSingleton原来只是一个普普通通的类而已并不是我想的那样！！ 但是怎么会强制转换成功呢？？问题一定处在WorkbenchSingleton的Workbench属性上，赶快看看~~~~~~
不对啊Workbench属性只是简单的返回一个IWorkbench的实例，难道~~~~ 再看看IWorkbench！也不是~~~~~~郁闷！！！！！！
看来只有强攻了！！！在当前文件查找WorkbenchSingleton在InitializeWorkbenchCommand类的Run()方法中发现：
DefaultWorkbench w = new DefaultWorkbench();
WorkbenchSingleton.Workbench = w;
这下有戏看了，呵呵~~ 看来DefaultWorkbench才是我想要的东西！！
转到DefaultWorkbench发现，DefaultWorkbench果然不假，DefaultWorkbench继承Form和IWorkbench。但是现在有个问题：怎样保证InitializeWorkbenchCommand.Run()一定在StartWorkbenchCommand.Run()之前调用？？如果得不到保证，那么会造成初始化失败，整个系统也将玩完~~~~~ 我想这因该是在插件文件中做的手脚，要不然你看那SD的工具条怎么会是按照顺序排列：先是文件菜单，再是编辑菜单。。。。。？？？？先不管先看看DefaultWorkbench，看看能找到什么有趣的东东！！
先直观地看，在VS.Net的窗体设计器中看来DefaultWorkbench只是一个Form上面什么都没有，看来SD的菜单栏，工具栏，面板……等等真的都是从外部挂接上去的，够牛的~~~但是怎么挂接上的还没弄清楚，郁闷~~~~~~~~~~再来看看DefaultWorkbench的代码吧！
不看不知道，一看吓一跳，DefaultWorkbench中有34个方法，5个属性，14个成员变量和3个事件，格式化过的代码667行~~~~有的看了，不过我可能可以找到重点，也就是我想要的东西！！！
你看看我说的没错吧，这不在DefaultWorkbench中有这么几个成员变量和一个方法：
readonly string mainMenuPath = “/Workbanch/MenuItems”;
public CommandBarManager commandBarManager = new CommandBarManager();
public CommandBar TopMenu = null;
public CommandBar[] ToolBars = null;
void CreateMainMenu()
{
TopMenu = new CommandBar(CommandBarStyle.Menu);
CommandBarItem[] items = (CommandBarItem[])(AddInTreeSingleton.AddInTree.
GetTreeNode(mainMenuPath).BuildChildItems(this)).ToArray(typeof(CommandBarItem));
TopMenu.Items.Clear();
TopMenu.Items.AddRange(items);
}
嗯~~~~~~~~ 现在看看，把上面这段代码贴到自己的程序中，应该也是可以的吧！！祈祷ing!!!
打开我的项目，在MainForm中粘贴好代码，编译——通过，兴奋ing,运行——抛出异常，郁闷ing！！！
仔细看看异常信息，好像是说找不到/Workbanch/MenuItems路径，更加郁闷了，/Workbanch/MenuItems路径不是在Core中定义的吗？？难道没有？？？
用查找工具找遍Core项目，竟然真的没有找到 ”/Workbanch/MenuItems”
