ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Office 2007与ACE冲突?修改MSI LaunchCondition

Office 2007与ACE冲突?修改MSI LaunchCondition 简介针对64位Windows 7系统同时安装32位Office 2007与64位AccessDatabaseEngine 2010时出现的版本冲突这份资料面向IT运维和Office组件部署人员给出了不升级Office即可启用64位ACE数据库引擎的解决思路。资源包为单个Word说明文档压缩包仅47KB内容覆盖冲突原因、两个辅助工具的使用要点和修改安装条件的完整流程尤其演示了用7-Zip提取安装文件、用ORCA删除阻止安装条件的关键步骤并提供了两个工具的下载地址方便读者准备环境。已有4024人学习下载。操作步骤清晰整个处理办法不要求重装Office也不影响原有数据整体思路是在保留原有32位Office环境的前提下完成64位数据库引擎安装适合处理大量数据的办公场景。文档也提醒了备份与风险注意事项有助于读者举一反三解决同类32位与64位组件混装问题。1. 冲突在哪里32位Office 2007遇上64位ACE引擎的安装拦截把 64 位 AccessDatabaseEngine_X64 装到安装了 32 位 Office 2007 的 64 位 Windows 7 上十有八九撞冲突墙。我头一回遇到是在给 SSIS 准备数据通道双击安装包不到两秒就弹“检测到与当前 Office 产品不兼容”安装直接回滚日志里只留着一个叫 BLOCKINSTALLATION 的关键字。问题不在系统损坏而在 ACE 引擎安装包里写死了一条 MSI 启动条件。本文从这条条件的含义讲起依次拆解 7-Zip 解包、ORCA 删除条件、改后 MSI 重装的完整过程适合做数据迁移、BI 开发、系统集成的工程师也适合被同样报错卡住、想弄明白到底改了什么的同学。2. 原理拆解LaunchCondition 的拦截逻辑与 ACE 引擎的 Bitness 边界2.1 ACE 引擎是干什么的从 JET 到 ACE 的演进Access Database Engine 是微软随 Office 提供的一套数据库存储和访问组件。更早的系统里它是 JET 4.0只支持 .mdb 和 .xls从 Access 2007 开始格式换成 .accdb/.xlsx组件也改名 ACEAccess Connectivity Engine以 OLEDB Provider 的形式对外开放注册名是 Microsoft.ACE.OLEDB.12.0。Excel 里的外部数据、VBA 里的 ADODB、以及 SQL Server 的导入导出向导底层都走这个入口。在 2010 年发布的第二个版本里微软把 ACE 拆成 32 位和 64 位两个安装包也就是常见的 AccessDatabaseEngine.exe 与 AccessDatabaseEngine_X64.exe。32 位包尺寸小、兼容老脚本64 位包则主要解决大数据量场景下的内存和进程位数问题。实际上很多 BI 工程只在 64 位 SSIS 或 64 位 .NET 程序里需要它不装这个驱动64 位进程连 .accdb 文件都打不开更谈不上读写。为什么绕来绕去还在用 2010 版而不是更新的版本选型理由其实很现实2010 版是微软最后一个以 Redistributable 方式免费提供、且能独立解包的 ACE 版本之后的 ACE 随 Office 2010/2013 分发没有单独的免费安装包。而 2007 版对 .accdb 的支持和稳定性都差一些。所以网上绝大多数解决“Office 2007 环境装 AccessDatabaseEngine_X64 冲突”的方案落点都在 2010 版安装包上AceRedist.msi 就是它的安装主体。这一点和我们在做的资源完全吻合。2.2 LaunchCondition 在 MSI 里的位置安装一启动就在把关MSI 安装包和普通 exe 安装程序一大区别是它由 Windows Installer 服务统一调度分 UI 序列、执行序列、广告序列等。LaunchCondition 表属于安装前检查的一部分在 UI 序列和安装执行序列最早的位置评估。表里每行是一条“条件表达式 描述文本 错误级别”只要有一条条件表达式为 False安装器就整体终止并回滚对应的窗口提示文案来自这行的 Description 字段。这就是为什么你双击原包时连安装向导都看不到但日志里已经留下了判断结果。AccessDatabaseEngine_X64 的 LaunchCondition 表里就躺着一条专门做版本互斥检测的记录即 BLOCKINSTALLATION。它的大意是检测到系统里已有位数不匹配的 Office 产品时禁止继续安装。安装器不会细说“你有一个 32 位 Office 2007”只会把 BLOCKINSTALLATION 条件名和描述文本抛出来。原包直接双击时那不到两秒的闪退就是这个表在起作用还没开始往硬盘写文件条件检查就已经把安装拦下了。2.3 微软为什么要写这条拦截Bitness 边界与正确的组件选型根本原因在 Windows 的 COM/OLEDB 体系32 位进程无法加载 64 位进程内组件。ACE 引擎是进程内 OLEDB Provider它的 DLL 被加载到调用进程地址空间里。64 位 ACE 的注册表项落在 64 位视图下32 位程序连注册表路径都看不到更不可能加载其 DLL。微软为了防止用户发现“装完还是不能用”而投诉干脆在安装器里做二次检查用 BLOCKINSTALLATION 提前把不匹配的安装组合挡在门外。动手之前先看一眼这个选型对照能省掉大半的无效操作目标场景正确的组件本文改包方案是否适用32 位 Office 2007 VBA 直接读写 accdb32 位 AccessDatabaseEngine.exe不适用64 位 SSIS / dtexec 读取 accdb64 位 ACE适用64 位 .NET / C 程序打开 xlsx64 位 ACE适用64 位服务程序调用 ACE OLEDB64 位 ACE适用这个表格经常被忽略但它是动手前最该看的对照。网上大量帖子只教删 BLOCKINSTALLATION不提醒调用方位数导致一部分人装完 64 位 ACE 之后在 Office 2007 的 VBA 里继续报“未找到提供程序”回头骂方案不管用。本文绕开条件拦截只针对 64 位调用方成立的场景。删除 BLOCKINSTALLATION 修改的是安装器决策运行期的位数鸿沟依然存在调用方必须是 64 位进程。3. 实操落地7-Zip 解包、ORCA 删条件、改后 MSI 安装3.1 工具选型为什么是 7-Zip 和 ORCA资源附带的两个工具下载地址很明确一个是 7-Zip一个是 ORCA。7-Zip 在解包界的优势大家都知道它能直接把 exe 自解压包当压缩包打开不触发安装界面也就不会在解包阶段被 BLOCKINSTALLATION 拦截一次。用 WinRAR 也能开一部分自解压包但对 MSI 的目录结构和 CAB 文件路径保留不如 7-Zip 干净。ORCA 是微软官方 MSI 表编辑器随 Windows SDK 分发网上流传的独立版是从 SDK 里提取出来的。它比 InstEd Lite 强在能看到所有 MSI 表改完还能保留 MSI 结构完整。我强调一个选型理由不要为了省事直接改注册表或者替换 dll。改注册表强行注册 64 位 OLEDB Provider 会造成 Provider 指向错乱卸载时还收不干净替换 dll 会影响系统文件保护。改 MSI 的 LaunchCondition 是影响面最小、可反悔的路径——改动局限在安装判断逻辑不碰二进制文件真出问题还能用原版包装回去。3.2 解包 AccessDatabaseEngine_X64.exe界面提取与命令行下载到的 AccessDatabaseEngine_X64.exe 实际上是一个自解压压缩壳里面装着一个 MSI 主体文件和一个 CAB 数据文件。用 7-Zip 解包的标准命令如下7z x -oD:\ACE_X64 AccessDatabaseEngine_X64.exex表示按压缩包内部目录结构解压-oD:\ACE_X64指定输出目录注意-o和路径之间不能有空格这是 7-Zip 命令行的老规矩如果只想预览内部内容先用7z l AccessDatabaseEngine_X64.exe查看清单。解压完成后目录里会同时出现 AceRedist.msi 和 aceredist.cab两个文件必须保持在同一个文件夹里后续安装、卸载、日志都需要它们。不习惯命令行的直接右键 exe → 7-Zip → “打开压缩包”全选内部文件解压到指定文件夹效果一样。我更推荐命令行因为输出目录可控后面验证日志文件路径时不会搞混。3.3 修改 AceRedist.msi删掉 BLOCKINSTALLATION先把原 MSI 复制一份留底比如 AceRedist_original.msi。然后启动 ORCA打开 AceRedist.msi。ORCA 左侧是所有 MSI 表的列表双击 LaunchCondition右侧出现该表的全部记录。按下面顺序操作在右侧记录里找到描述文本或条件表达式中带 BLOCKINSTALLATION 的行。单击选中该行按 Delete 删除ORCA 会弹确认提醒。确认无误后File → Save As 另存为 AceRedist_modified.msi不要覆盖原文件。删除这一行的意思是安装器评估启动条件时不再强制执行“Office 位数不一致就终止”的检查。其他行不要动里面还有管理员权限检查、系统版本检查等基础条件全删光会带来新的隐患。ORCA 改完保存后MSI 的原数字签名会失效Windows Installer 可能提示“安装包不受信任”这是改包的正常副作用直接继续即可不是文件坏了。注意这里只删条件行不改属性表、不换 ProductCode、不动 File 表。ProductCode 一旦改了卸载和补丁机制都会错乱这个坑在第 4 章会详细说。3.4 运行修改后的 MSI正常安装与日志兜底现在双击 AceRedist_modified.msi 应该能进入正常安装界面。但我建议第一次先走命令行方便把日志留下遇到任何异常都有据可查msiexec /i D:\ACE_X64\AceRedist_modified.msi /l*v D:\ACE_X64\ace_install.log/i表示安装指定 MSI/l*v表示记录详细日志到指定文件*记录所有信息v是 verbose路径保持英文避免日志编码或路径解析的怪问题。第一次安装不要加/qn静默参数图形界面能直观看到安装进度和结果确认稳定之后再做静默批量部署不迟。安装完成后打开控制面板 → 程序和功能列表里出现 Microsoft Access Database Engine 2010就说明绕过拦截成功。此时 C:\Windows\Installer 目录中会多出一份 MSI 缓存副本那份副本对应的就是修改后的文件这也是第 5 章要强调“保留修改版 MSI 做后悔药”的原因。4. 避坑排查五个安装 ACE 时容易翻车的细节4.1 先给冲突归个类很多报错不是玄学AccessDatabaseEngine 的安装冲突和你熟悉的依赖包版本冲突、DLL 冲突本质上是同一类问题安装器基于它出厂时的产品矩阵替用户做决策但这个决策在若干年后已经跟不上真实环境。Office 2007 与 ACE 2010 的位数互斥是 2009 年定的规则可实际部署环境里一堆新组件早就改变了情况。遇到报错先别反复双击安装包那是纯粹的碰运气。把 MSI 日志打开、看 LaunchCondition 里的条件值比任何“玄学”方法都来得快。4.2 五条具体踩坑记录现象、原因、解决现象用 7-Zip 解压后双击 AceRedist.msi 依然报 1603 或者找不到源文件。 原因MSI 和 aceredist.cab 没有放在同一目录。7-Zip 解压时如果按内部路径生成了子目录CAB 就不在 MSI 的 SourceDir 里MSI 定位不到 CAB安装必然失败。 解决把 AceRedist.msi 和 aceredist.cab 放到同一个独立目录的顶层再用msiexec /i D:\ACE_X64\AceRedist_modified.msi /l*v D:\ACE_X64\ace_install.log执行失败时打开日志搜“ResolveSource”看它实际找的路径。现象ORCA 保存后安装包双击没有任何反应或提示无法读取安装包、签名验证失败。 原因MSI 文件被 ORCA 修改后原始数字签名失效。直接覆盖原文件保存时Windows Installer 的缓存校验和数字签名校验会叠加产生误导性错误。 解决保存时用 Save As 另存为 AceRedist_modified.msi保留官方原版作为备份运行修改版时如果提示签名相关问题属于预期行为选择继续安装即可。现象在 ORCA 的 LaunchCondition 表里找不到 BLOCKINSTALLATION 这一行。 原因下载的不是 2010 版 64 位 ACE 包。可能是 2007 版也可能是 32 位的 AccessDatabaseEngine.exe不同版本的 MSI 条件表和条件名不完全一样。 解决在 ORCA 里先看属性表 PropertyProductName 应为 Microsoft Access Database Engine 2010再用解压出来的 cab 里 DLL 文件的位数做二次确认。确认是 64 位 2010 版后再删除操作找不到就换正确的包不要顺手把其他条件全删了。现象安装成功后Office 2007 的 VBA 代码里 ADODB 仍然报“未找到提供程序 Microsoft.ACE.OLEDB.12.0”。 原因位数组件隔离。ACE 的 OLEDB Provider 是进程内组件64 位 DLL 只为 64 位进程注册32 位 Office 2007 进程完全看不到它。 解决明确你的调用方是 64 位还是 32 位。需要 64 位驱动的是 64 位 SSIS、64 位开发工具、64 位服务程序如果需要 Office 2007 的 VBA 直接访问 accdb应当安装 32 位 AccessDatabaseEngine.exe而不是本方案。这个边界不是“改包”能绕过去的别在这个问题上浪费时间。现象装了修改版之后某天想卸载或重装官方原版提示“产品已安装”或找不到安装验证信息。 原因Windows Installer 缓存里保留的是修改版 MSI官方原版安装包的缓存校验方式和修改版不一致卸载管理器自然无法匹配。 解决把修改版 MSI 留在原目录用msiexec /x D:\ACE_X64\AceRedist_modified.msi卸载如果缓存已损坏用 Windows Installer 清理工具按原 ProductCode 清理后再装官方原版。第 3 章让你留 AceRedist_original.msi 和 AceRedist_modified.msi 两份文件就是提前给这一步留后悔药。5. 验证与进阶连接测试、注册表确认和一个安装习惯5.1 安装后三分钟验证日志、注册表、真实连接安装成功可以在控制面板看到但“安装成功”和“驱动能用”是两码事。先看安装日志 ace_install.log末尾应该有Product: Microsoft Access Database Engine 2010 — Installation completed successfully。然后查注册表确认 64 位 Provider 是否进入 64 位视图reg query HKLM\SOFTWARE\Microsoft\Office\14.0\Access Connectivity Engine\Engines\ACE /v FLAGS在 64 位系统上64 位 ACE 的引擎注册信息位于 64 位注册表视图的 Office 14.0 分支下/v FLAGS查看具体属性值。如果提示找不到说明 Provider 注册不在当前视图里回到避坑 4 检查进程位数。最后做一次真实的连接测试比看十个注册表项都直接。下面这段 VBS 用 ADODB 连一个已有的 accdb 文件Set conn CreateObject(ADODB.Connection) conn.ConnectionString ProviderMicrosoft.ACE.OLEDB.12.0; _ Data SourceD:\test.accdb; conn.Open If conn.State 1 Then WScript.Echo OK: ACE OLEDB 12.0 连接成功 End If conn.Close Set conn Nothingtest.accdb 需要先存在用 Access 新建即可。运行脚本必须用 System32 下的 64 位 cscript.exe命令是cscript D:\test_ace.vbs想对照 32 位进程的表现用C:\Windows\SysWOW64\cscript.exe跑同一份脚本会得到“未找到提供程序”这个差异正好印证第 4 章说的位数隔离。5.2 一个值得养成的安装习惯我自己在这个问题上翻过一次车改完 MSI 后顺手删了所有原文件三个月后客户环境要卸载 ACEWindows Installer 缓存校验对不上卸载入口全失效最后靠清缓存加装原版才恢复。从那以后我处理任何 MSI 安装冲突都强制走一遍固定流程先解包看 LaunchCondition再拉一次安装日志确认条件里到底是哪个检查在拦然后只删最小范围的条件行保留原版和修改版两份 MSI装完一定补一次连接验证而不是瞄一眼“安装成功”就收工。这套流程对 AccessDatabaseEngine_X64 的 Office 冲突有效对大多数 Windows Installer 的互斥检查同样有效。希望帮到你。本文还有配套的精品资源点击获取
返回列表