应用程序生命周期

在项目的生命周期中，许多决策都必须与操作过程有关。诸如提前计划版本、强度测试和疑难解答在各个时期都至关重要。计划最终会为您省去许多麻烦和时间。查阅 Microsoft Solution Framework 即可得知生命周期的准则：www.microsoft.com/msf（英文）。

了解何时设置“二进制兼容性”

编译指定“二进制兼容性”的 DLL，意味着新生成的 DLL 和旧的 DLL 有相同的 TypeLibraryID、Class ID、Interface ID 和其他标识符。这在后续版本的 DLL 部署到工作的客户机时是很必要的。不过，在开发周期中使用它可能不利于效率。在冻结所有接口之前请保持项目的兼容性，然后兼顾二进制兼容性并保持它。

详细信息

根据 COM 规则，接口在保持其 IID 的情况下不能改变。Visual Basic 利用一种所谓接口转发的功能，使开发人员免受该规则的限制。但是，它最终要创建复杂的注册表项。实际上这种转发是一系列搜索，最终指向最新和最好的编译的 COM 组件。

一旦设置了转发链，就失去了将组件放入 MTS 的能力。在迅速改变接口规范期间，这可能导致混淆。尽可能多地消除这种链。

此外，还有一个应用程序的周期问题。一旦设置了接口，回去改变它们可能会危及其他同时进行的开发活动。

操作方式

在开发周期中，您的对象接口通常经过许多改变以纠正设计阶段未检测到的错误。在这一发展过程中，最好使 DLL 保持项目兼容性。在极特殊的情况下，甚至可以依靠后绑定。不过这会减少 Visual Basic Intellisense AutoComplete 功能的大量开发人员性能优势。您不如退回一步，使接口正确无误，然后再恢复同时进行的开发。

在确信可以发布组件后，可将 DLL 的一个单独副本存储在一致同意的位置，以供日后引用（也许就在有“只读权限”的 Source Safe 中），将“兼容性”对话框指向它并指定二进制兼容性。

参考

PRB：在 MTS 的 VB 组件中添加新方法会中断现有的客户机 (Q241637)（英文）
MSJ：防止运行时版本冲突的 Visual Basic 设计时技术（英文）
BUG：MTS 无法删除 VB6 项目兼容服务器 (Q190175)（英文）
PRB：在有 MTS 的 Visual Basic 中已经将错误转发给该接口 (Q222634)（英文）

对应用程序进行强度测试以得到实际的容量计划

与给定范围的可用物理资源相比，应用程序的可伸缩性与资源冲突、队列拓扑和应用程序体系结构的关系更大。为机器添加更多的处理器或者为进程添加更多线程，通常不会明显地提高性能，特别是在现有资源尚未充分利用的情况下。确定一个应用程序是否能够承受一定负载的最佳方式，就是通过严格的强度测试（除了可能不现实的实际生产环境测试之外）。

详细信息

即使最简单的可伸缩性模型也是基于非线性关系的，而且得自于简单的系统。对复杂系统来说，对计划的性能建模就难多了，更不用说特殊情况下的性能了。为了合理地得到系统功能的精确规格，需以不同程度的强力测试应用程序，并全面记录实际的性能数。您应该绘制“性能/负载”和“负载/资源”图，然后观察其趋势以获得更现实的期望值。不过，计划值永远不会代替从强度测试中得到的实际经验结果。

操作方式

在 MTS 中可利用管理单元中的“状态视图”或者 XTremesoft 的性能监视器计数器，来确定一定强力程度下的对象使用情况。如果看到软件包的活动对象总数接近 100，那么可能需要调整 MTS 线程池。另一方面，体系结构也可能对 MTS 活动线程强加了不现实的负载。

参考

对可伸缩应用程序的性能测试（英文）
没有 MTS 的应用程序部署结果（英文）
Web Workshop：对 ASP 应用程序的负载测试（英文）
Windows DNA 性能工具包（英文）
XTremesoft（英文）

将测试环境设计为高度匹配生产环境

人们在将应用程序从测试、QA 或模拟调试移入生产的过程中会遇到许多问题。包括：

• 不同的操作系统版本
  
  
• 不同的服务运行
  
  
• 不同的处理器数量
  
  
• 应用程序跨越的不同的安全边界
  
  
• 不同的域、域信任度，或者本机特权或身份
  
  
• 网络流量会影响应用程序与已连接资源通信的能力
  
  
• 不同的连接设置（DNS、防火墙等等）
  
  
• 不同的资源可用性（与硬编码路径、注册表等相关的问题）

操作方式

在规范、设计和开发阶段，通过网络管理员和安全工程师的介入，很多此类问题是可以避免的。这包括在所有关键测试过程中保证他们的参与。同时，一定要了解应用程序的需求，并且用与生产中预期相同的锁定行为来测试系统。

参考

信息：测试 Web 服务器的强度测试工具 (Q231282)（英文）

测试部署并作计划备份以防失败

分布式应用程序生命周期中，出现困难的最大原因来自于应用程序开始工作的那天。所有有关团体试图给无生命的应用程序注入空气掩盖了该事件的缺少练习和计划。在“进入存活日”之前，需要在干净的环境中和所有参与者在场的情况下练习操作。在得到控制的环境中解决小问题，而不要对生产用户增加压力。通过计划和记录生产安装过程以及可能的计划，来避免部署失败所带来的混乱和难堪。

操作方式

创建称为“干净系统”的环境。它和应用程序及测试部署无关。从最常见的配置（Windows 2000 Advanced Server 的干净安装，或者映射到生产环境的任何配置）开始，清楚地记录分布式应用程序安装过程中涉及的每个步骤。注意二进制文件的位置以及安装点所在的位置。

假定在整个过程中没有人来解决问题。确保包括了安装程序可以使用的小型测试方案作为确定安装是否正常进行的记录点。最后，文档如何卸载应用程序，包括已注册组件、注册表项、临时文件、为它创建的特殊用户或者已经安装、启动或停止的服务。

参考

COM+ 应用程序的部署和注册（英文）

使用源控制软件，以及源控制策略和方针

分布式应用程序有许多分布在网络中的组件，这通常是件好事。不过，如果源代码分布在整个企业中，那么这肯定不是好事。在开始开发之前，应确定未来的源代码策略。保证对源代码和所有测试组以及结果的文档记录。确保调试扩展包括在编译后的代码中。（参见上面的“编译和符号信息”。）

操作方式

务必在安装说明中包括简单的文本文件，其中有如何在需要调试时获得源代码副本的说明。

参考

Visual SourceSafe 6.0 数据表（英文）
设置 Visual SourceSafe（英文）

了解如何调试和分析正在运行的应用程序或者转储

在完成项目后，您会编译它，然后部署在模拟测试环境中，最后放入生产环境。由于配置、硬件、逻辑或运行时错误，应用程序随时会表现不利的行为。

在这样的情形下，往往缺乏开发过程中的开发和调试工具，那就必须后退到另一种调试机制。

在某些情况下，调试器的存在会减少错误信息。开发环境经常使定时错误和运行情况无法表现出来。好在有许多调试工具可以用于这些情况。不过大多数工具的设置和配置都很麻烦。

有两种主要的调试用户模式进程，例如 MTX.EXE。它们是交互调试和转储调试。

交互调试意味着加载工具，如 Visual C++，它们可实现运行时线程控制、浏览内存（如处理器寄存器、堆栈和堆空间），所有这些都在实际程序的执行过程中完成。可在 COM+ 应用程序的属性单上指定这种调试器。有关交互是调试的更多信息，请参见调试 Visual Basic MTS 组件（英文）。

适用转储调试的情况是，应用程序崩溃了，而又很难得知服务器应用程序开始在 100% CPU 利用率的情况下运行的原因和时间。这主要围绕着一下操作来进行，即获得运行进程的快照（通常是崩溃转储），再将其加载到调试器中以分析错误当时的状态。由于这需要对机器、堆栈和堆体系结构有更多的低级别的了解，因此它比交互调试要难困，但一旦您有内存转储，它就可以随时在任何机器上完成。

操作方式

许多工具都对开发的应用程序很有用。当与遗产代码、继承的黑盒 DLL 或者其他方案交互时，这些工具特别重要。同时还需要为组件生成 PDB 文件，请查看上面的“编译和符号调试信息”一节。

为该类型行为选择的一种良好工具是 IIS Exception Monitor。它允许“钩连”到 MTS/IIS/COM+ 进程，以便监视可能在运行进程中发生的任何异常情况。

最简单的交互调试工具是 Visual C++，因为它是面向 GUI 的调试器。但是，它的可用性受到一些限制。如果您不愿意在生产或测试环境中存在 Visual Studio 的安装，那么其他调试器可能更符合您的需要。

其他可用的调试器还有 win32 SDK 中很有口碑的 WinDBG。它的强大功能是有代价的。建议您很好地了解汇编代码及其复杂性。