企业官网建设流程全解析

1. 项目概述：为什么一个.mll插件需要独立安装程序？

在Maya插件开发圈里，我见过太多人把写完的.mll文件直接扔进plug-ins目录就以为万事大吉——结果是同事电脑上打不开、客户现场报错“无法加载模块”、甚至自己重装系统后连调试环境都搭不起来。这根本不是代码问题，而是分发逻辑的缺失。标题里这个“用Visual Studio为Maya .mll做一个简单的窗体安装程序”，表面看是打包工具选择，实则直击工业级插件交付的核心痛点：可复现、可验证、可回滚的部署闭环。

核心关键词“Visual Studio”“Maya .mll”“窗体安装程序”三者组合，已经划定了技术边界的硬约束：这不是Python脚本一键复制，也不是PyInstaller打包的GUI小工具，而是面向Windows平台、需与Maya原生运行时深度耦合、具备图形交互能力的本地化安装载体。它要解决的不是“能不能装”，而是“装得对不对、装完能不能立刻用、出错了能不能一眼看出哪步错了”。比如某次给某高校动画实验室交付骨骼绑定插件，对方IT管理员明确要求：安装过程必须显示Maya版本检测结果、插件依赖项校验状态、注册表写入日志，且失败时能弹出带错误码的中文提示——这些，.mll文件本身完全做不到，必须靠安装程序兜底。

这类安装程序的本质，是开发者与终端用户之间的信任契约界面。它把原本藏在命令行、文档或口头交代里的隐性操作（如修改MAYA_PLUG_IN_PATH环境变量、注册COM组件、写入userSetup.mel钩子），全部显性化、流程化、可视化。我试过三种路径：纯批处理+注册表导入（太脆弱）、Inno Setup脚本（功能强但调试黑盒）、VS自带的Installer Projects（微软官方支持、C++/C#无缝集成、调试器直连）。最终选VS，不是因为它“最新”，而是因为当你的.mll是用C++写的，用同一套编译器链（MSVC）、同一套调试符号（PDB）、同一套Windows SDK做安装包，整个工具链的确定性高到离谱——比如你用VS2019编译的.mll，就必须用VS2019的Installer Project生成安装包，否则运行时可能因CRT版本不匹配直接崩溃，这种细节，只有常年混迹于Maya底层开发的人才踩得明明白白。

适合谁参考？第一类是刚从学校毕业、手握几个.mlldemo但没接触过企业交付流程的开发者；第二类是独立艺术家，想把自己的布料解算插件打包成“双击即用”的产品卖给同行；第三类是团队技术负责人，需要统一规范插件分发标准。它不教你怎么写.mll，但教你如何让写出来的.mll真正活下来、传出去、被用起来。

2. 整体设计思路：为什么不用Inno Setup或NSIS？

很多人第一反应是：“Inno Setup免费又轻量，为啥非要用VS？” 这个问题背后藏着对Maya插件特殊性的误判。Inno Setup确实能复制文件、写注册表、创建快捷方式，但它对Maya运行时环境的感知能力为零。举个真实案例：某次为某影视公司定制的UV展开插件，需要依赖特定版本的OpenSubdiv库（.dll），而该库又和Maya主程序的VC++运行时版本强绑定。用Inno Setup安装时，我们只能静态指定msvcp140.dll路径，但实际Maya 2022用的是msvcp140_1.dll，Maya 2023又换成了msvcp140_codecvt_ids.dll——这些细节Inno的脚本引擎根本无法动态识别，结果就是安装成功，启动Maya时报“找不到指定模块”，排查两小时才发现是DLL版本错配。

VS Installer Project的优势，在于它原生支持自定义操作（Custom Actions），且这些操作能以C#或C++代码形式嵌入安装流程，在关键节点（如“安装前”“安装后”“回滚时”）执行任意逻辑。比如我们可以写一段C#代码，在安装前自动读取目标机器上已安装的Maya版本（通过查询注册表HKEY_LOCAL_MACHINE\SOFTWARE\Autodesk\Maya下的InstallPath键值），再根据版本号动态决定要复制哪个版本的.mll（myplugin_2022.mll还是myplugin_2023.mll），甚至能调用mayapy.exe执行一段Python脚本，验证插件是否能被import maya.api.OpenMaya正常加载。这种“环境感知+动态决策”的能力，是任何声明式安装脚本都无法替代的。

另一个常被忽略的点是调试友好性。Inno的编译错误信息往往像天书：“Error 123 at line 45”，而VS的Installer Project编译失败时，会直接在错误列表里标出C#自定义操作代码中的空指针异常位置，双击就能跳转到源码行。更关键的是，你可以给自定义操作附加调试器——在安装过程中按F5，VS会自动挂载到正在运行的msiexec.exe进程，实时查看变量值、单步执行逻辑。我曾用这招在5分钟内定位到一个因System.Security.Principal.WindowsIdentity.GetCurrent().Name在服务账户下返回空字符串导致的权限判断失败问题，这种效率，是脚本工具永远给不了的。

所以整体设计思路很清晰：以VS Installer Project为容器骨架，用C#自定义操作作为智能引擎，将Maya插件安装拆解为“环境探测→依赖校验→文件部署→注册配置→验证反馈”五个原子步骤，每一步都可监控、可记录、可中断、可回滚。窗体（Form）不是为了好看，而是为了让每个步骤的状态（绿色对勾/红色叉号/黄色感叹号）实时可视化，让用户知道“现在卡在哪”“为什么卡住”“下一步要做什么”。

3. 核心细节解析：窗体安装程序的关键组成与避坑要点

一个合格的Maya.mll安装窗体，绝不是拖几个按钮就完事。它由四个不可分割的核心模块构成：安装向导窗体（UI层）、自定义操作逻辑（业务层）、Maya环境适配器（集成层）、错误诊断中心（保障层）。下面逐层拆解那些文档里不会写、但实操中必踩的坑。

3.1 安装向导窗体：不只是UI，更是状态机控制器

VS Installer Project默认生成的是无界面的MSI包，要加窗体，必须创建一个独立的Windows Forms Application项目（.NET Framework 4.7.2，严禁用.NET Core/.NET 5+，因为MSI自定义操作只支持Framework），然后在Installer Project中引用它。这里第一个大坑：窗体不能直接实例化，必须通过InstallerClass派生类的Commit方法触发。很多新手把窗体代码写在Install方法里，结果安装时窗体一闪而过就消失了——因为Install阶段MSI还在静默准备，UI线程未激活。

正确做法是：在自定义操作项目中新建一个MyPluginInstaller.cs，继承System.Configuration.Install.Installer，重写Commit方法：

public override void Commit(IDictionary savedState) { base.Commit(savedState); // 此时MSI已确认安装成功，可安全显示窗体 Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new InstallationWizardForm()); // 主窗体 }

窗体本身要设计成状态机模式：初始页显示Maya版本探测进度条，探测完成后自动跳转到依赖检查页，检查通过才启用“安装”按钮。我见过最蠢的设计是把所有步骤塞在一个窗体里用TabControl切换，结果用户点错Tab导致环境校验被跳过。正确的UI流必须是线性强制引导，每一步完成才解锁下一步，且每步顶部有清晰的状态指示器（如“✓ Maya 2023 detected”“⚠ OpenSubdiv not found”）。

第二个坑是DPI缩放适配。Maya用户常用4K显示器，Windows缩放设为150%，此时默认窗体文字会糊成一片。必须在窗体构造函数中加入：

this.AutoScaleMode = AutoScaleMode.Dpi; this.AutoScaleDimensions = new SizeF(96F, 96F); // 强制按96DPI基准缩放

否则用户看到的“安装完成”按钮可能只显示一半，这种体验损伤信任感。

3.2 自定义操作逻辑：环境探测的精确实现

Maya版本探测看似简单，实则暗藏玄机。不能只查注册表HKEY_LOCAL_MACHINE\SOFTWARE\Autodesk\Maya\2023\Setup\InstallPath，因为用户可能装了多个Maya版本，或者用的是便携版（不写注册表）。必须采用三级探测策略：

1. 注册表主路径扫描：遍历HKEY_LOCAL_MACHINE\SOFTWARE\Autodesk\Maya\下的所有子键（2020, 2022, 2023...），读取InstallPath，验证该路径下是否存在bin\maya.exe；
2. 环境变量兜底：检查MAYA_LOCATION环境变量是否指向有效Maya目录；
3. 文件系统穷举：扫描C:\Program Files\Autodesk\下所有Maya*文件夹，用File.GetLastWriteTime取最新修改时间的作为候选。

我封装了一个MayaEnvironmentDetector类，核心代码如下：

public static MayaVersion DetectLatestMaya() { var versions = new List<MayaVersion>(); // 1. 注册表探测 using (var key = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Autodesk\Maya")) { if (key != null) { foreach (var subKeyName in key.GetSubKeyNames()) { if (int.TryParse(subKeyName, out int year) && year >= 2020) { using (var subKey = key.OpenSubKey(subKeyName + @"\Setup")) { if (subKey != null) { var installPath = subKey.GetValue("InstallPath") as string; if (!string.IsNullOrEmpty(installPath) && File.Exists(Path.Combine(installPath, "bin", "maya.exe"))) { versions.Add(new MayaVersion { Year = year, Path = installPath }); } } } } } } } // 2. 环境变量 & 3. 文件系统探测（略，逻辑类似） return versions.OrderByDescending(v => v.Year).FirstOrDefault(); // 返回最新版 }

注意：MayaVersion类必须包含Path（Maya安装根目录）、Year（年份）、MllTargetPath（计算出的插件目标路径，如Path + @"\plug-ins"）三个属性，后续所有文件操作都基于此。

第三个致命坑是权限提升时机。安装.mll到C:\Program Files\Autodesk\Maya2023\plug-ins需要管理员权限，但VS Installer默认以msiexec.exe的权限运行，不一定有。必须在Installer Project的Properties里将InstallAllUsers设为True，并在Launch Conditions中添加AdminUser条件，否则普通用户双击安装包会静默失败。我在某次交付中漏了这步，客户反馈“安装没反应”，远程一看日志全是Access is denied，补上权限设置后问题消失。

3.3 Maya环境适配器：让.mll真正“活”在Maya里

复制.mll文件只是第一步，要让它被Maya识别，必须完成三件事：路径注册、初始化脚本注入、依赖DLL部署。这三者缺一不可，且顺序不能错。

• 路径注册：修改MAYA_PLUG_IN_PATH环境变量。但直接Environment.SetEnvironmentVariable只对当前进程有效！正确做法是调用Windows API写入注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment，并广播WM_SETTINGCHANGE消息通知系统。我封装了EnvironmentVariableManager类，关键代码：

[DllImport("user32.dll", SetLastError = true, CharSet = CharSet.Auto)] private static extern IntPtr SendMessageTimeout(IntPtr hWnd, uint Msg, UIntPtr wParam, string lParam, uint fuFlags, uint uTimeout, out UIntPtr lpdwResult); private const uint HWND_BROADCAST = 0xffff; private const uint WM_SETTINGCHANGE = 0x001A; public static void SetGlobalEnvironmentVariable(string name, string value) { Registry.SetValue(@"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment", name, value, RegistryValueKind.String); SendMessageTimeout((IntPtr)HWND_BROADCAST, WM_SETTINGCHANGE, UIntPtr.Zero, "Environment", 0, 5000, out _); }

• 初始化脚本注入：在Documents\maya\2023\scripts\userSetup.mel末尾追加loadPlugin "myplugin.mll";。但要注意：如果该文件不存在，需先创建；如果已存在相同loadPlugin语句，要避免重复添加。我用正则^loadPlugin\s+["']myplugin\.mll["'];?$全局搜索替换，确保幂等性。

• 依赖DLL部署：.mll若链接了OpenSubdiv.dll或自定义mathlib.dll，必须和.mll放在同一目录，或放入C:\Windows\System32（不推荐，污染系统）。最佳实践是创建Dependencies子目录，将所有DLL复制进去，并在.mll的DllMain中用SetDllDirectory(L"Dependencies")临时修改DLL搜索路径。

这三个动作必须按“路径注册→脚本注入→DLL部署”顺序执行，否则Maya启动时可能因找不到DLL而拒绝加载插件。我曾因顺序颠倒，在客户现场花了三小时排查，最后发现是userSetup.mel先执行了loadPlugin，但DLL还没复制过去。

3.4 错误诊断中心：让失败变得可理解

安装失败时，用户看到的不应该是“Error 1603”，而应该是“Maya 2023未检测到，请先安装Maya或检查注册表路径”。这就需要构建一个错误码映射系统。我在ErrorCodes.cs中定义：

public static class ErrorCode { public const int MAYA_NOT_FOUND = 1001; public const int MLL_COPY_FAILED = 1002; public const int USERSETUP_WRITE_FAILED = 1003; public const int DLL_DEPENDENCY_MISSING = 1004; } public static class ErrorMessages { public static string GetMessage(int code) => code switch { ErrorCode.MAYA_NOT_FOUND => "未找到有效的Maya安装。请确认已安装Maya 2020或更高版本。", ErrorCode.MLL_COPY_FAILED => $"无法复制插件文件到Maya插件目录。请检查目标路径{MayaEnvironmentDetector.Current.MllTargetPath}是否有写入权限。", ErrorCode.USERSETUP_WRITE_FAILED => "无法写入userSetup.mel初始化脚本。请确认Maya用户脚本目录可写。", ErrorCode.DLL_DEPENDENCY_MISSING => "检测到缺失的运行时依赖库。请确保已安装Microsoft Visual C++ 2019 Redistributable。", _ => "未知错误。请查看详细日志获取更多信息。" }; }

每次操作后检查返回值，失败时调用EventLog.WriteEntry写入Windows事件查看器，并在窗体上显示ErrorMessages.GetMessage(code)。这样用户截图发来，我一眼就知道问题根源，而不是让他手动翻日志。

提示：所有文件操作必须用try-catch(FileNotFoundException ex)捕获具体异常，而不是笼统的Exception。FileNotFoundException和UnauthorizedAccessException的处理策略完全不同——前者要引导用户检查Maya路径，后者要提示“请右键以管理员身份运行安装程序”。

4. 实操过程详解：从零开始构建可运行的安装包

现在进入实操环节。我会以一个真实的简化场景为例：为名为MyRigTool.mll的绑定工具插件（编译自VS2019，依赖VC++2019运行时）制作安装包。整个过程分为六个阶段，每个阶段都有精确的VS操作路径和参数说明，杜绝“点击下一步”式的模糊指引。

4.1 环境准备：VS版本与SDK的硬性匹配

首先确认你的开发环境：必须使用Visual Studio 2019（社区版即可），因为Maya 2022/2023的官方SDK（ADSK Maya DevKit）只提供VS2019的预编译库。如果你用VS2022，即使强行编译.mll，也会在Maya中报STATUS_ACCESS_VIOLATION——这是CRT堆管理器不兼容导致的。打开VS2019，安装工作负载时务必勾选：

• “使用C++的桌面开发”
• “用于Windows的.NET桌面开发”
• “Visual Studio扩展开发”（Installer Project模板需要）

然后安装Microsoft Visual Studio Installer Projects extension（VS2019专用版，官网搜索下载，不要用VS2022的版本）。重启VS后，新建项目时才能看到“Setup Project”模板。

注意：Maya SDK的devkitBase目录下有一个mayaStubs.h头文件，它定义了MStatus等类型。你的.mll项目必须引用此目录，而Installer Project不需要引用它，但必须确保.mll编译输出路径（如$(SolutionDir)bin\$(Configuration)\）能被安装程序准确找到。

4.2 创建安装项目：结构化组织安装资产

在解决方案中右键 → “添加” → “新建项目” → 搜索“Setup Project”，命名为MyRigTool_Installer。此时解决方案包含两个项目：MyRigTool.mll（你的插件）和MyRigTool_Installer（安装包）。

右键MyRigTool_Installer→ “视图” → “文件系统”，打开文件系统编辑器。这里要建立三层结构：

• Application Folder（应用程序文件夹）：右键 → “添加” → “项目输出”，选择MyRigTool.mll项目的“主输出”，这会自动包含.mll及其PDB符号文件；
• User's Desktop（用户桌面）：右键 → “添加” → “快捷方式”，目标设为[ApplicationFolder]MyRigTool.mll，名称为“卸载MyRigTool”（方便用户快速卸载）；
• User's Programs Menu（用户程序菜单）：同上，添加快捷方式到开始菜单。

关键操作：右键Application Folder→ “属性”，将DefaultLocation设为[ProgramFilesFolder][Manufacturer]\[ProductName]，其中Manufacturer填你的公司名（如MyStudio），ProductName填MyRigTool。这样安装路径就是C:\Program Files\MyStudio\MyRigTool，符合Windows规范。

4.3 集成自定义操作：注入智能逻辑

右键MyRigTool_Installer→ “视图” → “自定义操作”，打开自定义操作编辑器。右键“安装”节点 → “添加自定义操作” → “应用程序文件夹” → 选择MyRigTool.mll项目的“主输出”。此时会生成一个Primary output from MyRigTool.mll (Active)条目。

但这只是壳，真正的逻辑在MyRigTool_CustomActions项目里。新建一个“Windows Forms App (.NET Framework)”项目，命名为MyRigTool_CustomActions，框架选.NET Framework 4.7.2。删除默认的Form1.cs，新建InstallationWizardForm.cs（主窗体）和MyPluginInstaller.cs（安装器类）。

在MyPluginInstaller.cs中，重写Install、Commit、Rollback、Uninstall四个方法。重点看Install：

public override void Install(IDictionary stateSaver) { base.Install(stateSaver); // 保存安装路径供Commit使用 stateSaver["INSTALLDIR"] = Context.Parameters["TARGETDIR"]; // 执行环境探测 var detector = new MayaEnvironmentDetector(); var maya = detector.DetectLatestMaya(); if (maya == null) { throw new InstallException("未检测到Maya安装。错误码：" + ErrorCode.MAYA_NOT_FOUND); } stateSaver["MAYA_PATH"] = maya.Path; stateSaver["MAYA_YEAR"] = maya.Year.ToString(); }

stateSaver字典是MSI进程间传递数据的唯一通道，所有关键信息（Maya路径、年份）都存进去，Commit方法里再取出来用。编译MyRigTool_CustomActions项目，生成MyRigTool_CustomActions.dll。

回到MyRigTool_Installer的“自定义操作”视图，右键“安装”节点 → “添加自定义操作” → “浏览”，选择MyRigTool_CustomActions.dll。此时“安装”节点下会出现Install、Commit等子项。必须将Commit拖到“提交”节点下，Rollback拖到“回滚”节点下，Uninstall拖到“卸载”节点下，否则逻辑不会触发。

4.4 编写窗体逻辑：状态驱动的用户交互

InstallationWizardForm.cs是用户体验的核心。它继承Form，布局用TableLayoutPanel实现响应式网格。关键控件：

• ProgressBar probeProgress：显示Maya探测进度；
• Label statusLabel：实时显示状态文本（如“正在扫描注册表...”）；
• Button nextButton：下一步按钮，初始禁用；
• RichTextBox logBox：滚动日志窗口，记录每步操作。

窗体Load事件中启动探测：

private void InstallationWizardForm_Load(object sender, EventArgs e) { var backgroundWorker = new BackgroundWorker(); backgroundWorker.DoWork += (s, args) => { // 在后台线程执行耗时探测 var detector = new MayaEnvironmentDetector(); var maya = detector.DetectLatestMaya(); args.Result = maya; }; backgroundWorker.RunWorkerCompleted += (s, args) => { if (args.Result is MayaVersion maya && maya != null) { statusLabel.Text = $"✓ 检测到Maya {maya.Year}，路径：{maya.Path}"; nextButton.Enabled = true; } else { statusLabel.Text = "✗ 未找到Maya，请先安装Maya 2020+"; logBox.AppendText($"错误：{ErrorMessages.GetMessage(ErrorCode.MAYA_NOT_FOUND)}\r\n"); } }; backgroundWorker.RunWorkerAsync(); }

点击nextButton后，触发依赖校验和文件部署。校验逻辑调用DependencyChecker.CheckAll(maya.Path)，检查msvcp140.dll、OpenSubdiv.dll是否存在。部署逻辑用File.Copy复制.mll到maya.Path + @"\plug-ins"，并用File.AppendAllText写入userSetup.mel。每步操作后更新logBox，例如：

logBox.AppendText($"[{DateTime.Now:HH:mm:ss}] 开始复制插件...\r\n"); try { File.Copy(mllSource, mllTarget, true); logBox.AppendText($"✓ 插件复制成功：{mllTarget}\r\n"); } catch (Exception ex) { logBox.AppendText($"✗ 复制失败：{ex.Message}\r\n"); throw new InstallException($"插件复制失败。错误码：{ErrorCode.MLL_COPY_FAILED}"); }

4.5 构建与测试：模拟真实用户的完整流程

构建安装包前，必须清理所有残留。在MyRigTool_Installer项目属性中，将Configuration设为Release，Platform设为x64（Maya是64位程序）。右键项目 → “生成”，VS会输出MyRigTool_Installer.msi文件。

测试必须分三步：

1. 干净虚拟机测试：在全新Win10虚拟机中，只安装Maya 2023，双击MyRigTool_Installer.msi，观察窗体流程、日志输出、Maya启动后是否能执行loadPlugin "MyRigTool.mll"；
2. 多版本共存测试：在同一台机器装Maya 2022和2023，运行安装包，确认它自动选择2023并正确部署；
3. 故障注入测试：手动删除msvcp140.dll，再运行安装包，确认弹出“缺失运行时依赖”的精准提示。

我有个铁律：任何安装包在交付前，必须在至少三台不同配置的物理机上完成全流程测试。曾经一个客户用的是老款戴尔工作站，显卡驱动老旧，导致窗体DPI缩放失效，文字全糊，补上AutoScaleMode.Dpi后问题解决。

4.6 卸载与回滚：确保系统状态可恢复

卸载逻辑写在MyPluginInstaller.Uninstall方法中。它必须做三件事：

• 从userSetup.mel中删除loadPlugin行（用正则替换，保留其他内容）；
• 删除plug-ins目录下的.mll文件；
• 清理MAYA_PLUG_IN_PATH环境变量中添加的路径。

关键点：卸载时不能删除整个userSetup.mel文件，只删相关行。代码示例：

public override void Uninstall(IDictionary savedState) { base.Uninstall(savedState); var mayaPath = savedState["MAYA_PATH"] as string; var userSetupPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments), "maya", savedState["MAYA_YEAR"] as string, "scripts", "userSetup.mel"); if (File.Exists(userSetupPath)) { var content = File.ReadAllText(userSetupPath); // 删除loadPlugin行，保留其他内容 var newContent = Regex.Replace(content, @"^\s*loadPlugin\s+[""']MyRigTool\.mll[""'];?\s*$", "", RegexOptions.Multiline); File.WriteAllText(userSetupPath, newContent); } var mllPath = Path.Combine(mayaPath, "plug-ins", "MyRigTool.mll"); if (File.Exists(mllPath)) File.Delete(mllPath); }

回滚（Rollback）方法在安装中途失败时触发，用于清理已执行的操作。比如已复制了.mll但userSetup.mel写入失败，则Rollback中要删除已复制的.mll。这保证了“要么全成功，要么全回滚”，系统状态始终一致。

5. 常见问题与排查技巧实录：那些文档里找不到的实战经验

在给超过30个团队交付Maya插件安装包的过程中，我整理了一份高频问题速查表。这些问题没有标准答案，只有基于血泪教训的排查路径。以下全是真实发生过的案例，附带我的解决思路。

除了表格中的问题，还有三个隐藏极深的坑值得单独强调：

第一个坑：Maya的“延迟加载”机制。有些插件在userSetup.mel中loadPlugin后并不立即初始化，而是等到首次调用其命令时才加载。这会导致用户误以为安装失败。解决方案是在安装完成后，自动在userSetup.mel末尾追加一行MyRigTool_init;（假设你注册了这个MEL命令），强制Maya在启动时执行一次初始化。我在Commit方法中加入：

// 写入初始化命令 var initCmd = "if(!`pluginInfo -q -l \"MyRigTool.mll\"`) loadPlugin \"MyRigTool.mll\";\nMyRigTool_init;"; File.AppendAllText(userSetupPath, initCmd);

第二个坑：防病毒软件拦截。某些国产杀软会将自定义操作DLL识别为“潜在风险”，在安装时静默阻止执行。表现是窗体不出现，MSI日志里有CAQuietExec: Error 0x80070005: Command line returned an error.。解决方案是给DLL添加数字签名。用signtool.exe（VS自带）执行：signtool sign /f mycert.pfx /p password MyRigTool_CustomActions.dll。虽然增加流程，但能避免90%的杀软误报。

第三个坑：Maya版本号解析错误。Maya 2023的注册表键名是2023，但Maya 2022 Update 5的键名可能是2022.5。int.TryParse会失败。我的修复方案是：先用Regex.Match(keyName, @"(\d{4})(?:\.(\d+))?")提取主版本和次版本，再用Version类比较大小。这样2022.5就比2022新，逻辑更健壮。

最后分享一个小技巧：在安装包属性中，将ProductVersion设为1.0.0，UpgradeCode设为一个固定GUID（右键项目→“属性”→“升级代码”），这样后续发布1.0.1版本时，用户双击新MSI，Windows会自动卸载旧版再安装新版，无需手动清理。这个GUID必须永久不变，我把它记在密码管理器里，每次新建项目都粘贴过去。

6. 进阶思考：从安装程序到插件生态的延伸

做到上面的程度，已经能解决95%的交付需求。但如果想走得更远，这个安装程序可以成为插件生态的起点。我最近在帮某动画工作室重构他们的内部工具链，就把安装程序升级成了“插件管理中心”。

核心升级点有三个：版本仓库集成、在线更新推送、使用统计埋点。版本仓库很简单：在安装程序中内置一个CheckForUpdates()方法，访问工作室内网的https://tools.my-studio.com/versions.json，比对本地MyRigTool.mll的文件版本（FileVersionInfo.GetVersionInfo(mllPath).FileVersion）和服务器返回的最新版本号。如果需要更新，弹出对话框：“检测到新版本1.2.0，是否立即下载？（约12MB）”，点击后用WebClient.DownloadFileAsync后台下载，下载完成自动调用msiexec /i new_installer.msi /quiet静默升级。

在线更新解决了“每次发新版都要重新发安装包”的麻烦。而使用统计埋点则帮助团队了解工具真实价值：在Commit方法末尾，用HttpClient发送一个匿名POST请求到分析服务器，携带PluginName=MyRigTool&Version=1.1.0&MayaVersion=2023&OS=Windows10。注意：必须用户授权才发送，首次安装时弹出勾选项“允许发送匿名使用数据以帮助改进工具”，这是合规