CLR Export Archive

clr_archive/ 保存了 ExtremeEngine 原有 RTTR → CoreCLR 导出与调用链中已退出活动工程的源码。它的目标是保留实现依据、接口形状与恢复线索，方便后续人工整理并迁移到独立仓库；它不是一个已经修复引用、可以原地构建的独立产品。

状态基线：2026-07-19。本文描述的是当前归档源码与同一工作树中的活动接缝。后续迁移时应以版本控制中的具体提交为准。

• clr_archive/ 当前不由 SB、BuildScripts LSP、EngineTools.sln[x] 或核心模块构建规则发现。
• 归档的是 C# 专用元数据扩展、手写 CS_* 原生 C ABI、托管运行时与绑定生成器，以及对应数学绑定产物和 CLR 测试程序。
• 活动工程继续保留共享 SkrRTTR/export 数据结构、ScriptBackend、CSharpBackend、Script Meta/mixin 设施、SB 通用 C# 构建能力和 GenMath。
• 归档后的目录布局与原工程不同，多个 .csproj 仍保存旧相对引用；Sakura.TestCLR 还包含旧环境的硬编码动态库路径。因此本目录当前不可视为可直接构建或运行的解决方案。
• Generated/、Export/ 与 *.gen.cs 是理解生成契约的重要样本，但恢复时应在工具链可运行后重新生成，并审查差异，而不是默认这些产物仍与活动 RTTR ABI 同步。

完整文档位于 docs/：

1. 归档范围与活动边界：为什么归档、归档了什么、明确保留了什么。
2. 系统架构与端到端数据流：构建期、生成期和运行期如何串联。
3. C# Meta 扩展与原生 C ABI：cs_* 标记、RTTR flags、CS_* 导出和后端连接。
4. 托管运行时与对象生命周期：NativeProc、RTTR 包装、代理、所有权和回调。
5. C# 绑定代码生成：Sakura.CppExport 与 Sakura.GenExport 的输入、分类和输出。
6. 数学类型、生成产物与 CLR 测试：归档数学代码与仍保留的 GenMath 的边界，以及测试覆盖。
7. 恢复与迁移操作手册：按依赖顺序恢复、建立验证门禁。
8. 源码清单与证据索引：目录职责、原路径和关键一手源码。
9. 已知限制、风险与待验证项：哪些内容已经由源码确认，哪些必须在恢复环境中复验。

构建产物与本地缓存（例如 bin/、obj/、.vs/）不属于归档内容。

下列代码没有被归档，也不应在清理 clr_archive/ 时顺带删除：

• engine/modules/core/core/include/SkrRTTR/export/export_data.hpp：共享 RTTR 导出数据与 Script/Editor 等通用 flags；C# 专用 flags 已从当前活动定义移除。
• engine/modules/core/core/include/SkrRTTR/script_backend.hpp 与 script_backend.cpp：脚本后端抽象和全局活动后端槽位。
• engine/modules/core/core/include/SkrRTTR/csharp_backend.hpp 与 csharp_backend.cpp：CoreCLR backend/mixin 函数表实现。
• engine/tools/SB/SB.Meta/Generators/MetaGeneratorCore.Script.cs：Script Meta 生成能力。
• SB 的 CSharpTarget、CSharpCompileEmitter 等通用 C# 构建基础设施。
• engine/tools/GenMath/：C++ 与 C# 数学类型生成器；它与这里归档的 C# 数学结果不是同一个边界。

当前核心模块不再编译 src/csharp/build.*.cpp，所以保留的 CSharpBackend 没有通过本归档的 CS_CSharpBackend_Connect 暴露给托管端。该“实现仍在、专用入口已断开”的状态是本次边界决定的结果，不应误判为遗漏。

• 原生和托管侧各有 213 个同名 CS_*，名称集合完整对应，但 CS_RTTRType_TypeId 已确认存在 native void / managed IntPtr 返回类型漂移；名称相同不代表 ABI 正确。
• NativeProc 默认使用 SuppressGCTransition；TryUnlockObject 可能在 release 中析构对象并反向调用托管 callback，当前标记组合需要先修正或证明安全。
• ObjectProxyFindOrCreate 尚未实现，native 返回此前未注册 object 的包装路径不完整。
• SkrCoreProcTable.Unload() 只清零函数指针，生成器没有保存并 NativeLibrary.Free 自己加载的 handle；不要宣称支持热卸载/重载。
• 当前树和 Archive 都缺少生产 TestCoreCLR native fixture 的源码/target；现有 TestCLR 又没有断言且硬编码旧路径，不能作为可重建的自动化测试。
• 未发现 hostfxr/nethost 等 CoreCLR hosting 实现。历史形态是 .NET 程序加载原生 DLL，而不是引擎负责启动 CLR。

完整风险与验证项见 已知限制、风险与待验证项。

• 查阅实现时优先从文档链接进入源码；文档中的路径均为仓库相对路径，便于迁移后重映射。
• 若只需保存历史，不要修复项目引用或把本目录重新加入解决方案，否则会重新激活已归档能力。
• 若要恢复，先选择恢复目标（原工程或独立仓库），再严格执行 恢复与迁移操作手册。
• 任何 ABI、生成结果或生命周期行为，在通过恢复环境的构建与端到端验证前，都只能视为“归档源码所表达的契约”，不能视为当前引擎支持承诺。

既定方向是把本目录人工清理后迁移到新仓库。推荐将它作为可追溯的实现种子：先保留原始源码与证据，再在新仓库中修复依赖、建立显式的 ABI 版本和自动化测试。不要直接发布现有归档，也不要把生成文件当作唯一事实来源。