简短答案： 可移植性 。
同时
__arglist，
__makeref和
__refvalue被 语言扩展
，并在C＃语言规范没有证件，用于实现它们的罩下的构建体（
vararg调用约定，
TypedReference类型，
arglist，
refanytype，
mkanyref，和
refanyval指令）是完全在记录CLI规范（ECMA-335）在在 可变参数库 。
通过在Vararg库中进行定义，可以很清楚地看出它们主要是为了支持可变长度的参数列表，而没有太多其他功能。变量参数列表在不需要与使用varargs的外部C代码进行接口的平台中几乎没有用。因此，Varargs库不是任何CLI配置文件的一部分。合法的CLI实现可能选择不支持Varargs库，因为它不包含在CLI内核配置文件中：
4.1.6瓦拉格
所述 可变参数的功能集 支持可变长度参数列表和运行时类型的指针。
如果省略：
尝试使用vararg调用约定或与vararg方法关联的签名编码（请参阅分区II）引用方法的任何尝试都将引发System.NotImplementedException异常。使用CIL指令的方法arglist，refanytype，mkrefany，并refanyval应抛出System.NotImplementedException异常。没有指定异常的确切时间。类型System.TypedReference不需要定义。
更新（回复GetValueDirect
评论）：
FieldInfo.GetValueDirect是
FieldInfo.SetValueDirect是 不是 基类库的一部分。请注意，.NET
framework类库和基类库之间存在差异。BCL是实现CLI / C＃的唯一必要条件，并且在ECMA TR /
84中进行了记录。（实际上，
FieldInfo它本身是反射库的一部分，并且也不包含在CLI内核配置文件中）。
一旦在BCL之外使用了一种方法，就会放弃一些可移植性（随着非Silverlight和MonoTouch等非.NET
CLI实现的出现，这一点变得越来越重要）。即使实现想要增加与Microsoft .NET
framework类库的兼容性，它也可以简单地提供
GetValueDirect并
SetValueDirect接受一个，
TypedReference而不必进行
TypedReference运行时的特殊处理（基本上，使它们等效于它们的
object对应物，而没有性能上的好处）。
如果他们用C＃对其进行了记录，则至少会产生以下几点影响：
- 像任何功能一样，它 可能会 成为新功能的障碍，尤其是因为该功能实际上并不适合C＃的设计，并且需要怪异的语法扩展和运行时对类型的特殊处理。
- C＃的所有实现都必须以某种方式实现此功能，对于完全不在CLI之上运行或在没有Varargs的CLI之上运行的C＃实现而言，它不一定是琐碎/可能的。
