Unity与.net生态问题

事情始于一个简单的想法，在基于UNITY的游戏开发过程中，我们不可避免的开发大量工具以加快整体工作流运行效率。这其中不可避免的使用UNITY自身的编辑器扩展，于此同时我们会经常使用打包来完成一些批量工作，如配置文件的打包等。事实上相同或者相似的功能在UNITY编辑器和打包机中都会有出现。举一个简单的例子，游戏配置文件来远远EXCEL表，而我们最终使用的可能是转化后的JSON文件或者自定义二进制文件。在当前情况下，我们首选使用NODEJS或者PYTHON这样的脚本语言来进行工具开发，同时部署到打包机当中。一切看上去非常美好。但实际上我们仍然希望在不依赖于打包机而是在本地完成这个步骤。原因在于策划可以在本地快速验证配置的合理性与正确性。想要达到上面的效果，我们尝试统一开发语言，无论是本机还是LINUX打包机均使用c#来完成。这是一个一举两得的方案，但在深入研究.net生态之后，我们不得不放弃这个想法，原因还是来资源.NET生态的一些问题。

首先，想要让C#代码在LINUX上运行，我们就必须使用.NET生态，无论是基于.NET CORE还是MONO。这些是可以实现的，微软也一直以来想要统一.NET生态。而在UNITY中，针对C#环境提供了两种不同的选择，一个是MONO，二另外一个是.NET FRAMEWORK。很显然，我们在开发过中，只要坚定不移的选择MONO环境就可以实现我们的目标。不幸的是，项目中引入了hybridclr这个C#动态热更新解决方案。令人沮丧的是，该方案由于UNITY底层对于DLL核心库引用的问题，导致所有的C#环境必须使用.NET FREAMEWORK环境来进行开发。下面是hybridclr中对于此问题的描述。

Unity在打包过程中，会把对netstandard.dll的引用全部转换最终的mscorlib.dll之类的引用，导致原始代码的引用关系跟最终的引用关系有很大不同。这个差异会导致Generate/All/*下命令会运行出错。同时由于 HybridCLR/CompileDll/*命令编译出的热更新dll仍然引用了netstandard而是不是最终的mscorlib之类的程序集，导致加载和运行热更新dll时，会出现找不到netstandard中类型的错误。因此，HybridCLR默认要求使用Net Framework Api Level。

换一个思路，UNITY是否有计划放弃MONO 和 .NET FRAMEWORK，转而最新的.NET生态中。我查阅了UNITY官方讨论组的相关话题。由于UNITY底层C++和MONO过多的依赖，更多的是EDITOR上的问题，导致.NET生态迁移并没有想象中的简单。相反，官方更关注追赶MONO的版本，这也导致的NUGET和一开始统一C#工具开发的想法在短时期内无法实现。如果UNITY官方能做到跟随.NET环境，那么对应的hybridclr也应该会做相应的调整。这样才能做到工具的跨平台。

如果想在当前阶段强行实现同一套C#工具链运行与UNITY EDITOR和LINUX环境，我们在工程结构设计和编码规范中要耗费大量的经历，主要避免两种不同运行环境所带来的兼容问题，工具的维护成本可能会超出想象，甚至在某些工具链环节中无法实现最终效果。