T3项目SharpGLTF依赖问题分析与解决

在T3项目开发过程中，我们遇到了一个关于SharpGLTF库加载异常的典型问题。本文将详细分析该问题的成因、排查过程以及最终解决方案，为开发者处理类似依赖问题提供参考。

问题现象

开发者在测试wip-assemblies分支时，发现点击[LoadGltf]按钮后系统抛出MissingMethodException异常。异常信息显示无法找到SharpGLTF.Schema2.ModelRoot.Load方法，该方法签名应为接收字符串路径和ReadSettings参数。

排查过程

1. 基础检查：首先执行了常规的清理操作，包括运行CleanUp.bat脚本、重新构建解决方案以及删除输出目录，但问题依旧存在。

2. 依赖分析：检查项目NuGet包依赖关系时发现异常情况：

   • Lib项目引用了SharpGLTF.Core 1.0.0-alpha0030版本
   • 而Pixtur项目却引用了AssetRipper相关包 这种不一致的依赖关系可能是问题的根源。

3. 文件系统检查：在Lib项目的依赖文件(Lib.deps.json)中确认了SharpGLTF.Core的引用信息，版本为较旧的alpha版本。

4. 对比测试：测试了项目中其他NuGet包(如RugOSC)的功能，发现工作正常。值得注意的是，RugOSC同时被Core和Lib项目引用，而SharpGLTF仅被Lib引用。

问题根源

经过分析，确定问题的主要原因是：

1. 版本不匹配：Lib项目使用的SharpGLTF.Core版本(1.0.0-alpha0030)过旧，与新版本API不兼容。
2. 依赖隔离：SharpGLTF仅被Lib项目引用，而未被Core项目引用，导致运行时可能加载了错误的程序集版本。

解决方案

最终采取的修复措施是：

1. 将SharpGLTF引用提升到Core项目层级
2. 同时将NuGet包升级到稳定的1.0.4版本

这一调整确保了：

• 所有相关项目使用同一版本的SharpGLTF
• 使用经过充分测试的稳定版本而非alpha版本
• 解决了API兼容性问题

经验总结

1. 依赖管理：在大型项目中，关键依赖最好放在基础项目(Core)中，避免分散引用导致版本不一致。
2. 版本控制：生产环境应尽量避免使用alpha/beta版本的NuGet包。
3. 异常分析：MissingMethodException通常表明存在版本兼容性问题或程序集加载错误。
4. 清理策略：除了常规清理外，有时需要手动删除bin/obj目录以确保完全干净的构建环境。

通过这次问题的解决，我们进一步巩固了对T3项目依赖体系的理解，为后续开发奠定了更稳定的基础。