Visual Studio .NET 的 Google

Visual Studio .NET 的 Google

 

发布日期： 7/28/2004 | 更新日期： 7/28/2004

John Robbins

下载本文的代码： Bugslayer0311.exe (669KB)

为了最高效地完成软件开发，关键是尽可能以最快的速度找到编码方面难题的答案。 当我们开始在 Internet 上搜索那些答案时，毫无疑问，归根结底都要使用 Google。 Google 不仅是最全面的搜索引擎，而且也是最快的搜索引擎。

了解到这一点之后，我不禁感到惊讶，居然只有极少数开发人员会花时间阅读 Google 的文档。 对于您提出的任何查询，Google 都可以返回大量链接。 为了使搜索做到真正高效，秘诀在于，告诉 Google 如何确定搜索的范围，这样您就可以得到 100 个最合适的答案，而不是一百万个毫无意义的结果了。

为了更好地确定搜索的范围，Google 为特定主题建立了特殊的搜索组，包括 Microsoft、Apple Macintosh、BSD、Linux 和美国政府的信息。例如，当从 http://www.google.com/microsoft.html 进行搜索时，您的查询将只在主要包括 Microsoft 内容的站点上运行。 要使用这些特定站点，请用浏览器访问 http://www.google.com/options/specialsearches.html。

此外，您还可以将搜索限制到单个站点。 在搜索编辑控件中输入 "site:"（不带引号）， 后面跟着您要搜索的站点，也可以使用高级搜索页。 例如，要搜索 MSDN Online，请在搜索字符串之前输入 "site:msdn.microsoft.com"。

我非常希望您阅读完整的 Google 搜索文档，该文档位于 http://www.google.com/about.html。 您在开发方面的所有问题都可以在 Internet 上找到答案，但如果没有巧妙的搜索，您永远也找不到那些答案。

先不说别的，单单是我提供的两个 Google 搜索技巧就值得您仔细阅读这篇专栏文章，更何况还有更多的提示技巧呢。 因为我基本上是个懒人，所以不喜欢每次有问题时都要打开浏览器，在 Google 的搜索框中键入 "site:msdn. microsoft.com"。 我希望单击按钮就能够进行刚刚提到的 Google 搜索，以及 Usenet 组、Google 目录还有从 Visual Studio .NET 内进行的整个 Web 搜索。 可以这么说，它就是一个无所不能的出色的小外接程序。 要预先看一下这个外接程序的外观，请参见图 1。

图 1 Google 外接程序

我原来的想法是，本专栏文章应该短小实用，为您提供一个搜索 Internet 的实用工具。但是，我在这个外接程序模型中遇到了一些非常奇怪的限制，因此不得不花费相当大的精力来突破这些限制。 我希望能因此使您在开始开发自己的外接程序时省去许多麻烦（并且不用在计算机面前老是骂人）。

对于本专栏文章的其余部分，我假设您已经很熟悉外接程序如何工作以及如何编写外接程序这方面的基础知识。 如果您希望赶上我的进度，请阅读 2002 年 1 月的 Bugslayer 专栏文章或 Visual Studio .NET 文档。

本页内容

	来自地狱的 CommandBars
	F1 监视？
	真正的 Google 外接程序
	实现要点
	总结
	提示

来自地狱的 CommandBars

我原来的设计是，将整个 Google 外接程序放在一个工具栏中。 第一个控件是一个组合框，它通过保存过去的搜索来模仿现有的 Find 组合框。 接下来的控件是从组合框接受文本的所有按钮。 这些按钮的顺序是： 搜索 MSDN Online、搜索 Microsoft 站点、搜索 Google 组、搜索 Google 目录、搜索 Web。

Visual Studio 中工具栏和菜单的类型为 CommandBars。 CommandBars 的文档表明，它们来自 Microsoft Office DLL，即 MSO.DLL。Visual Studio .NET 文档没有直接讨论 CommandBars，只是引用了 Microsoft Office 文档。 这种做法带来的问题是，该文档暗示 Visual Studio .NET CommandBars 的功能与 Office CommandBars 相同，但正如您稍后将看到的那样，它们并不一样。 这意味着您得自己搞清楚 Office XP Developer 文档中的 Visual Basic for Applications 示例。

由于我已经拥有了一些使用 Visual Studio .NET CommandBars 的经验，我意识到我的第一个任务应该是创建一个该组合框的原型，以便可以找出它的局限性。 我怀疑这只是外接程序模型的问题，而 Visual Studio Integration Program (VSIP) 模型可能解决了这方面的问题，但我还没有去证实，主要是因为编写 VSIP 代码需要涉及更多内容，而且无法编写成托管代码。 既然大多数读者都打算成为这种外接程序的忠实拥踅拥护者，我们就应该最终找到究竟有哪些局限。

在本月专栏文章的源代码中，您可以看到我用 Visual Basic .NET 编写的名为 ToolBarTest 的 CommandBar 测试应用程序（请参见本文开始部分的链接）。 您可能希望编译和安装该外接程序，这样您就可以自己看出这些局限了。 通过运行作为项目一部分的 TOOLBARTEST.REG 文件即可完成安装。

添加组合框的过程非常简单，只是调用工具栏中的 Controls 属性的 Add 方法。 正如您在可下载的代码中看到的那样，只有在调用 IDTExtensibility2.OnConnection 方法且 ext_ConnectMode 参数为 ext_cm_UISetup 时（该参数说明外接程序被要求执行其初始用户界面安装），我才会创建和填充工具栏。 因为用户界面安装只会执行一次，所以在以后加载该外接程序时，我会找到这个已经创建的工具栏，然后使该工具栏处于活动状态。

在第二次运行时，查找工具栏的代码运行正常，但我在工具栏的第一个位置创建的组合框却不见了。 我感到非常困惑，我想它可能处于隐藏状态，因此我需要对它取消隐藏。 我很快编写了一个宏来枚举工具栏上的控件，发现我添加的组合框确实不见了。 我将 CommandPreload 选项重置为 1，强制外接程序用户界面初始化并重新运行 Visual Studio 之后，组合框又出现了。 但不幸的是，重新启动仍然会使组合框丢失。

对 CommandBars 有一些使用经验的读者可能怀疑我在调用 CommandBars.Controls.Add 时是否错误地将 Temporary 参数设置为 true。正如您看到的那样，我确实是将组合框作为非临时控件添加的。 此时，我意识到是外接程序模型出现了问题，它似乎只能保存按钮。 我的解决办法是，在 IDTExtensibility2.OnConnection 方法中正常加载外接程序时，我找到了该外接程序的 CommandBar，然后用手动方式将组合框插入到了工具栏上的第一个位置。 您可以看到 ToolBarTest 内 Connect.AddComboBox 中的代码。

虽然工具栏不能保存组合框显得有些奇怪，但至少您有了一个能部分解决问题的办法。 真正的问题在于这种情况：工具栏可见，但启动时没有加载外接程序。 在这种情况下，工具栏不会正确显示。 您可以在 ToolBarTest 外接程序中看到这个过程。虽然您可以告诉用户确保能够始终加载外接程序，但实际上有时会出现不同的情况。 如果您运行 ToolBarTest，则会发现，如果外接程序没有加载，只要单击一个按钮，组合框就会像变魔术一样出现，因为那是外接程序在第一次添加组合框。 从用户界面的角度来看，这并不理想。

由于我没有想出任何关于组合框消失的解决方案，我将希望寄托在了处理来自组合框的 CommandBarComboBox.Change 事件上，这是它唯一支持的事件。 我挂接了该事件，向组合框添加了几个项，然后开始测试。 从代码中可以看出，只要触发 Change 通知，就会弹出一个消息框，通知您发生了该事件，并会显示组合框中的文本。 此外，我还挂接了 IDTCommandTarget.Exec 方法，该方法也会弹出一个消息框，该消息框具有一个不同的标题，也会包括组合框中的文本。 起初看上去一切顺利，我可以用鼠标从下拉组合框选择一个项，也能正常触发 CommandBarComboBox.Change 事件。

现在我必须看看，在组合框编辑控件中输入各项内容时会发生什么事情。 我发现正确输入一个新值并按 Enter 键之后会弹出 Change 通知 － 这是正确的响应。 同样，单击任何按钮都会导致对相应的测试弹出执行消息框。 但是从这以后，情况就急转直下。

因为我想模仿标准工具栏的 Find 组合框，我输入了一些新的文本，然后立即单击了其中一个按钮。 糟糕的是，输入的文本被去掉了，取而代之的是组合框列表中的第一项！ 这看起来肯定像一个 bug，并且说明 Visual Studio .NET 外接程序模型不希望您在 CommandBars 中使用组合框。 不管我用什么办法，都无法使组合框停止更改文本。 更糟的是，更改组合框中的文本并在工具栏之外的任何地方进行单击也会导致输入的文本被替换，同时会对替换的文本发出 Change 通知。

执行一个 Spy++ 操作后，我看到了标准工具栏 Find 组合框和我的工具栏的组合框编辑控件的 Windows 过程。 我的组合框来自 MSO.DLL，即 Office XP 控件 DLL，而 Find 组合框编辑控件来自 VSBROWSE.DLL，奇怪的是，它是 Web 浏览包。 因为 Find 组合框表现正常，其 Windows 过程来自另一个不同的 DLL，很显然，默认的组合框不是很正确。

虽然可编辑组合框无法正常使用，但直接选择组合框没什么问题，因此我开始了一项试验，看看是否能挽救我关于单个工具栏的想法。 因为 Office XP Developer 文档指出，实际上您可以在 CommandBar 上放置许多不同的控件，于是我尝试了使用不同的 MsoControlType 控件。 我发现，除了按钮或组合框，CommandBars.Controls.Add 总是会在您试图添加控件时引发异常。 我原来还以为也允许添加编辑控件呢。

最后，如果不大量创建子类，外接程序只能在工具栏上正常添加按钮和选择组合框。 我对此感到很失望，因为我认为工具栏上的可编辑组合框有许多用处。 令人庆幸的是，至少我经历了 CommandBar 的所有挫折，因此我确切地了解了可以在上面添加哪些控件，不能添加哪些控件。

返回页首

F1 监视？

我当时想暂时进行一些其他工作，所以我想，如果可以将我的 Google 外接程序命令分配给一些键，那么就可以直接在编辑器中使用 Google 搜索了。 最终的情况是，我是否能用某种方式可在您编辑时出现 Dynamic Help 窗口所显示的那种列表。 通过这种方式，我的外接程序会搜索 Google，查找与通常的 F1 命令所使用的完全一样的文本。 此外，我也不必从编辑窗口解析当前关键字。

在浏览了 MSDN Help 之后，我发现 "Adding Custom Links to the Dynamic Help Window" 一节所包含的信息非常有用。 在有关如何对添加到动态帮助中的帮助主题进行调试的部分中提到了一个有趣的话题，即您怎样才能知道 Visual Studio .NET 如何搜索主题。 在注册表项 HKEY_CURRENT_USER/Software/Microsoft/VisualStudio/7.0/Dynamic Help 中，添加一个新的字符串值 "Display Debug Output in Detail"，然后将它的值设置为 "YES"。 重新启动 Visual Studio 后，您会在 Dynamic Help 窗口中看到其他的一些详细信息，如图 2 所示。

图 2 更多详细信息

当您将光标移到不同的区域时，您会发现 Active Context 下的值会根据光标的移动而变化。 实际上，在 IDE 周围进行单击看会显示什么值是很有趣的。

在浏览 Visual Studio .NET 自动化文档时，我无意间看到了 ContextAttribute 集合，它包含了与 Dynamic Help 窗口中的全局上下文或窗口上下文相关联的所有属性。 当我随便使用某些宏来访问各个 ContextAttribute 值时（如图 3 中显示的值），我发现 DTE 对象包含的是光标在源窗口时的关键字列表。

我计划通过编写外接程序命令来查看一下这个活动的窗口。 如果该窗口不是源代码窗口，我就会使用正常的 Help.F1Help 命令了。 当我对多个项目运行类似图 3 中所示的宏，以便获得关于 ContextAttribute 集合中模式的信息时，我发现了两个模式。 正像我所怀疑的那样，第一个模式是，对于不同的项目，F1 关键字 － 动态帮助中列出的 Active Context － 并不总是位于数组中的第一个位置。 实际上，在 Visual Basic .NET 项目中，它似乎根本不遵循任何特殊模式，可能会出现在数组中的任何地方。

又一次阅读文档后，我发现了 DTE 对象的 HighPriorityAttributes 属性，该对象似乎暗示它应该包含 F1 关键字。 添加了检查属性 HighPriorityAttributes 的代码之后（这个过程在图 3 的宏中完成），我发现，对于源代码窗口，HighPriorityAttributes.Count 始终为零。 这一发现阻碍了我的计划，因为我希望对同样的 F1 关键字执行 Google 搜索。

我在 ContextAttribute 集合中发现的第二个模式是，对于基于 Visual Basic .NET 的应用程序，大多数关键字都以 "vb." 开头。 由于这些关键字实际上是特定于帮助引擎的关键字，这一点是可以理解的。 虽然我可以去掉 "vb."，但我估计不值得这样做，因为我根本无法获得 F1 关键字。

到目前为止，我关于 Google 外接程序的两个主要想法都失败了。 由于我无法使得 Visual Studio .NET CommandBar 正确处理组合框，也无法确保能对正确的 F1 关键字进行搜索，我需要后退一步，看看是否能找到另一种方式使 Google 进入 IDE。

返回页首

真正的 Google 外接程序

如果我无法让 Google 外接程序进入 CommandBar，我确信可以使它成为一个寄宿的工具窗口。 如果您不熟悉如何使托管控件寄宿在工具窗口中，我建议您访问 "Automation Samples for Visual Studio .NET"，您可以从该网页下载基本的 ToolWindow 外接程序。这个示例的关键部分是一个填充程序 C++ COM DLL，它承担了寄宿公共语言运行库 (CLR) 以及将您的用户控件加载到工具窗口的所有工作。 正如您稍后将看到的那样，我采用了这个填充程序 DLL 代码、添加了错误处理、断言（这样您就会知道发生问题时的具体症结了），以及一些其他的有用功能。 由于您的外接程序要加载这个填充程序，并且告诉该填充程序加载什么内容，您可以不加任何改动地重用我这个经过改进的填充程序 DLL。

您应该回头看看运行中 Google 外接程序的屏幕截图（请参见图 1）。 我认为 Google 窗口应该放在 Solution/Class 固定窗口和 Properties/Dynamic Help 固定窗口之间，这样更便于访问。 您完全可以将 Google 窗口拖入 Dynamic Help 窗口旁边的选项卡中。 如果您隐藏 Google 窗口，View | Other Windows 弹出菜单则会以 Google Search Window 作为第一项。 您还可以将如 Alt+F1 这样的组合键（可在默认键盘上使用）分配给 GoogleAddIn.ViewGoogle 命令。

因为我可以控制 Google 窗口中的组合框，所以我使得该组合框的运行状况与标准工具栏的 Find 组合框完全一样。 您在编辑控件中键入的任何内容都将添加到组合框中，并且会在 IDE 运行之间保存搜索。 正像我在本专栏文章开头说明的那样，在控件顶部分布的按钮都将执行一个特殊的搜索。

当您单击其中一个搜索按钮后，外接程序将根据您的 Help 设置启动浏览器窗口。 如果您选择了在外部启动 MSDN Help 系统，将在 IDE 的外面弹出一个完整的浏览器窗口。 如果您选择了内部帮助，则在 IDE 内打开一个浏览器窗口。 您可以覆盖选项中的默认设置。

像所有优秀的外接程序应该做到的那样，Google 外接程序有一个正确集成的 Options 对话属性页，如图 4 所示。 Settings 部分的所有选项都可以从字面看出其意义，但我只想提一句，Default Google 站点下拉列表允许您具体指定希望使用哪个国际 Google 版本。 我在 http://www.google.com/language_tools 上找到了所有国际站点。

图 4 Google 外接程序 Options 页

Group 限制字符串文本允许您指定将搜索限制在哪些组。 默认情况下，搜索会限制在 "comp.*" 组。 如果您希望将搜索只限制在由 Microsoft 托管的 Usenet 组，可以用 "microsoft.public.*" 代替该文本。

返回页首

实现要点

对于 Google 外接程序在其他方面的使用，我想用一点时间来讨论几个有趣的实现要点。 如果您不熟悉外接程序，并且想知道我是怎样将 Options 属性页放在 Options 对话框中的，请一定要阅读 Leo Notenboom 的 MSDN Magazine 文章 "Custom Add-Ins Help You Maximize the Productivity of Visual Studio .NET"。

我要解决的第一个难题是，如何在 Visual Studio .NET 中控制内置浏览器窗口。 在了解了 vsWindowKind* 常量中的各个窗口类型后可以知道，有一个 vsWindowKindWebBrowser，它是包含 Web 浏览器的 Window。 一般人都能意识到，该窗口内的内容是 SHDocVw.WebBrowser 的一个实例，您将掌握它的用法并发现它很有用。 不幸的是，我根本无法确定如何获得实际的 Web 浏览器控件以调用 SHDocVw.WebBrowser.Navigate 方法。

Window 类有一个 Object 属性，文档说它会返回一个可以在运行时通过名称访问的接口或对象。 虽然这段说明特别模糊，但我认为既然我是在用 C# 编写 Google 外接程序，就应该尝试将返回的对象强制转换为 SHDocVw.WebBrowser，然后看看会产生什么效果。 向项目添加了对 SHDOCVW.DLL 的引用后，我安装了图 5 中的代码。

虽然没有文档说明，但将 Window.Object 值强制转换为 SHDocVw.WebBrowser 的技巧非常有效。 更令人高兴的是，调用 Navigate 方法会自动显示 Web 工具栏，并且会将 URL 放入浏览地址组合框中。

在验证了我可以在 IDE 内控制内部 Web 浏览器窗口后，我开始创建实际的控件，这个过程就没什么特别的了。 不过，我希望在 IDE 内使用控件之前，对该控件进行彻底的调试和测试。 虽然可以开发和调试驻留在外接程序中的 .NET 用户控件，但我不希望这样做。 具有相应名称的 GoogleControl.DLL 包含了该控件的 UI。

因为我希望该控件是独立的，所以用于建立 Google 搜索 URL 的所有逻辑都在 GoogleControl.BtnBar_ButtonClick 中。 只要执行几个不同类别的搜索，并查找共有的元素，就可以得出各个参数。 我所作出的唯一比较有趣的设计决策是，我不希望访问 IDE 的控件本身去打开一个窗口之类的内容，因此当按下一个特殊的搜索按钮时，该控件会触发其 GoogleSearch 事件，该事件的参数包含完整的 URL。 这样，有控制权的应用程序就可以根据情况产生浏览器窗口了。

寄宿 Google 控件时，我几乎不知道选择使用事件将导致某种严重的棘手问题。 正如前面提到的那样，Microsoft 随一个外接程序示例提供了一个填充程序控件。 提供此填充程序的全部原因是，Visual Studio .NET IDE 是一个 ActiveX 宿主，而 .NET 框架不会创建 ActiveX 控件。 您的外接程序将创建一个 ToolWindow，通知它寄宿该填充程序。 一旦创建了 ToolWindow，您就要在该 ToolWindow 内访问该填充程序，通知它寄宿 CLR，并创建一个特定控件。 如果能演练图 6 中 CVSNetToolWinShim::HostUserControl2 和 CVSNetToolWinShim::FinalConstruct 方法中的寄宿代码，则会提供很大的指导作用。 完整的实现位于 VSNetToolHostShim2project 中的VSNETTOOLHOSTSHIM.CPP。

Microsoft 控件虽然需要一些正式的断言，但它能很好地完成工作。 不过，由于按下按钮后 GoogleControl 会触发一个事件，我意识到该 Microsoft 代码不会有帮助。 虽然在创建代码及使其运行时一切顺利，但无法访问 VSNetHostShim ActiveX 控件内实际寄宿的 CLR 控件。 如果不能访问该控件，就无法收到事件通知，也无法对控件本身调用方法。

在经历了片刻的不知所措以后，考虑到不得不重新构思 Google 控件实现，我想起了允许在控制实例的同时在应用程序域之间传递对象的 System.Runtime.Remoting.ObjectHandle 类。 如果我能够以某种方式从返回 C# 代码的 VSNetToolHostShim2 获得 IObjectHandle 接口，问题就全解决了。 令人高兴的是，调用 AppDomain.CreateInstance（它是必须在 CVSNetToolWinShim::HostControl2 中调用的方法，用来创建一个 .NET 对象）将返回 IObjectHandle 接口。 这种做法的结果是，Microsoft 宿主填充程序已经在其实现内包括了 IObjectHandle 接口，但没有公开它所需的方法。

我需要做的事情是，向刚刚对 IID_IObjectHandle 的 ObjectHandle 类成员数据执行了 QueryInterface 的 VSNetToolHostShim2 ActiveX 控件添加一个新的方法。 您可以在 CVSNetToolWinShim::GetObjectHandle 方法中看到这行代码。

一旦您用 .NET 编写的外接程序包括了 ObjectHandle，您要做的就是调用 Unwrap 方法，然后将返回值强制转换为适当的类型，于是您就获得了对寄宿控件的引用。 虽然我真的很希望 CVSNetToolWinShim::GetObjectHandle 方法直接返回 ObjectHandle（本来可以通过在 VSNetToolHostShim2.IDL 中导入 MSCOREE.IDL 来完成），但 MSCOREE.IDL 文件包含对并不存在的文件的引用，因此如果导入或者如果 MSCOREE.H 包括在 IDL 文件中， MSCOREE.IDL 文件不会进行编译。 因此，我返回了 IUnknown，您需要将返回值强制转换为 ObjectHandle，以便调用 Unwrap 方法。

如果最后几段内容有点看不懂，则需要参考图 7，图 7 显示了 Google 外接程序中创建 ToolWindow 并使 Google Control 得以正确寄宿的方法。 对于您自己的工具窗口，您可以使用代码来确保寄宿控件能够正确安装。

对于围绕 VSNetToolHostShim2 控件所作的所有这些操作，令人高兴的是，您可以完全按照现有的形式对于希望寄宿在 Visual Studio .NET 内的任何控件使用该控件。 有了 VSNetToolHostShim2，您现在就可以处理触发事件的控件了。 您可以像我处理 Google 控件那样，更好地分离功能，这样可能就能够实现可插入多个应用程序中的真正可重用控件的梦想。

Google 外接程序的最后一个任务是将其无缝地集成到环境中，我希望向 View | Other Windows 弹出菜单添加一个 Google Search Window 选项。 根据我对文档的理解，我需要做的是得到 "&View" CommandBar，一直枚举到 Other Windows 弹出菜单，然后将我的命令插在弹出菜单的末尾。 我没有想到这会成为一个大问题，但我带着错误的假设就这样去做了。

我第一个步骤是编写下面的宏，枚举 "&View" 菜单上的各项，然后返回它们的类型：

Sub PrintMenu()
    Dim cw As New CmdWindow

    cw.Clear()
    Dim Cmds As _CommandBars
    Cmds = CType(DTE.CommandBars, _CommandBars)
    Dim FileMenu As CommandBar = Cmds("&View")
    For Each Ctrl As CommandBarControl In FileMenu.Controls
        cw.WriteLine(Ctrl.Caption + vbTab + Ctrl.Type.ToString())
    Next

End Sub

顺便提一句，CmdWindow 是一个简单的类，它将写入的内容封装到 Command 窗口和 Output 窗格。 我关于宏的想法是枚举控件，然后输出其类型，这样我就能知道究竟需要哪些值了。

但我惊讶地看到，Other Windows 菜单没有列在输出中，对于每个菜单项，除 msoControlButton 之外也没有其他类型。 通过在周围进行单击，我发现可以独立枚举 Other Windows 菜单，这样就可以很轻松地将我的菜单选项添加到正确的位置了。 我的假设是我可以直接从 CommandBar 获得 msoControlPopup 类型。

返回页首

总结

虽然整个过程出了很多差错，但最终还是完成了这个每天用来解决不断出现的开发问题的外接程序。 Google 是一个了不起的搜索引擎，现在我将它嵌入在我的 IDE 中，我真不知道没有它该怎么办。

返回页首

提示

在我的上一篇专栏文章中，由于版面紧张，只能发布两条提示中的一条。 为了弥补缺少的这个提示，这个月您可以看到三条！ 如果您有任何要发布的心得体会，请立即通过电子邮件将它们发送给我，我的邮件地址是 john@wintellect.com。

提示 56 Microsoft Visual Studio 小组已经将 Visual Studio 的一些功能较强的外接程序整理成为一个集合，您可能会发现这个集合非常有用。 您可以访问 PowerToys for Visual Studio .NET 2003 下载这些外接程序。 利用 Visual Basic Commenter，您可以在 Visual Basic .NET 中加入 XML 注释，利用 Custom Help Builder，可以向帮助系统轻松地添加您自己的类文档，这两者都是 IDE 的比较出色的外接程序。

提示 57 为了加速 Visual Studio .NET IDE 的启动，可以取消 Start Page（起始页）。 因为 Start Page 需要加载所有 Web 浏览组件，所以您可以通过跳过起始页，从而节省大量启动时间。 要关闭 Start Page，请从 Tools 菜单选择 Options，打开 Options 对话框。 在 Environment/General 属性页中，在 "at Startup" 组合框中选择 "Show empty environment"。

提示 58 另一个性能提示是，关闭 Solution Explorer 窗口中的跟踪活动选项。 这样当您在项目中对不同的文件进行操作时，就可以避免 Solution Explorer 选定内容到处移动。 从 Tools 菜单中选择 Options。 在 Options 对话框中，选择 Environment/Projects and Solutions 属性页，取消选中 Solution Explorer 中的 Track Active Item。

如果您对 John 有任何问题和意见，请发送将电子邮件发送至 slayer@microsoft.com。

John Robbins 是 Wintellect 的创始人之一，这是一家专门致力于 .NET 框架和 Windows 编程的公司，公司业务涉及软件咨询、教育和开发。 他最近出版的图书是《Debugging Applications for Microsoft .NET and Microsoft Windows》（Microsoft Press，2003）。 您可以访问 http://www.wintellect.com 来联系 John。

摘自 2003 年 11 月的 MSDN Magazine。

可以从当地报摊或最好通过订阅购买该杂志。