用ShellLink创建.lnk文件必须引用COM组件，因快捷方式本质是COM对象，C#需通过IShellLink接口操作，否则编译报CS0246错误；解析失败多因路径变动、网络路径权限或线程模型不匹配。
用 ShellLink 创建 .lnk 文件必须引用 COM 组件
Windows 快捷方式本质是 COM 对象，C# 里不能靠纯 .NET 类库直接生成，得走 IShellLink 接口。不引用 COM 互操作程序集，编译就报错：CS0246: 未能找到类型或命名空间名 "IShellLink"。
实操建议：
- 在项目中右键「添加引用」→「COM」→ 勾选
Windows Script Host Object Model（更轻量）或Microsoft Shell Controls And Automation（功能全但依赖略重） - 或者用
tlbimp手动导入shell32.dll，但容易因系统版本差异导致InvalidCastException - 代码里必须加
using IWshRuntimeLibrary;或using Shell32;，否则类型不可见
IShellLink.Resolve 解析快捷方式失败的常见原因
调用 Resolve 后目标路径仍是空或返回 ERROR_FILE_NOT_FOUND，不是代码写错了，而是 Windows 的解析策略在起作用。
常见错误现象与应对：
- 目标文件被移动或重命名 →
Resolve默认只尝试一次，且不自动更新 lnk 文件本身；需手动调用SetPath再Save - 快捷方式指向网络路径（
\servershare）→ 当前用户没映射驱动器或未登录域，Resolve直接失败；改用GetPath读原始字符串更可靠 - 运行环境是服务账户或无桌面会话 → COM 初始化失败，
CoInitializeEx必须设为COINIT_MULTITHREADED，否则Resolve返回E_FAIL
读取快捷方式里的工作目录、参数、图标要用不同接口
IShellLink 只管路径和描述，工作目录（WorkingDirectory）、命令行参数（Arguments）、图标路径（GetIconLocation）得靠 IPropertyStore 或额外调用 IShellLink.GetIDList + 解析 PIDL —— 但后者太底层，日常够用的是前者。
实操要点：
-
WorkingDirectory和Arguments可直接从IShellLink实例调用对应属性获取，无需额外 COM 查询 - 图标信息藏在
IPropertyStore里，键是PKEY_IconResource，但 .NET 没内置定义，得用Guid+PROPVARIANT手动取；更简单的方式是调用IShellLink.GetIconLocation，它返回图标路径和索引 - 注意：有些 lnk 文件图标字段为空，
GetIconLocation会 fallback 到目标 exe 的默认图标，这不是 bug，是 Windows 行为
跨平台或 .NET Core/6+ 项目里没有现成替代方案
System.IO 不支持 .lnk，Microsoft.Win32.TaskScheduler 管任务不碰快捷方式，.NET Standard 里也没有抽象封装。这意味着：
- 即使你用
dotnet publish -r win-x64，只要跑在 Windows 上，仍得走 COM；Linux/macOS 下直接抛PlatformNotSupportedException - 在 ASP.NET Core 后台服务里创建 lnk 要特别小心：必须确保 IIS/Windows Service 运行账户有桌面交互权限（默认禁用），否则
CoCreateInstance失败 - 如果只是想“读”路径，最轻量办法是跳过 COM，直接解析 lnk 文件头（前 20 字节校验 + 0x14 偏移处的 flags 字段），但无法获取参数、工作目录等高级字段
真正麻烦的从来不是怎么写几行代码，而是 COM 生命周期管理、线程模型匹配、以及 Windows 用户上下文对快捷方式行为的隐式约束——这些点不提前踩一遍，上线后出问题根本看不出日志在哪。
