Mono 4.0发布说明 的草稿目前已经提交，在新版本的诸多变更之中，值得注意的一点是Mono团队开始采纳微软CoreCLR项目中的源代码了。

让我们说得更准确一些，微软实际上一共推出了三个以MIT方式授权的源代码集。

ReferenceSource

CoreFX

CoreCLR

由于CoreCLR项目本身依然还不够稳定，因此Mono团队目前主要专注于ReferenceSource项目中的代码。团队的短期目标是将Mono项目中一些有bug或未完成的组件替换为.NET的对应代码，你可以在Trello网站上 跟踪该项目的进展情况 。

除了Decimal类之外，以下命名空间中的代码也都被替换为ReferenceSource项目中的源代码了：

System.Collections
System.Collections.Concurrent
System.Collections.Generic
System.Collections.Specialized
System.ComponentModel
System.ComponentModel.Design
System.Diagnostic.Contracts
System.Linq
System.Linq.Parallel
System.Text.RegularExpressions
System.Runtime.CompilerServices
System.Threading.Tasks

而其它命名空间中也有多个类的源代码已经整合到Mono项目中了

不再支持的特性

Mono将不再支持生成对应.NET 4.0或更早版本的程序集了，在新的版本中只支持生成.NET 4.5以及基于移动档案的程序集。这一变动引起了那些使用Unity进行开发的使用者的疑虑，因为Unity的开发目前还依赖于某个早期版本的Mono中对.NET 3.5的实现。

新版本也将不再提供对Entity Framework的“内置支持”，因为毕竟大多数用户都会选择使用NuGet下载的EF版本进行开发。与之类似的是，Mono中也不再提供自己的Npgsql驱动了。

性能优化

之前，Mono对于浮点数的操作默认是使用最大精度的。虽然使用64位算法进行32位浮点数操作同样是安全的，但这种方式对于性能会带来不利的影响。因此，新版本中提供了一个选项，可以选择进行32位的计算。

方法的内联也得到了改进。“我们现在能够对最多8个机器字长的数据结构的拷贝进行内联，而之前只支持最多5个机器字长。超过8个字长的数值仍将使用memcpy指令以完成操作”。

此外，对于原子操作的运行方式也有某些地方进行了变更。

现在，JIT能够将框架中的所有原子方法认可为固有方法，并进行内联，这一点利益于平台中某些特定代码的功能。这些方法包括Interlocked和Volatile的所有方法，以及Thread类中的MemoryBarrier、VolatileRead和 VolatileWrite方法。

在x86及64位机器上，Thread.MemoryBarrier的实现方式选择了使用mfence指令，而不是使用lock add rsp,0指令。此外，Interlocked.Exchange的实现使用了xchg [dst], val指令，而不是之前那种更耗性能的lock cmpxchg [dst], val循环方式。

对于使用获取/释放语法的原子方法来说，我们将为这些语法生成内存屏障，而不是使用过于严格的顺序一致性方式。

查看英文原文：Mono Adopts .NET Source Code