企业官网建设流程全解析

在客户的车间里交付一套 C# 上位机，最尴尬的不是程序有 Bug，而是你双击图标之后，屏幕上弹出一句"需要安装 .NET Framework 4.8 或更高版本"。内网隔离、没有外网、现场只有一台不能随便联网的工控机，这时候你翻遍 U 盘才发现自己只拷了程序目录，没拷运行时。这个场景我遇到过不止一次，后来就彻底改成了把所有东西都打进一个安装包：C# 程序、依赖库、配置文件、以及 .NET Framework 离线安装包本身，插上 U 盘双击一个 exe，从零到能跑，全程不需要外网。

这篇文章讲的就是这套交付方式怎么落地。它不是那种"打开 Visual Studio，右键项目，选择发布"的入门介绍，而是把打包部署里最容易被忽略的一环——运行时怎么跟着走——拆开讲透。涉及的核心内容包括：.NET Framework 为什么不能像 .NET 8 那样自包含、怎么判断目标机器到底缺哪个版本、Inno Setup 和 WiX Burn 两条主流路线的完整脚本、以及静默安装返回 3010 之后到底该怎么办。适合正在做桌面软件交付、工控上位机、内部工具分发的开发者，也适合被"用户装不上框架"这个问题折磨过的运维同学。

1. 把运行时塞进安装包之前，先认清 .NET Framework 的身份

1.1 它不是 DLL，是一套写进系统的"地基"

很多人第一次做这件事时的直觉是：把 .NET Framework 相关的 dll 拷到程序目录旁边不就完了？这个思路在 .NET Core 之后的时代是对的，但在 .NET Framework 上行不通。原因在于 .NET Framework 的运行时（CLR）并不是普通的托管程序集，它包含大量非托管组件，需要注册 COM 组件、写注册表、把mscoree.dll挂到系统加载链上，并且会被多个进程共享。换句话说，它是操作系统级别的共享组件，而不是你的程序私有的一份拷贝。

微软给 .NET Framework 的定位一直是"系统组件"，所以它的安装方式只有一种：通过官方安装程序（或 Windows 功能）装到系统里，全机器共享。你在Program Files里看不到它，因为它藏在C:\Windows\Microsoft.NET\Framework64\v4.0.30319这种系统目录下。

这个特性直接决定了本文所有方案的形态：你没办法"随身携带"框架，只能"随身携带框架的安装程序"。安装包里放的是一个 100MB 左右的 exe，安装时由它自己去完成系统级部署。这一点想通了，后面所有设计的取舍就都好理解了。

顺带说一句：如果你现在还有选择权，用 .NET 8 发布成 self-contained 单文件，确实能彻底绕开这个问题，dotnet publish -r win-x64 --self-contained出来就是一个自包含目录。但存量项目、必须用 WinForms/WPF 某些老控件库、或者依赖只支持 .NET Framework 的第三方 SDK 的场景，短期内还是得走老路。

1.2 目标机器上的三种状态，对应三种处理策略

在做检测逻辑之前，我习惯先把目标机器分成三类，因为不同类别的处理方式完全不同：

第一类和第二类合起来是绝大多数问题来源。Windows 10 从 1903 版本开始内置 .NET Framework 4.8，Windows 11 22H2 之后自带 4.8.1，所以新机器上基本不会缺——但工控行业大量还在跑 Windows 7 SP1 和 Windows 10 早期版本，这些机器就是重灾区。

判断策略的关键点在于：别写"没装就装"这种粗逻辑，要写"低于某个 Release 值就装"。因为 4.8 的安装程序在一个已经装了 4.8 的机器上跑，会直接弹窗告诉你"这台计算机中已经安装了 .NET Framework 4.8 或版本更高的更新"，然后退出。用户看到这个弹窗会以为装错了，体验非常差。

1.3 必须接受的代价：体积、时间和签名

把框架打进去不是没有成本的。.NET Framework 4.8 的离线安装包（英文版ndp48-x86-x64-allos-enu.exe）大约 110MB，中文版体积相近。Inno Setup 用 lzma2 压缩后，整个安装包大概在 55MB 到 75MB 之间——注意，压缩率并不高，因为微软的这个 exe 内部本来就是 CAB 压缩过的自解压包，你压不出太多水分。

安装时长也要提前有个心理预期。在一台机械硬盘的老机器上，装 .NET Framework 4.8 单独就要 2 到 5 分钟，加上文件复制，整个安装过程可能接近 8 分钟。如果你在工控现场交付，最好在安装界面上放一行明确的提示文字，告诉用户"正在安装运行时组件，请勿关闭"，否则八成会有人在第三分钟的时候以为卡死了然后强杀进程——那样留下的就是一堆半成品状态。

还有一个容易被忽视的点是数字签名。你打包出来的整体安装包，最好用代码签名证书签一下。原因不是炫耀，而是当你把一个 110MB 的微软 exe 包进自己的安装包里，整个文件的哈希就变了，SmartScreen 会把它当成"未知发布者"。签名之后这个问题会缓和很多。

2. 先量准尺寸：你的程序到底依赖哪个版本

2.1 从编译输出里读出真实的 TFM 和 supportedRuntime

判断目标框架最可靠的地方不是你的记忆，而是编译产物本身。C# 桌面项目的.csproj里会写<TargetFrameworkVersion>v4.8</TargetFrameworkVersion>，这个值就是项目的最低运行要求。但更值得看的是编译输出的App.config，它会生成类似这样的内容：

<configuration> <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.8" /> </startup> </configuration>

sku里的版本号就是运行时加载器会去核对的目标版本。如果目标机器上装的框架低于它，程序启动时会直接报错，连Main函数都进不去。

我一般会养成一个习惯：在打包脚本里读一遍这个文件，把版本号提取出来，而不是靠人肉记忆。因为项目做久了，中途改过目标框架却忘了同步安装包里的运行时版本，这种事发生频率高得惊人。

2.2 用反编译工具确认第三方库的最低框架要求

你自己的项目是 4.8，不代表第三方库也是。常见的情况是主项目 4.8，但引用的某个老 SDK 是 4.0 编译的；反过来更麻烦——某个库标称支持 4.5，实际用了 4.6.2 才有的 API。

用 ILSpy 或 dotPeek 打开对应的 dll，看程序集的TargetFrameworkAttribute，这是最直接的办法。命令行下也可以用 PowerShell 快速批量扫一遍：

Get-ChildItem .\bin\Release -Filter *.dll -Recurse | ForEach-Object { try { $asm = [Reflection.Assembly]::ReflectionOnlyLoadFrom($_.FullName) $attr = $asm.GetCustomAttributesData() | Where-Object { $_.AttributeType.Name -eq 'TargetFrameworkAttribute' } [PSCustomObject]@{ File = $_.Name Framework = if ($attr) { $attr[0].ConstructorArguments[0].Value } else { '未知' } } } catch { [PSCustomObject]@{ File = $_.Name; Framework = '非托管或加载失败' } } } | Format-Table -AutoSize

扫出来的结果里取最高版本，那就是你安装包真正需要满足的下限。这个动作花不了五分钟，但能避免你把框架装完了程序还是跑不起来的尴尬。

2.3 Release 值对照表：代码里判断版本的正确姿势

写检测逻辑时，不能靠读版本号字符串，因为 .NET Framework 的注册表里没存"4.8"这种字符串。正确的做法是读HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full下的Release这个 DWORD 值，它是个数字，越大版本越新。

常用的对照关系如下，这张表我建议直接贴到你的代码注释里：

判断逻辑就是一句简单的不等式：Release >= 528040就认为满足 4.8 的要求。用最低值做阈值，是因为同一版本在不同 Windows 版本上的 Release 值不同，但都大于等于表中的最小值，用最小值做判断永远不会漏。

有一个坑必须提醒：在 64 位系统上，32 位的安装程序读HKLM会被重定向到WOW6432Node。.NET Framework 的 NDP 键在两个视图里通常都有，但为了万无一失，我在 Inno Setup 里会显式判断系统位数再决定读哪个视图，代码在后面第 4 节给出。

2.4 3.5 和 4.0 这类老框架，情况完全不一样

如果你的程序依赖 .NET Framework 3.5（比如用了某些只支持 2.0 运行时模型的老组件），处理方式跟 4.x 是两码事。Windows 8 之后，3.5 变成了"按需功能"（Feature on Demand），不能再像以前那样直接跑安装程序。

在 Windows 10/11 上启用 3.5 的常规做法是用 DISM 从系统安装镜像的sources\sxs目录里取源文件：

dism /online /enable-feature /featurename:NetFx3 /All /Source:D:\sources\sxs /LimitAccess

这意味着如果你的目标机器里有 Windows 10/11 需要装 3.5，你的安装包里除了 3.5 的离线包，还得考虑带上 sxs 源目录——那个体积又是几百 MB 起步。更现实的做法是：尽量避免依赖 3.5，把项目升级到 4.x。因为 4.0 本身已经在较新的系统上不再被支持，继续留在 3.5 只会让交付越来越难。

3.5 的检测方式也简单，读这个键：

HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5

看Install这个 DWORD 是不是 1。注意这个键在 64 位系统上只存在于 32 位视图，读的时候要用HKLM32。

3. 四条打包路线怎么选，我为什么最后落在 Inno Setup

3.1 Visual Studio Installer Projects：原生但引导能力弱

如果你在 Visual Studio 里装了 "Microsoft Visual Studio Installer Projects" 扩展，就能新建一个 Setup Project。它支持在 "Prerequisites" 里勾选 ".NET Framework 4.8"，然后选择"从与我的应用程序相同的位置下载系统必备组件"，再把离线包放进指定目录。

这条路线的优点是"官方出品，心里踏实"，缺点是生成的是 MSI + setup.exe 的组合，界面非常朴素，安装过程中的自定义能力很差——你几乎没法在安装前弹一个友好的版本检测提示，也做不了复杂的条件分支。而且它需要在每台开发机上装扩展，CI 服务器上配置起来也麻烦。小项目做一次交付可以，批量维护不推荐。

3.2 Inno Setup：脚本可控、单文件输出，中小项目的性价比之王

Inno Setup 是我这些年最常用的方案，原因有三条。

第一，它是脚本驱动的。整个安装行为写在一个.iss文本文件里，可以进版本管理，可以做 diff，可以在 CI 里参数化替换版本号。这比在图形界面里点来点去可靠太多。

第二，它的[Code]段是完整的 Pascal 脚本，能写条件判断、能调外部进程、能读注册表、能自定义安装流程。第 4 节那个"安装前先检查框架版本，低了就静默装，装完再确认一遍"的完整逻辑，就是靠它实现的。

第三，输出是单一 exe，用户拿到就是一个文件，不用管旁边有没有别的目录。

它唯一的门槛是你要接受 Pascal 语法。但其实用到的就那几个函数，看一遍例子就会了。

3.3 WiX Burn：企业级链式安装的正规军

WiX Toolset 的学习曲线陡得多，但如果你需要管理一个"多个前置条件 + 多个 MSI"的复杂安装链，它是唯一正经的答案。它的 Burn 引擎专门用来做 bundle，可以在一个 exe 里串起任意多个安装包，每个包有自己的检测条件和安装命令，失败还能回滚。

企业内部分发、需要走软件资产管理系统、或者安装过程要做成"无人值守 + 日志上报"的场景，WiX 更合适。代价是调试起来比较痛苦，XML 写错一个属性可能只是静默不生效，没有任何报错。

3.4 商用工具：花钱买时间

Advanced Installer、InstallShield 这类工具把上面所有事情都图形化了，包括前置条件检测、离线包内嵌、多语言界面、自动更新。如果你所在团队对安装包的交付质量有硬要求，又不想在脚本上花时间，买个授权是划算的。它们的核心能力和 WiX 是同一层的，只是包了一层好用的壳。

3.5 选型对照表

我的实际选择是：中小项目一律 Inno Setup，需要串多个 MSI 的复杂场景才上 WiX。下面两节把两条路线都给出可运行的样例。

4. Inno Setup 落地：从离线包准备到静默安装全流程

4.1 离线安装包从哪来、放哪、怎么校验

离线包建议从官方下载中心获取，选 "Offline installer" 那个版本，文件名形如ndp48-x86-x64-allos-chs.exe（中文）或ndp48-x86-x64-allos-enu.exe（英文）。微软允许把 .NET Framework 可再发行组件随你的应用程序一起分发，所以放进安装包没有授权问题。

下载完之后一定要校验哈希，因为这是个 100MB 级别的文件，网络传输损坏的概率并不低，而且损坏的表现是安装到一半失败，非常难排查。校验完之后把它放进项目的一个prereq目录：

MyProject/ ├─ installer/ │ └─ setup.iss ├─ prereq/ │ └─ ndp48-x86-x64-allos-chs.exe └─ dist/ <- 程序发布输出

prereq目录要不要进 Git？我的做法是不进，因为 100MB 的二进制文件会让仓库迅速膨胀。改成写一个fetch-prereq.ps1脚本，构建时自动下载并校验哈希，这样既保证了可复现，又不污染仓库。

4.2 检测：不装重复，不装错版本

检测逻辑的核心就是读 Release 值，但要注意视图问题。下面这段 Inno Setup 代码把 64 位和 32 位两个视图都试一遍，哪个读得到用哪个：

const NET48_RELEASE = 528040; function GetNetRelease(): Cardinal; var Value: Cardinal; begin Result := 0; if IsWin64 then begin if RegQueryDWordValue(HKLM64, 'SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full', 'Release', Value) then Result := Value; end; if Result = 0 then begin if RegQueryDWordValue(HKLM32, 'SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full', 'Release', Value) then Result := Value; end; end;

注意HKLM64和HKLM32这两个常量需要 Inno Setup 6.0 及以上版本。如果你还在用 5.x，得换回HKLM加InstallIn64BitMode的写法，会比较别扭，建议直接升级。

用一个独立的函数封装检测的好处是，它可以在安装流程里被调用两次：一次在开始安装前判断要不要装框架，一次在装完之后验证是否真的装上了。第二次验证非常重要，因为静默安装是有可能失败的，如果不验证就往下走，你会在用户那边得到一个"安装成功但程序打不开"的诡异现象。

4.3 用 PrepareToInstall 而不是 [Run]：这一行决定了失败时会不会留烂摊子

这是我最想强调的一个实操点。很多教程会告诉你把 .NET Framework 的安装命令写到[Run]段里，用Flags: runhidden waituntilterminated。这样确实能跑起来，但顺序是错的——[Run]段是在文件复制完成之后执行的，也就是说框架装没装上，你的程序文件已经先落到目标目录里去了。

如果框架安装失败（比如用户点了取消，或者系统版本不支持），结果就是：程序装了一半，快捷方式已经建好了，用户双击打开报错，然后来找你。卸载重装也未必干净。

正确的做法是把框架安装放到PrepareToInstall里。这个函数在 Inno Setup 开始复制文件之前被调用，返回空字符串表示继续安装，返回非空字符串则中止安装并把这个字符串作为错误信息展示给用户。这样一来，框架装不上，你的程序文件就一个都不会被复制，系统保持原样。

function PrepareToInstall(var NeedsRestart: Boolean): String; var ResultCode: Integer; ExePath: String; begin Result := ''; if GetNetRelease() >= NET48_RELEASE then Exit; // 已经满足要求，直接放行 ExePath := ExpandConstant('{tmp}\ndp48-x86-x64-allos-chs.exe'); if not FileExists(ExePath) then begin Result := '未找到 .NET Framework 4.8 离线安装包，安装无法继续。'; Exit; end; if not Exec(ExePath, '/q /norestart', '', SW_HIDE, ewWaitUntilTerminated, ResultCode) then begin Result := '无法启动 .NET Framework 4.8 安装程序。'; Exit; end; case ResultCode of 0: ; // 成功 1641, 3010: NeedsRestart := True; // 成功但需要重启 1602: Result := '已取消 .NET Framework 4.8 的安装。'; 5100: Result := '当前操作系统不支持 .NET Framework 4.8，请先升级系统。'; else Result := Format('.NET Framework 4.8 安装失败，退出码 %d。', [ResultCode]); end; if (Result = '') and (GetNetRelease() < NET48_RELEASE) then Result := '安装程序执行完毕，但仍未检测到 .NET Framework 4.8，请手动安装后重试。'; end;

那段case里的退出码是实测中最常遇到的几个，3010和1641都表示"成功了但要重启"，这两个绝不能当成失败处理。5100是系统版本不支持，这种情况只能让用户升级操作系统。把这几行写进代码，比事后去猜"为什么安装到一半停了"要省事太多。

4.4 完整的 setup.iss 骨架

把上面这些拼起来，一份能直接用的脚本大概长这样。我把关键项都加了注释：

[Setup] AppId={{9A2B7C4D-1111-4222-8333-ABCDEF012345} AppName=MyHmi AppVersion=1.0.0 AppPublisher=MyCompany DefaultDirName={autopf}\MyHmi DefaultGroupName=MyHmi UninstallDisplayIcon={app}\MyHmi.exe OutputDir=Output OutputBaseFilename=MyHmi_Setup_1.0.0 Compression=lzma2/max SolidCompression=yes PrivilegesRequired=admin WizardStyle=modern ArchitecturesInstallIn64BitMode=x64compatible MinVersion=6.1sp1 [Files] Source: "..\dist\*"; DestDir: "{app}"; \ Flags: ignoreversion recursesubdirs createallsubdirs Source: "..\prereq\ndp48-x86-x64-allos-chs.exe"; DestDir: "{tmp}"; \ Flags: deleteafterinstall [Icons] Name: "{group}\MyHmi"; Filename: "{app}\MyHmi.exe" Name: "{autodesktop}\MyHmi"; Filename: "{app}\MyHmi.exe"; Tasks: desktopicon [Tasks] Name: "desktopicon"; Description: "创建桌面快捷方式"; \ GroupDescription: "附加任务：" [Run] Filename: "{app}\MyHmi.exe"; Description: "立即运行 MyHmi"; \ Flags: nowait postinstall skipifsilent

几个细节值得单独说一下。PrivilegesRequired=admin是必须的，因为装 .NET Framework 需要管理员权限。{tmp}目录用来临时存放离线包，配合deleteafterinstall标志，安装结束后 Inno 会自动清理，不会在用户机器上留一个 110MB 的垃圾文件。MinVersion=6.1sp1是给 .NET Framework 4.8 划的系统下限，比这个还老的系统连框架都装不上，不如直接在启动时就拦住。

SolidCompression=yes会让编译时间明显变长（我实测过一次大概三到五分钟），但压缩率会有几个百分点的提升。如果你在 CI 上跑，可以考虑关掉它换取构建速度。

4.5 体积与单文件输出的取舍

打包完之后你会看到一个 60MB 到 80MB 的 exe。这个体积在 2024 年其实不算什么，但如果你的用户是通过某种带宽受限的内网渠道获取安装包，可能就得考虑取舍了。

第一种取舍是分成两个包：主程序包（几 MB）和运行时包（70MB）。主程序包在检测到框架已满足时完全不下载运行时。这需要你的分发渠道支持按需拉取，复杂度上去了。

第二种取舍是只打包框架的 Web 安装器（ndp48-web.exe，只有 1MB 多），代价是目标机器必须能上外网。这个方法在办公室环境很好用，在隔离的工业现场就是废的。

第三种思路是改用 4.6.2 或者 4.7.2 的离线包，如果你只是图个"框架版本别太老"，低版本的离线包体积会小一些，但功能上不会有区别。

我的经验是：先搞清楚交付渠道，再决定体积策略。内网 U 盘交付就老老实实打全量离线包，别折腾；有内部分发平台且带宽稳定，就上双包方案。

5. WiX Burn：需要串多个前置条件时的组织方式

5.1 Bundle / Chain / ExePackage 这三件套的关系

WiX 的 Burn 模型其实很直观。一个Bundle就是最终生成的那个 exe，Chain是它要按顺序执行的一串安装包，ExePackage和MsiPackage是链条上的具体节点。每个节点都可以带自己的检测条件和安装参数。

一个最小可用的 bundle 大概是这样（这里是 WiX v4 的 schema，v3 主要是命名空间和BootstrapperApplicationRef的写法不同）：

<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs" xmlns:bal="http://wixtoolset.org/schemas/v4/wxs/bal" xmlns:util="http://wixtoolset.org/schemas/v4/wxs/util"> <Bundle Name="MyHmi" Version="1.0.0.0" Manufacturer="MyCompany" UpgradeCode="PUT-YOUR-GUID-HERE"> <BootstrapperApplication> <bal:WixStandardBootstrapperApplication Theme="rtfLicense" /> </BootstrapperApplication> <Chain> <ExePackage Id="NetFx48" SourceFile="prereq\ndp48-x86-x64-allos-chs.exe" InstallCommand="/q /norestart" PerMachine="yes" Vital="yes" DetectCondition="NetFx48Release &gt;= 528040" /> <MsiPackage SourceFile="MyHmi.msi" Vital="yes" /> </Chain> </Bundle> <Fragment> <util:RegistrySearch Id="NetFx48Search" Variable="NetFx48Release" Root="HKLM" Key="SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" Value="Release" Result="value" Bitness="always64" /> </Fragment> </Wix>

Vital="yes"表示这个包必须成功，失败就整个中止——框架包必须设成这个。DetectCondition引用的是上面RegistrySearch输出的变量，读注册表拿到 Release 值跟 528040 比。Bitness="always64"是让搜索强制走 64 位视图。

5.2 DetectCondition 写错的典型症状

这个属性写错的表现特别有迷惑性：安装过程看起来一切正常，但框架包被跳过了。原因是检测条件返回真，Burn 就认为"已经装好了，不用装"。

常见的写错方式有三种。第一种是忘记加Result="value"，默认行为只判断键存不存在，而NDP\v4\Full这个键在很老的框架上也可能存在，于是就被误判成已满足。第二种是Bitness没设，32 位的 bootstrapper 去读WOW6432Node下的键，读到一个空值或者旧值。第三种是 XML 里的>符号没转义成>，这个错误编译期会报，反而是最好发现的。

调试这类问题有个小技巧：在ExePackage上加LogPathVariable或者干脆临时把InstallCommand改成带/passive的可见模式，看看框架安装窗口到底有没有弹出来。弹出来了说明检测条件没生效，没弹说明条件写对了。

5.3 一个 Bundle 里同时处理 3.5 和 4.8

如果程序确实需要两个框架（比如某个第三方报表控件依赖 3.5，主程序是 4.8），在 Chain 里加两个ExePackage就行，顺序按依赖关系排。但要注意 3.5 在 Windows 10/11 上不能用 exe 装，得用 DISM，这在 Burn 里要写成带参数的ExePackage，指向dism.exe：

<ExePackage Id="NetFx35" SourceFile="C:\Windows\System32\dism.exe" InstallCommand="/online /enable-feature /featurename:NetFx3 /All /LimitAccess /Source:[SourceDir]sxs" DetectCondition="NetFx35Installed" Vital="no" />

Vital="no"是因为 3.5 装不上时，程序或许还能降级运行，不至于整个安装失败。但这种"能跑但功能不全"的状态最难排查，我倾向于还是设成Vital="yes"，宁可装不上让用户明确知道，也别留下一堆说不清的问题。

6. 实测踩到的坑，以及它们为什么难查

6.1 静默安装返回 3010 之后，系统处在什么状态

3010 的含义是"安装成功，但需要重启才能完成"。.NET Framework 安装到一半需要重启的情况并不罕见，尤其是从很老的版本升级上来的时候。

危险的地方在于：返回 3010 之后，注册表里的 Release 值可能已经更新了。也就是说如果你只是简单地检查 Release 值，会以为一切正常，然后继续装程序。但实际的运行时文件可能还没完成替换，程序启动后会报一个非常难懂的异常。

我的处理方式是：如果返回 3010 或 1641，除了设置NeedsRestart，还要在安装完成页上加一句明确的提示，引导用户重启。Inno Setup 里可以在[Setup]段声明RestartIfNeededByRun=no，然后用[Code]里的NeedRestart()配合自己的提示逻辑，控制得更细。

6.2 杀软误报：单文件打包的副作用

把一堆 exe 打成一个 exe，你其实做了一次自解压。这个行为模式和一些恶意软件是重合的，所以国内几个主流杀软对 Inno Setup 生成的包有一定概率报"可疑行为"。

缓解办法有几个：用带签名证书的SignTool对最终 exe 签名；在 Inno 的[Setup]段里加上AppPublisherURL、AppSupportURL这些元信息；如果预算允许，在发布前把包提交到各家的白名单申诉渠道。这些都是体力活，但一次做过之后，后续版本只要签名证书不变，一般不会再被拦。

6.3 老系统上的 SHA-2 依赖

这个坑专门针对 Windows 7 SP1。微软从 2019 年开始用 SHA-2 签名，而 Windows 7 SP1 默认只认 SHA-1。所以在一个没打过补丁的 Win7 SP1 上，你运行 .NET Framework 4.8 的安装包，它会直接报签名验证失败。

解决办法是先装KB4474419和KB4490628这两个补丁。但这两个补丁的安装本身又需要其他前置补丁，形成一条依赖链。我最后的处理方式是：把 Win7 的支持范围收窄到"已打全补丁"的机器，在安装程序启动时检测系统版本，如果是 Win7 SP1 且缺少 SHA-2 支持，直接弹一个说明文档的链接，让现场 IT 先把系统补丁打齐。这比在安装包里塞一整套补丁链现实得多。

6.4 {tmp} 目录的残留问题

用{tmp}存放离线包是很自然的做法，但有个细节：deleteafterinstall这个标志是在安装流程正常结束时才清理的。如果用户在安装中途点了取消，或者安装失败中止，这个文件就留在临时目录里了。

大部分情况下这不是大问题，因为临时目录迟早会被系统清理。但如果用户连续安装多次都失败，你的 110MB 文件就会在磁盘上留好几份。稳妥一点的做法是在[Code]里加一个清理函数，在DeinitializeSetup的时候主动删一次：

procedure DeinitializeSetup(); var Target: String; begin Target := ExpandConstant('{tmp}\ndp48-x86-x64-allos-chs.exe'); if FileExists(Target) then DeleteFile(Target); end;

6.5 卸载时该不该动框架

明确一个原则：卸载你的程序时不要卸载 .NET Framework。

理由很实在。第一，目标机器上可能有其他程序也在用这个框架，你卸掉就把别人搞挂了。第二，卸载框架需要重启，用户体验很差。第三，框架本身占的那点磁盘空间，在今天的硬盘容量面前不值一提。

在 Inno Setup 里，只要你不主动写[UninstallRun]去调用框架的卸载命令，它就不会动。这是默认行为，但值得在团队里形成共识，免得有人觉得"装了什么就得卸载什么"而多写几行代码。

7. 装完之后怎么验收，出问题怎么定位

7.1 一份可以直接照着做的验收清单

每次发布新版本之前，我都会在一台干净的虚拟机里跑一遍下面这套流程。虚拟机最好是快照状态，验完就回滚，保证每次都是"全新机器"。

第三项和第六项是最容易被忽略的。已有 4.8 的场景如果检测逻辑写错，会浪费时间在无谓的框架安装上；中文路径出问题，多数是因为安装脚本里某个地方没加引号，路径一有空格就断开了。

7.2 用日志定位失败到底在哪一环

Inno Setup 支持/LOG="文件名"参数生成安装日志，日志里会记录每一步的动作和返回码。给现场运维配一个带日志的快捷方式，比在电话里问"你当时看到什么提示了"高效太多。

MyHmi_Setup_1.0.0.exe /LOG="%TEMP%\MyHmi_install.log" /SILENT

如果失败发生在框架安装这一环，还可以让 .NET 的安装程序自己输出日志。它的命令行参数里支持/log加上一个路径：

ndp48-x86-x64-allos-chs.exe /q /norestart /log "%TEMP%\netfx48.log"

这个日志会详细记录框架安装过程中每一个组件的状态，能精确定位到是哪个组件失败了。我遇到过一次是目标机器上的 Windows Update 服务被组策略禁用导致的失败，日志里写得很清楚，但在安装界面上只显示一个笼统的错误码。

7.3 给现场运维做一个小诊断工具

装在程序目录里的第三方库版本更换、系统环境变化，都可能让一个原本好用的程序突然打不开。与其每次远程排查，不如在主程序里加一个命令行参数，输出一份环境诊断报告：

using Microsoft.Win32; using System; using System.Reflection; static void DumpEnv() { Console.WriteLine($"OS: {Environment.OSVersion}"); Console.WriteLine($"64-bit OS: {Environment.Is64BitOperatingSystem}"); Console.WriteLine($"CLR: {Environment.Version}"); Console.WriteLine($"Exe: {Assembly.GetEntryAssembly()?.Location}"); using var baseKey = RegistryKey.OpenBaseKey( RegistryHive.LocalMachine, RegistryView.Registry64); using var ndp = baseKey.OpenSubKey( @"SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full"); var release = ndp?.GetValue("Release"); Console.WriteLine($"NET Release: {release ?? "not found"}"); }

现场运维只要把这段输出截图发过来，我基本就能判断问题出在哪一层。这个函数不到二十行，但在实际支持中省下的沟通成本非常高。我甚至把它做成了快捷方式的一个隐藏入口，右键属性里能看到完整的启动参数。

有一点要注意：这个诊断函数本身依赖 CLR 能启动。如果程序连 CLR 都加载不起来，它自然是不会执行的。所以更稳妥的做法是把同样的检测逻辑用 PowerShell 写一份，放在安装目录里作为check-env.ps1，它不依赖 .NET Framework 的任何版本。

如果交付的目标机器数量不多，还有一种更省事的办法：在安装程序的完成页上放一个"复制诊断信息"的按钮，用[Code]里的Clipboard.SetText把检测结果直接放进剪贴板，让用户粘贴给你。这个小功能我加过之后，支持效率提升得比预想中明显。