强名称是身份，不是保密措施
强名称包含程序集名称、版本、区域及公钥等信息。它不加密 IL，也不阻止反编译；Microsoft 明确提醒不要把强名称作为安全边界。Authenticode 发布者签名又是另一种机制。先确认你的交付到底要求哪种签名，不要因为仍使用 EXE 扩展名就认定签名有效。
为本服务准备未签名输入
FreeObfuscator 拒绝强名称签名或延迟签名的输入。应单独准备未签名 Release 构建，并保留原发布包。示例命令适合简单 SDK 项目，导入的构建目标、引用身份和多程序集签名策略可能要求专门配置。不要直接清除已发布文件的签名元数据就当成等价版本，更不要上传 .snk、.pfx 或证书密码。
重新签名不是万能的一条命令
先确认所用工具能正确签署转换后的程序集。未签名文件可能没有简单重签命令所需的签名预留空间，因此 sn -R 不是通用方案。依赖程序集签名之后，调用方期待的身份也可能变化。签名、引用更新和打包应在可信本地流水线中作为一个完整发布步骤处理。
验证最终交付给用户的包
对比整个流程前后的程序集身份，并使用适合目标平台的工具验证签名。存在公钥令牌不等于签名有效。运行已有调用程序、插件加载器及安装包，保留可回退版本。如果无法维持签名契约，不要仅因测试程序能加载，就向客户交付未签名替代文件。
dotnet build MyLibrary.csproj -c Release -p:SignAssembly=false -p:DelaySign=false -o ./unsigned-check
# Inspect identity only; this is NOT signature validation:
[System.Reflection.AssemblyName]::GetAssemblyName((Resolve-Path './unsigned-check/MyLibrary.dll')).FullName