使用微软公司提供的再发布的赞同和反对意见
开发者应该使用微软公司提供的再发布吗？通常，这个问题在开发者仅仅需要一个特定组件或由于安装程序需要一个自动并无须重启动的安装过程是被提出来。手工制作再发布是可以的。为了制作MDAC
1.5的在发布，请参看知识库文章 Q178842 （FILE：
Mdacred.exe Required Files to Redistribute MDAC 1.5）。这篇文章的MDAC 2.0版本此时还没有发表；但是，在此文章的MDAC
2.0组件文件列表中你可以找到你所需要的信息。
创建一个健壮、全面的MDAC再发布机制不是一个简单的任务。简单地将文件放入一个目录并注册它们是不够的。这里是应注意的一些问题：
- 文件现在是不是装载在内存中？如果是，你必需使用Windows API来安装文件并在重启动时注册这些文件。包含在Platform SDK中的Setup API功能支持这些动作。但是这意味着你的再发布机制必需用C++语言编写或用基于C++的DLL调用。
- 在更多情形下，为了注册ODBC驱动程序，你必须实际安装 ODBC。Microsoft Technical Support ODBC 3.0安装假定你在某个目录下有完整的新版本ODBC组件，并在注册新版本ODBC时明确使用LoadLibrary函数。但是，ODBC的正式发布使用一个工具——Odbcconf——来明确地在重启动后注册 ODBC驱动程序。前面一个方法的优势是可以少测试（或终止）一个再发布，并且只在将内存中需要的MDAC文件注册时才需要重启动。Odbcconf则意味着必需重启动才能完成安装过程。
- OLE DB、ADO和RDS组件必需安装到正确的路径并从那里注册。也就是说，在注册前，你必需将当前路径转到DLL的安装路径（特别时OLE DB DLL）。否则，注册将会失败，尤其在注册OLE DB Provider for ODBC Drivers时（尽管这个问题并不仅仅局限于这个组件）。
- 测试一个再发布机制可能会非常烦琐无味。你必需针对不同的操作系统和安装在机器上的不同的主要产品或技术对再发布机制进行测试。例如，这是为了保证你的再发布机制能够正确处理文件版本问题。这些被测试的操作系统平台包括Windows 95、Windows 95 OSR2、Windows NT 4.0 Server （和Windows NT 4.0 工作站，尽管根据作者的经验，这不太必要）、Windows 98和很快就要面世的Windows 2000。然后加入服务软件包、Web浏览器和主要产品如数据库服务器和办公应用程序软件等。这些测试的排列组合将会使测试越发复杂。
专业的磁盘镜像软件可以使这个过程进行得快些，它可以将恢复操作系统配置的时间从几个小时减少到几分钟。另外，本文作者推荐在你的再发布机制的测试机器上有一个大的硬盘（最小 4
GB），其中至少一半空间专门用于为不同的操作系统存储图像。一套能很快测试OLE
DB、ADO和 RDS（以及你需要的驱动程序或数据提供商）的测试程序那是必需的。对ODBC和 OLE DB，
QueryDemo示例程序是测试它们的简单方法。对ADO，使用那些通过实例化每个对象并执行其主要的方法（BeginTrans、Open、Execute、AddNew等等）的代码来进行测试。在测试MDAC
1.5再发布机制时，作者发现一个如果一个OLE
DB DLL没有注册，则无法创建Parameter对象的情况。
- The MDAC独立安装程序、MDAC 再发布安装程序和Data Access SDK安装程序都用于检测MDAC组件彼此之间的依赖关系。建造他们自己的再发布的用户最容易忽略的一个依赖关系是ODBC 3.5和OLE DB Provider for ODBC Drivers之间的依赖关系。如果你的安装程序没有考虑到这一点，你可能会破坏用户机器上的应用程序。并不是每个使用你的再发布组件的用户都会碰上这个问题，但有些用户就会。
再发布的大小你是否自己创建自己的再发布解决方案的有效依据。但是，如果你要这样做，本文者坚强推荐你使用专业的再发布软件。这些产品可以解决前文列出的许多问题——比如很好地处理对现在装载在内存中的文件的更新问题。包含在Platform
SDK中的Setup API是创建C/C++安装程序的一个很好的资源。美国微软公司技术支持的基本努力就是帮助消费者处理再发布问题。
小心掉入被“我仅仅想要这个组件”的怪圈。组件经常有依赖关系。如果你考虑不到，则你的应用程序的安装会无意中给你的消费者带来不良后果，并会给他们已经安装的其他软件带来无意的损害。
