修改EXE图标或版本信息必须用UpdateResource等Win32 API操作资源段，不可直接复制文件或改写PE头；图标和VERSIONINFO属非托管资源，存于.rsrc节，需严格遵循RT_GROUP_ICON/RT_VERSION结构、UTF-16 LE编码及资源目录树。
修改EXE图标必须用资源编辑器，不能靠File.Copy或重写文件头
直接覆盖 icon 或改写 PE 文件头前几十字节，几乎一定会破坏签名、校验和或导入表，导致系统拒绝执行或杀软报毒。Windows 的图标不是独立嵌入的“图片文件”，而是作为 RT_GROUP_ICON 和 RT_ICON 资源类型，按特定结构存放在资源段（.rsrc）中，且依赖资源目录树索引。
实操建议：
- 用
UpdateResourceWin32 API（通过 P/Invoke）是最稳妥方式，它会自动维护资源目录结构和校验和 - 别用
System.Drawing.Icon.Save()直接写入 —— 它输出的是 .ico 文件格式，不是 PE 资源格式 - 若原 EXE 有数字签名，修改后签名必然失效；如需保留签名，必须用
signtool sign /fd SHA256 /tr ...重新签名 - 调试时先用
ResourceHacker.exe手动试改一次，确认目标资源 ID（比如图标常为IDR_MAINFRAME或101）再编码
C# 调用 UpdateResource 更新版本信息（VERSIONINFO）
版本信息是标准资源类型 RT_VERSION，结构体为 VS_FIXEDFILEINFO，但 C# 没有内置封装。直接手拼二进制容易出错，尤其字节序、对齐和字符串表偏移。
实操建议：
- 用
VerQueryValue先读取原始版本块，确认VS_VERSIONINFO布局是否含StringFileInfo和VarFileInfo - 构造新版本块时，字符串值必须以 UTF-16 LE 存储，并在末尾补零；
szKey字段（如"FileVersion"）也要双字节零终止 - 调用
BeginUpdateResource→UpdateResource→EndUpdateResource三步缺一不可；若中间出错，未调用EndUpdateResource会导致文件句柄泄漏甚至锁死 - 更新后务必用
GetVersionInfo（或命令行powershell "(Get-Item 'xxx.exe').VersionInfo"）验证，别只信返回值
为什么用 ResourceManager 或 Assembly.GetExecutingAssembly().GetManifestResourceStream 行不通
这些 API 只能读取「托管资源」（.resources 文件或嵌入的二进制流），而图标、版本信息、菜单、对话框等属于「非托管资源」（native resources），存储在 PE 文件的 .rsrc 段，运行时由 Windows 资源加载器（FindResource/LoadResource）解析，.NET 运行时根本不碰它们。
常见错误现象：
- 代码编译通过，但执行后图标/版本完全没变 —— 实际压根没操作到正确资源段
- 用
Assembly.LoadFile加载 EXE 后调用GetCustomAttributes，只能拿到程序集级特性（如[AssemblyVersion]），和文件属性里的“文件版本”不是一回事 - 误以为修改
app.manifest或项目属性里的“Assembly Information”就能改已生成 EXE 的版本 —— 那只是编译期注入，对已有文件无效
跨平台或无 Win32 API 环境下的替代方案很有限
.NET 6+ 的 Microsoft.Extensions.ResourceManager 或 ILMerge 类工具均不支持写入原生资源。Linux/macOS 下连 PE 格式都不支持，更无从谈起。
如果必须避开 Win32 P/Invoke：
- 用
rc.exe+link.exe重链接：写 .rc 文件定义图标/版本，再用命令行重建资源段（但需完整构建环境，且会重排节偏移） - 调用外部工具如
ResourceHacker.exe -addoverwrite，通过Process.Start控制，适合 CI 场景但难调试 - 接受限制：仅在构建阶段生成带正确资源的 EXE（用
Icon项目属性 +AssemblyVersion），放弃运行时动态修改
真正麻烦的从来不是“怎么写几行代码”，而是资源块内部的字段对齐、语言 ID 映射、Unicode 字符串表嵌套层级 —— 这些细节错一个字节，UpdateResource 就静默失败，还留不下任何错误码。
