将一个对象放置在 ILGenerator 的堆栈顶部

Question

我必须向函数传递一个对象的实例，因此显然所有作为参数的信息都将加载到计算堆栈上 这是我正在寻找的代码，

someClass SomeObject = new someClass();

il.Emit(OpCodes.LoadObject, SomeObject);
il.Emit(OpCodes.CallVirt, MethodInfo Function);


public void Function(Object obj)
{
       Type type = typeof(obj);
       //do something w.r.t to the type
}

我不需要存储在类中的任何信息，只是类型，并且我不能使用任何原始类型来做出我的决定，

最后我读到我可以使用指针来加载类型，使用一些操作码...但我在这里完全迷失了，任何帮助或指向正确方向的指针都会很棒:)

[更新]

好吧，我找到了我自己问题的答案，尝试了一下，有效 不知道这是否是正确的方法，但我可以成功创建一个对象并将其加载到堆栈中并将其传递给函数

ConstructorInfo ci = typeof(SomeClass).GetConstructor(System.Type.EmptyTypes);
IL.Emit(OpCodes.Newobj, ci);
IL.Emit(OpCodes.Call, SomeFunctionMethodInfo);

SomeFunctionMethodInfo 是一个以 Object 作为参数的函数，我成功地将对象传递给函数并且也可以操作它并将类作为对象返回。

我在任何地方都找不到这个例子的参考，只是通过MSDN弄清楚了，我做错了什么还是有什么缺点？ 请专家指正或提供更好的答案

Answer 1

这是其他人在此页面此处和上概述的解决方案的完整实现 ="https://stackoverflow.com/a/35679100/147511">这里。此代码允许您导入或“硬编码”您能够提供到 DynamicMethod 的 IL 流中的任何活动对象引用作为永久烧入的 32-或 64 位“文字”引用。

请注意，这显然不是推荐的技术，此处显示仅用于教育和/或实验目的

如其中一条评论，您无需固定 GCHandle； GC 可以正常移动对象，因为只要句柄保持活动状态，句柄的数字值就不会改变。您可能需要在此处持有 GCHandle 的真正原因是，完成的 DynamicMethod 实例将不会持有引用（实际上也不知道）嵌入在其自身中的句柄。如果没有GCHandle，当/如果对它的所有其他引用超出范围时，可以收集实例。

下面的代码采用了过于谨慎的方法，在使用 GCHandle 结构提取对象引用后故意放弃它（即不释放它）。这意味着句柄——以及目标实例——永远不会被收集。如果您的应用程序有其他方法或手段来保持句柄处于活动状态，请随意依赖这些方法，只要您可以保证句柄在通过此技术发出的 DynamicMethod 的生命周期内存活。 ;在这种情况下，您可以在使用 GCHandle 获取句柄值后释放它（代码已注释掉）。

/// <summary>
/// Burn a reference to the specified runtime object instance into the DynamicMethod
/// </summary>
public static void Emit_LdInst<TInst>(this ILGenerator il, TInst inst)
    where TInst : class
{
    var gch = GCHandle.Alloc(inst);

    var ptr = GCHandle.ToIntPtr(gch);

    if (IntPtr.Size == 4)
        il.Emit(OpCodes.Ldc_I4, ptr.ToInt32());
    else
        il.Emit(OpCodes.Ldc_I8, ptr.ToInt64());

    il.Emit(OpCodes.Ldobj, typeof(TInst));

    // Do the following only if you can elsewhere ensure that 'inst'
    // outlives this DynamicMethod
    // gch.Free();
}

其他人没有提到的这个答案的一个贡献是，您应该使用 Opcodes.Ldobj 指令将正确的运行时类型强制到新的硬编码文字上，如上所示。通过以下测试序列很容易验证这是否是一个好的实践。它生成一个 bool 指示新导入的实例的 System.Type 是否是我们期望的，并且仅在以下情况下返回 true Opcodes.Ldobj 指令存在于上面所示的扩展方法中。

TInst _inst = new MyObject();

// ...
il.Emit_LdInst(_inst);                  //  <-- the function shown above
il.Emit(OpCodes.Isinst, typeof(TInst));
il.Emit(OpCodes.Ldnull);
il.Emit(OpCodes.Ceq);
il.Emit(OpCodes.Ldc_I4_1);
il.Emit(OpCodes.Xor);

在我们粗鲁的 Ldc_I4 / Ldc_I8 推动之后，不需要的是 Conv_I，这似乎即使我们放弃 IntPtr.Size 检查并仅使用 Ldc_I8 始终加载 long，即使在 x86 上也是如此。这再次感谢 Opcodes.Ldobj 平息了此类不当行为。

这是另一个使用示例。这会检查嵌入实例（在 DynamicMethod 创建时导入）与将来随时调用该方法时可能以不同方式提供的任何引用类型对象之间的引用相等性。只有当其久违的祖先出现时，它才会返回true。 （有人想知道重聚会如何进行...）

il.Emit_LdInst(cmp);
il.Emit(OpCodes.Ldarg_0);
il.Emit(OpCodes.Ceq);

最后，关于顶部显示的扩展方法的 where TInst : class 约束的评论。一方面，没有理由以这种方式导入值类型，因为您可以将其字段作为文字导入。然而，您可能已经注意到，使导入工作更加可靠的关键 Opcodes.Ldobj 被记录为用于值类型，而不是我们在这里所做的引用类型。简单的关键是要记住，实际上，对象引用是一个句柄，它本身只是一个 32 位或 64 位的模式，总是按值复制。换句话说，基本上是一个 ValueType。

我已经在 x86 和 x64 上对所有这些进行了广泛的测试、调试和发布，并且它运行良好，到目前为止没有任何问题。

Answer 2

您无法在 IL 中凭空提取引用，除非您将引用编码为 IntPtr 文字，在这种情况下：
       一个。不要这样做
        b.您需要固定，并且
        c.不要这样做。

最好的方法取决于您正在编写的方法的签名。如果它是静态的并且不带任何参数......那么，这有点棘手。就我个人而言，我倾向于将一个对象传递到生成的方法中，并让委托从那里获取它需要的任何外部数据。但另一种方法是生成一个类，并将该方法编写为访问类型上的字段的实例方法。

区别（因此是我的偏好）是，第一个方法（最多）需要一个 object[] 参数，并且您可以使用 DynamicMethod；第二个需要 MethodBuilder、TypeBuilder、ModuleBuilder、AssemblyBuilder 等，因此工作量更大。

我提到 object[] 的原因是，通常您希望生成的方法有一个共同的签名，即使它们需要不同的输入。这使您可以绑定到固定委托类型并使用更快的 Invoke 执行（DynamicInvoke 速度很慢）。

例如：

class SomeType { }
delegate void SomeDelegateType(params object[] args);
public class Program
{
    public static void Main()
    {
        var dn = new DynamicMethod("foo", (Type)null, new[] {typeof(object[])});
        var il = dn.GetILGenerator();
        il.Emit(OpCodes.Ldarg_0);
        il.Emit(OpCodes.Ldc_I4_0);
        il.Emit(OpCodes.Ldelem_Ref);
        il.EmitCall(OpCodes.Call, typeof(Program).GetMethod("Function"), null);
        il.Emit(OpCodes.Ret);
        var action = (SomeDelegateType)dn.CreateDelegate(typeof(SomeDelegateType));

        var obj = new SomeType();
        action(obj);
    }
    public static void Function(object obj)
    {
        Type type = obj.GetType();
        Console.WriteLine(type);
    }
}

如果您不能有输入参数，那么您将不得不使用您创建的类型上的字段 - 这实际上正是编译器所做的，如果您编写（例如）

object someObj = ...
Action action = () => Function(someObj);

创建为：

class <>somehorriblename {
    public object someObj;
    public void SomeGeneratedName() { Function(someObj); }
}
...
var captureClass = new <>somehorriblename();
captureClass.someObj = ...
Action action = captureClass.SomeGeneratedName;

Answer 3

我使用的一种简单方法是获取 GCHandle，然后获取其 IntPtr （通过静态方法 GCHandle.ToIntPtr），然后将其转换为 long 或 integer（使用 ToPointer 或 ToInt64）。

这样我就可以调用 ILGenerator.Emit(OpCodes.Ldc_I8, ptr)。

Answer 4

尚未提及的另一种可能性（通过迄今为止发布的任何一个优秀答案）是将运行时对象引用存储在您自己的实例之一中的某个位置，并发出您的自定义IL< /code> 代码来访问它，您知道您将放置它。

如果相关的（外部）对象实例恰好是每个 AppDomain 的单例，那么这是最简单的，因为您可以在您自己的单例之一中建立一个众所周知的（对您来说）静态字段，您可以从中建立一个静态字段。 IL 当然一定能找到它。

相反，如果您需要在运行时容纳未知数量的外部类型的任意实例，或者如果您无法排除它们的任意延迟（这两种情况似乎都需要某种安排来保持它们的正常性），您仍然可以在全球范围内发布它们，在本例中，以 IL 代码可以理解的某种预先建立的方式将其转换为 Object[]（或其他类型）数组。

如前所述，可能必须有某种方法来协调发布活动（由系统中的某些相关“管理模块”制定）与后续消费（通过定制的 IL，也是您的，但是大概受到方法签名约束），这样 IL 将能够仅根据参数（或任何其他证据）从已发布的数组中区分并选择适当的实例事实上可以访问，或者实际上确实在其（可能是受限的）参数列表中接收。

根据情况，您可能需要选择如何设计已发布实例的单例列表。在所有情况下，IL 使用者都希望永远不会更改已发布的条目，但需要考虑的一个因素是您是否需要多个发布者。选项包括：

• 用所有预期的外部实例预填充一个 readonly 数组一次（即在初始化期间），确保这先于任何自定义 IL< /代码>。显然，这是最简单的计划。
• 使用单调增长的数组（在 AppDomain 生命周期内仅添加外部实例，而不会删除）。这简化了与 IL 的协调，因为数组中的索引一旦发出，就永远不会过期或更改。这还允许将 IL 生成为“set-and-forget”，这意味着在创建时，每个 DynamicMethod 实例都可以直接烧录其相关的数组索引。永久地为双方带来好处：运行时的 DynamicMethod 原则上不能是其内置的 IL，尽可能支持自定义模式，而该列表意味着发布者/管理者既不需要保留创建的DynamicMethod身份，也不需要保留与它发布的外部对象实例相关联的任何信息。
• “一劳永逸”策略的简单性在每个DynamicMethod 都被授予其自己的私有或不同实例的情况下特别有效。
• 如果此处列出的任何动态场景需要线程安全（即，由于存在多个管理器或发布源），则可以通过 无锁并发技术，每个发布者始终使用 Interlocked.Exchange（具有保护性 SpinWait）来交换先前发布的数组的新但严格扩展的版本。
• 如果外部实例确实数量众多且短暂，那么您可能会被迫采用更复杂的方法，其中您发布的实例列表会动态调整。在这种情况下，外来对象的实例仅临时存在于列表中，并且与 IL 代码的协调可能需要使用更复杂的信令或通信方法。
• 请注意，即使根本没有必要，如果外部实例资源昂贵，并且如果在阵列中保留过期实例是唯一的 GC 参考，您仍然可以选择更复杂的“即时”管理方案。防止此类资源被释放和回收。