Inno Setup 覆盖安装前执行卸载、获取原安装路径实战用 Inno Setup 做安装包时最让我头疼的一个改动需求就是“覆盖安装时先把旧版本卸掉再装新的”。听起来很简单但真做起来全是细节怎么在安装启动阶段拿到旧版本的位置、怎么保证卸载程序能干净跑完、如果用户中途取消卸载要不要继续装、装完之后注册表残留怎么办。这篇就把我在实际项目中落地的完整方案和踩过的坑一次说清。这篇文章适合正在维护 Windows 桌面软件安装包、对 Inno Setup 语法有一定基础至少知道 [Setup]、[Files] 段怎么用的开发者。如果你是第一次听说 Inno Setup建议先跑通一个最简单的安装包再回来看不然部分概念会有点跳。核心解决三个问题知道旧版本装在哪里、什么时候触发卸载、卸载失败如何处理。1. 为什么覆盖安装前必须先卸旧版1.1 覆盖安装的隐藏雷区接手这个需求之前我其实也是“偷懒派”——直接让 Inno Setup 覆盖写文件觉得只要版本号升上去、文件覆盖掉就行。但现实很快教做人覆盖安装至少有这三个坑第一旧版注册的 COM 组件、服务、驱动不会自动清理。比如旧版注册了一个全局 Hook DLL新版本如果不再需要这个组件覆盖安装后这个 DLL 还在系统里被加载着用户迟早会碰上诡异冲突。第二文件版本不同但文件名相同。如果你新旧版本里某个公共 DLL 的版本号相同直接覆盖可能不会替换如果新版本把文件拆分了比如一个 exe 拆成 exe dll旧文件就会残留装完出现“幽灵文件”。第三用户配置和注册表项的状态不可控。旧版卸载时会执行一些清理逻辑比如删除旧版专用配置、重置 Shell 状态但覆盖安装完全绕过了这些。等用户手动卸载新版时那些旧版遗留的清理逻辑早已失效。所以产品侧提出“覆盖安装前先执行卸载”这件事不是小题大做。尤其是老项目迭代多年、历史包袱大干净卸载再装新版本比指望覆盖逻辑永远正确要稳妥得多。1.2 卸载再安装的核心判断逻辑“先卸载再安装”听起来是暴力方案但它背后的判断逻辑其实很讲究什么情况下允许自动卸载什么情况下不能我的经验是至少要看这三层旧版必须是在本机上确实存在的。如果用户是全新安装根本没装过旧版你上来就执行卸载只会弹一个“未找到卸载程序”的报错体验极差。卸载不能是静默无声的。用户的机器上可能有正在运行的旧版程序直接静默卸载会把用户的工作进程杀掉至少得弹窗问一句“检测到旧版本是否先卸载再安装”。用户取消卸载时安装流程必须终止。不能出现“用户点了取消卸载结果新版本照样装”的尴尬局面否则两个版本文件混杂比覆盖安装还危险。这里还要提一个容易被忽略的点如果新版安装包是 MSI 包而旧版是 Inno Setup 包的卸载方式完全不同。MSI 包不能靠执行 unins000.exe 来卸载得走 msiexec /x。所以实现自动卸载前先要确认旧版确实是 Inno Setup 打的包。怎么确认后面讲注册表时一起说。2. 安装状态检测AppId 与注册表里的卸载线索2.1 AppId 是查找旧安装的唯一线索Inno Setup 在安装包脚本里有一个很关键的字段叫AppId。它的默认值是 script 文件的 GUID每次新建脚本都会自动生成一个。AppId决定了卸载信息在注册表里挂在哪个键下面。Inno Setup 安装完成后会在HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{AppId}_is1或者如果是“仅当前用户”安装模式privilegesRequiredlowest则在HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{AppId}_is1写入一整组卸载相关信息包括DisplayName、UninstallString、QuietUninstallString、InstallLocation、DisplayVersion等。这就是我们判断“旧版是否装过”和“装在哪里”的核心依据。提示AppId一旦在线上发布过就不要随便改。改了 GUID 之后老版本的卸载信息就找不到了新版本会变成“看似全新安装但旧文件还在”的孤儿状态用户手动卸载也没法一次卸干净。我在项目里吃过这个亏后来强制团队把 AppId 写死在脚本里。2.2 读取注册表拿到原安装路径知道了注册表路径接下来就是在 Inno Setup 的 Pascal 脚本代码里读取它。核心代码很简短function GetOldInstallPath(): string; var sPath: string; sAppId: string; begin Result : ; sAppId : {#emit SetupSetting(AppId)}; if RegQueryStringValue( HKLM, SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ sAppId _is1, InstallLocation, sPath) then begin Result : sPath; end else if RegQueryStringValue( HKCU, SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ sAppId _is1, InstallLocation, sPath) then begin Result : sPath; end; end;这段代码的逻辑很直白先查 HKLM再查 HKCU谁有值就用谁。为什么要两个都查因为 Inno Setup 的privilegesRequired设置不同卸载信息存放位置也不同。你无法百分百保证所有用户都是管理员权限安装所以两个根键都要看。InstallLocation就是安装时DefaultDirName实际解析出来的完整路径。如果你在脚本里用了{autopf}、{userpf}这类预定义常量注册表里存的也是展开后的真实路径。注意InstallLocation这个值只有在安装时确实写入了才会存在。理论上DefaultDirName决定了安装路径Inno Setup 也会在卸载信息里写一份但老版本5.x 早期有可能不写。如果读不到InstallLocation可以退一步读UninstallString从卸载命令的参数/DIR里解析路径后面会讲这个兜底方案。2.3 32 位与 64 位注册表视图这一步非常容易踩坑。如果安装包是 32 位的 Inno Setup 程序默认就是 32 位它在 64 位 Windows 上读写注册表时会遇到注册表重定向。简单说32 位进程默认只能看到HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\...而 64 位安装程序写的信息在HKEY_LOCAL_MACHINE\SOFTWARE\...如果你是 32 位安装包去读 HKLM 的SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\...很可能读不到 64 位路径下的卸载信息因为系统给你偷偷重定向到了 WOW6432Node 节点。Inno Setup 的RegQueryStringValue有第 4 个参数Use64bitKey。设置为True时32 位进程也能读写 64 位视图下的注册表。所以代码要改成if RegQueryStringValue( HKLM, SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ sAppId _is1, InstallLocation, sPath, True) then begin Result : sPath; end;这个True就是“我明确要访问 64 位注册表视图”。顺便提醒如果安装包脚本里设置了ArchitecturesInstallIn64BitModeInno Setup 本身会以 64 位模式运行这时候默认就可以直接读 64 位视图。但为了稳妥我建议无论哪种模式都把Use64bitKey显式传值避免团队其他人改配置时把行为搞乱。3. 完整实现覆盖安装时先卸载旧版本3.1 在 InitializeSetup 中完成路径读取Inno Setup 脚本的生命周期里第一个适合干“检测旧版本”这件事的地方是InitializeSetup()函数。它在安装包解压出所有文件之前触发此时 Windows 还没有任何文件占用冲突进程可以放心做检测和判断。我的写法是这样的function InitializeSetup(): Boolean; var sOldPath: string; sOldUninstall: string; iResult: Integer; begin Result : True; // 1. 找到旧版本卸载程序路径 sOldUninstall : GetOldUninstallString(); if sOldUninstall then begin // 没有旧版本直接进全新安装流程 Log(No previous installation found.); Exit; end; // 2. 读取旧版本安装目录供后续逻辑使用 sOldPath : GetOldInstallPath(); if sOldPath then begin Log(Previous installation path: sOldPath); end; // 3. 询问用户是否卸载同时兼容无人值守场景 if WizardSilent then begin // 静默安装模式下直接卸载不弹窗 Exec(RemoveQuotes(sOldUninstall), /VERYSILENT /NORESTART, , SW_HIDE, ewWaitUntilTerminated, iResult); if iResult 0 then begin Result : False; end; end else begin iResult : MsgBox(检测到已安装旧版本是否先卸载 #13#10 卸载完成后将继续安装新版本。, mbConfirmation, MB_YESNO); if iResult IDYES then begin Exec(RemoveQuotes(sOldUninstall), /VERYSILENT /NORESTART, , SW_HIDE, ewWaitUntilTerminated, iResult); if iResult 0 then begin MsgBox(卸载旧版本失败安装已中止。, mbError, MB_OK); Result : False; end; end else begin // 用户拒绝卸载就直接退出安装 Result : False; end; end; end;这段代码把整个核心逻辑都串起来了先找卸载程序找不到就直接走全新安装。找得到先弹窗确认用户同意就静默执行卸载命令等待卸载结束。卸载失败就终止安装不让系统处于半旧半新状态。静默安装模式下不弹窗直接卸载。这里最关键的决策点是ewWaitUntilTerminated。它让安装程序挂起等待卸载程序执行完毕拿到返回值再决定下一步。如果不等待、直接用ewNoWait安装进程和卸载进程会同时工作卸载程序正在删文件、安装程序正在写文件这个冲突画面我不敢细想。3.2 卸载时机的选择Install 前 vs InitializeSetup有同学可能会问为什么不用CurStepChanged(ssInstall)或者[Run]段触发卸载我的回答是只要能把卸载安排在“文件复制开始之前”都可行但 InitializeSetup 是最早、最安全的位置。为什么最早最好因为安装包解压到临时目录里文件都还没往目标盘写。此时执行卸载目标盘上的文件是完整的老版本卸载程序删起东西来不会有“文件被占用”的顾虑当然你自己程序正在运行还是要单说。如果把卸载放在[Run]段那么新版本文件可能已经覆盖了老文件此时卸载程序再跑大概率会提示“找不到文件”或“文件已损坏”用户看到这种卸载报错会非常困惑。CurStepChanged(ssInstall)也曾经是我第一版的做法但它踩了一个问题文件复制前的检查阶段卸载还没执行时安装向导已经让你选了目录和组件。万一你读到的旧路径和用户新选择的路径不一样用户体验非常分裂——明明要“先卸再装”但向导界面看着跟普通覆盖安装没区别。所以最终还是回到InitializeSetup在向导显示之前就处理完旧版本。3.3 卸载命令的参数与返回值处理Inno Setup 自带的卸载程序unins000.exe支持多个参数实际开发中我会关注这几个参数作用建议/SILENT静默卸载但保留进度条窗口交互模式下可以不用直接走程序弹窗/VERYSILENT完全静默卸载不显示任何窗口自动卸载时用它最省心/NORESTART禁止卸载程序触发重启强烈建议安装流程里插一次重启体验很差/SUPPRESSMSGBOXES禁止卸载过程弹出任何消息框自动卸载场景下必须加防止卸载过程中弹一个用户没看到的框卡住/DIR...指定目标目录如果UninstallString里缺了路径或用错位置可以手动指定当旧版本的卸载程序路径里有空格时我们一般用RemoveQuotes处理引号。sOldUninstall读出来通常是这样的C:\Program Files (x86)\MyApp\unins000.exe带不带引号取决于注册表里的存储格式。用RemoveQuotes去掉引号再让Exec自己按正常路径格式执行比较保险。返回值怎么判定Inno Setup 卸载程序正常退出返回 0如果因为安装状态异常或者参数错误返回非 0我们就中止后续安装。这里建议卸载失败时不要在静默模式下弹任何消息框静默模式直接返回 False 让安装退出即可否则用户会看到“半静默”的诡异体验。3.4 卸载完成后的残留文件处理卸载程序正常执行完毕后很多时候会残留一个或几个空目录。原因往往是旧版本卸载时有文件被占用没删干净或者用户自己往安装目录丢过东西。这时候安装新版本就有一个隐患如果你选的新安装路径和旧路径一样残留文件可能在安装向导的“目录已存在”检查中触发警告更坑的是如果残留文件里恰好有同名 DLL新装的文件可能被覆盖或者版本错乱。我的处理方式是卸载结束后再确认一次旧路径是否还存在如果存在就尝试彻底删除function RemoveOldPathIfExists(sOldPath: string): Boolean; begin Result : True; if DirExists(sOldPath) then begin if not RemoveDir(sOldPath) then begin // 目录不为空或者被占用至少清到能删则删 Log(Warning: old path still exists and cannot be removed: sOldPath); end; end; end;注意这里只做“尽力而为”的清理别强制递归删除。万一用户把个人文件放进了安装目录你一刀切删光就会引发投诉。真实项目里我会在卸载完成后检查一下卸载程序是否已经把文件清干净如果还有少数残留记录下来不阻塞安装流程。4. 获取原安装路径的进阶方案4.1 从 UninstallString 中解析目录前文提到了InstallLocation的读取但老版本可能没有写这个值或者注册表项被别人改了。这时候兜底方案是解析UninstallString里的/DIR参数function ParseDirFromUninstallString(sUninstall: string): string; var iPos: Integer; sTemp: string; begin Result : ; iPos : Pos(/DIR, sUninstall); if iPos 0 then begin sTemp : Copy(sUninstall, iPos 5, Length(sUninstall) - iPos - 4); // 去掉首尾引号 if (Length(sTemp) 2) and (sTemp[1] ) and (sTemp[Length(sTemp)] ) then begin sTemp : Copy(sTemp, 2, Length(sTemp) - 2); end; Result : sTemp; end; end;这个解析逻辑不算复杂但有一个坑路径里如果包含处理起来要小心。所幸 Inno Setup 生成的卸载命令里目录参数一定会用引号包起来所以按引号处理就够用。4.2 多实例安装的判断有些软件允许用户同时装多个实例比如不同版本共存Inno Setup 卸载信息里会以{AppId}_is1、{AppId}_is2这样的递增编号出现。如果你要处理的是“检测到任意旧版本就卸载”那么读取卸载信息时需要遍历_is1、_is2……而不是只查一个键。实现上可以写一个循环function FindAllOldInstalls(): Integer; var iIndex: Integer; sSubKey: string; sUninstall: string; begin Result : 0; iIndex : 1; while True do begin sSubKey : SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ {#emit SetupSetting(AppId)}_is IntToStr(iIndex); if RegQueryStringValue(HKLM, sSubKey, UninstallString, sUninstall, True) then begin Log(Found install # IntToStr(iIndex) : sUninstall); Result : Result 1; end else Break; iIndex : iIndex 1; end; end;不过大多数产品只会有一个安装实例这个遍历是防御性写法。如果你确定自家产品只允许单实例那直接查_is1就够了别画蛇添足。4.3 用户级与机器级安装的注册表差异Inno Setup 的安装权限模式会影响写注册表的位置。privilegesRequiredadmin时写 HKLMprivilegesRequiredlowest或poweruser时可能写 HKCU。真实环境中经常遇到“之前是管理员装的这次是非管理员跑安装包”的情况。这种情况的典型表现是读 HKLM 读不到读 HKCU 也读不到。不是没装过而是记账位置不匹配。面对这种混乱状态我会再做一层判断同时查两个根键下的DisplayName跟当前 AppId 是否匹配命中任何一个都认为是“旧版本已存在”。5. 常见问题与排查技巧实录5.1 问题速查表现象可能原因解决方案总是找不到旧版本AppId 对不上或者注册表视图选错检查 AppId 是否变更32 位包读 64 位注册表要补True卸载程序执行返回非 0卸载程序路径带引号导致解析失败用RemoveQuotes处理路径后再Exec卸载过程中弹窗卡住卸载参数漏了/SUPPRESSMSGBOXES自动卸载场景务必加上卸载完成后旧目录还在有文件被占用或用户放置了额外文件不要强制删记录日志即可用户取消卸载后继续安装逻辑里没写Result : False用户取消必须中止安装安装包在 UAC 提权前后行为不一致32 位包和 64 位注册表重定向问题用Is64BitInstallMode分支处理新版装完旧版还能找到安装顺序或卸载时机不对新版覆盖了旧文件确保卸载在InitializeSetup中执行完毕5.2 卸载后安装路径选择还有一个实际项目里很容易被埋坑的细节卸载执行完毕后Inno Setup 的DefaultDirName如何确定如果你的安装包脚本里DefaultDirName是固定的那没问题。但如果你允许用户在向导页上自选安装路径那么覆盖安装场景下用户新选的路径可能和旧路径不同。卸载旧版本时旧路径上的文件被清空但新版本装到了新路径等于一台机器上出现了两个目录文件名还都叫 MyApp.exe。这个不是 bug但很容易被用户告状。我的建议是在InitializeSetup拿到旧路径后如果用户没有手动改路径即WizardForm.DirEdit内容还是默认值就悄悄把旧路径塞进去作为默认值如果用户改了那就尊重用户选择不做强制。实现片段procedure CurPageChanged(CurPageID: Integer); begin if CurPageID wpSelectDir then begin // 仅当用户还没手动修改时用旧路径覆盖默认路径 if sOldInstallPath then begin WizardForm.DirEdit.Text : sOldInstallPath; end; end; end;这样既能保证覆盖安装时路径一致性又不限制用户主动更换目录。5.3 卸载程序被杀掉后再次检测实际生产环境有个老哥遇到一个问题卸载程序在自动执行时被安全软件拦截用户看到卸载进程一直被查杀最后系统里的旧版本“看不见了”卸载信息被清了一部分但文件还在。这种情况下安装包重新跑一次GetOldUninstallString可能已经读不到卸载命令了但InstallLocation或者文件还残留。我当时的处理是在检测完注册表之后再补一道文件检测if FileExists(sOldPath \unins000.exe) then begin // 注册表信息被清理但卸载程序仍在继续走卸载流程 sOldUninstall : sOldPath \unins000.exe; end;这种做法有点暴力但对于“卸载到一半被打断”的场景很管用。6. 实际项目中的一些经验心得这套“先卸后装”的流程我已经在三个项目里落地过最典型的是一套内网工具软件用户基数不大但升级频率很高没有这套机制前售后群天天有人反馈“升级完打不开”、“两个版本混在一起”。改成先卸后装之后这类问题基本绝迹。分享几个实操经验第一个经验是关于卸载日志。Exec执行卸载程序时Uninstall 程序默认会写日志但生成位置不固定。我建议在卸载命令里加上/LOG...路径...参数把日志写到公共目录比如{tmp}或系统临时目录这样一旦后面安装或运行出问题可以拉着卸载日志一起排查。第二个经验是关于静默卸载的版本兼容性。旧版可能是非常老的 Inno Setup 打的包比如 5.3.3它的 unins000.exe 不一定支持/VERYSILENT以外的参数组合。如果发现旧的卸载程序对/SUPPRESSMSGBOXES识别不好就会返回错误。为了让兼容性最大化我的自动卸载命令通常后面挂一个/NORESTART就好其他参数根据实际测试情况再加。第三个经验是安装包自身版本与旧版本 AppId 的一致性。很多团队在项目初期随便复制了一个 Inno Setup 脚本改了下名称和版本号就发布了根本没管 AppId。等后面做成“检测旧版再卸载”时发现 AppId 早换过好几次了老用户机器上的卸载信息全不在当前 AppId 下面。这时候你写多少代码都找不到旧版。所以如果你现在还能改 AppId务必在第一个对外发布版本就定死它后续永不修改。第四个经验是卸载后和目标目录的冲突判断。有些项目卸载完成后旧目录因为文件占用没法删干净新版本又恰好要往这个目录写文件结果安装过程中 Windows 报“文件夹访问被拒绝”。这个问题的根因在于卸载结束后到文件复制前的时间窗太短某些系统进程杀软、索引服务还没释放句柄。我的处理方式是在卸载后加一个短暂等待比如Sleep(200)给系统一点缓冲时间实测有效降低了这种“偶发装不上”的问题。7. 留给你的动手建议如果你现在正好要改手上的 Inno Setup 安装包我建议按这个顺序动手一是在当前脚本里把AppId固定下来不要让它跟着工程文件 GUID 乱跳。二是先写一个只读旧路径和卸载字符串的函数用日志把读到的值打出来确认你能在目标环境里拿到正确信息。三是再写卸载调用先跑一遍完整安装流程确认卸载、安装、注册表清理全链路没有报错。最后再考虑静默模式、多实例这些进阶场景。另外有个细节建议代码里所有注册表读取都明确传True或False给Use64bitKey参数不要用默认值。我之前见过同事的代码漏传这个参数在 32 位和 64 位系统上表现不一致排查了整整一个下午。最后再分享一个技巧在InitializeSetup里做的所有判断最好都打日志。Inno Setup 的Log()函数会把信息写到安装日志里配合命令行/LOG参数可以导到指定文件这个日志在用户反馈“安装失败”时是排查第一现场的最强武器。我实际用下来这套方案在普通内网软件、商业桌面产品上都表现稳定。只要你把 AppId 守死、注册表路径读对、卸载时机放准基本不会有意外。如果你们项目里还有更独特的场景——比如旧版是 MSI 安装包、或者要基于某个注册表 Key 做条件卸载那就在这个框架上加分支逻辑核心思路是一样的。
