动态编译库 Natasha 5.0 兼容版本发布

2023-07-25 生活百科

Natasha 5.0 版本已于 2022/10/10 日发布, 此次大版本更迭带来了兼容性支持, 目前 Natasha 可以兼容 standard2.0 及 coreapp3.1 以上版本.

下载使用 NuGet\Install-Package DotNetCore.Natasha.CSharp -Version 5.0.0.

引擎分离该版本分离了编译引擎, Natasha 将根据 <TargetFramework> {NET VERSION} </TargetFramework> 目标版本来适配对外的 API.

【动态编译库 Natasha 5.0 兼容版本发布】单域编译引擎
- 兼容 Standard2.0(Core3.1 以下) 版本, 动态构建将在主域中进行, 您无法体验到多域编程带来的好处, 也无法卸载动态编译输出的程序集.
- 不兼容旧版 Natasha API,旧版 Natasha 仅支持多域编程, 并提供了多域方面的 API, 而单域引擎是从多域引擎分离简化而来, 它将失去一些非必要的 API.

多域编译引擎
- 兼容 Core3.1 以上版本, 支持程序集卸载, 域功能隔离, 插件加载卸载等操作.
- 兼容旧版 Natasha API, 本次升级保留了多域环境应有的 API, 未做改变, .

代码分离本次版本在源码层,分为 MultiDomain / Public / SingleDomain 三部分, 并使用自定义宏 MULTI 来区分单/多域, 从工程文件上做兼容隔离允许 Natasha 后续的升级工作不必过多的关注兼容性代码,多域引擎仍然是 Natasha 未来版本的主战场, 迭代优化工作将在 MultiDomain 文件夹中进行.相比较有特色的 API {OperatorClass}.DefaultDomain/CreateDomain/RandomDomain/UseDomain 单域版仅有 {OperatorClass}.DefaultDomain 一个 API, 单域引擎的编译结果均加载到主域中, 因此也不具备隔离和卸载功能.
使用须知

编译前提 : 使用字符串脚本需要对编译原理有一定的了解, Roslyn 及 Natasha 简化了复杂的理论依据及构建过程, 使用 Natasha 您只需关注3点:
- 元数据管理, 熟悉 Emit / Expression 的同学应该清楚, 在构建过程中可能用到反射, 比如 propertyInfo / fieldInfo / methodInfo, 因为在编程中只关注使用,而忽视了元数据对动态编译的重要性, 从而切换到字符串编译的时候出现各种各样的问题,Roslyn 和 Natasha 同样是需要元数据的, 而元数据的来源有引用程序集,内存程序集,实际程序集, 除内存程序集外元数据均记录在 DLL 文件中, 因此您可以看到一些构建代码是这样: NatashaManagement.AddGlobalReference("1.dll"); 这一步的缺失可能导致错误: 找不到 RuntimeMetadataVersion 的值。找不到包含 System.Object 的程序集，或未通过选项为 RuntimeMetadataVersion 指定值。, 引用管理对程序来讲是有一定负担的, 因为目前还不能从内存程序集中提取元数据, 所以需要以文件方式来添加, 这也导致你发布动态编译的程序时需要有完备的引用文件跟随, 因此会导致您发布的包体积变大, 至于环境需要哪些引用文件我们交给 DotNetCore.Compile.Environment 环境包来解决, 如果您不能很好的管理引用, 请引入该包全面覆盖当前程序的元数据.
- Using 管理, 这关乎着元数据的引用来源, 任何动态构建都是以一个完整类方式进行, 那么完整的类 using 代码是必不可少的一部分, Natasha 的构建模板可以覆盖大部分 using 并有语义过滤处理异常 using, 如果您直接使用 AssemblyCSharpBuilder 来构建代码则需要注意脚本中的 using 部分.
编译环境 : 编译环境包已不在新版的 Natasha 中,推荐使用 Natasha 的 API NatashaManagement.AddGlobalReference/AddGlobalUsing 来管理全局引用及 Using 缓存, 如果您不能很好管理的元数据引用, 请引入 DotNetCore.Compile.Environment 包来解决元数据引用的问题.
经验总结扩展阅读

上一篇：2023年2月14日认干女儿好吗 2023年2月14日是认干女儿吉日吗

下一篇：JuiceFS 元数据引擎选型指南