我很确定我错过了一些约束或警告的地方，但这是我的情况。假设我有一个类，我想为它设置一个代理，如下所示:
public class MyList : MarshalByRefObject, IList<string>
{
private List<string> innerList;
public MyList(IEnumerable<string> stringList)
{
this.innerList = new List<string>(stringList);
}
// IList<string> implementation omitted for brevity.
// For the sake of this exercise, assume each method
// implementation merely passes through to the associated
// method on the innerList member variable.
}
我想为该类创建一个代理，这样我就可以拦截方法调用并在底层对象上执行一些处理。下面是我的实现:
public class MyListProxy : RealProxy
{
private MyList actualList;
private MyListProxy(Type typeToProxy, IEnumerable<string> stringList)
: base(typeToProxy)
{
this.actualList = new MyList(stringList);
}
public static object CreateProxy(IEnumerable<string> stringList)
{
MyListProxy listProxy = new MyListProxy(typeof(MyList), stringList);
object foo = listProxy.GetTransparentProxy();
return foo;
}
public override IMessage Invoke(IMessage msg)
{
IMethodCallMessage callMsg = msg as IMethodCallMessage;
MethodInfo proxiedMethod = callMsg.MethodBase as MethodInfo;
return new ReturnMessage(proxiedMethod.Invoke(actualList, callMsg.Args), null, 0, callMsg.LogicalCallContext, callMsg);
}
}
最后，我有一个使用被代理类的类，并且我通过反射设置MyList成员的值。
public class ListConsumer
{
public MyList MyList { get; protected set; }
public ListConsumer()
{
object listProxy = MyListProxy.CreateProxy(new List<string>() { "foo", "bar", "baz", "qux" });
PropertyInfo myListPropInfo = this.GetType().GetProperty("MyList");
myListPropInfo.SetValue(this, listProxy);
}
}
现在，如果我尝试使用反射来访问被代理的对象，就会遇到问题。下面是一个例子:
class Program
{
static void Main(string[] args)
{
ListConsumer listConsumer = new ListConsumer();
// These calls merely illustrate that the property can be
// properly accessed and methods called through the created
// proxy without issue.
Console.WriteLine("List contains {0} items", listConsumer.MyList.Count);
Console.WriteLine("List contents:");
foreach(string stringValue in listConsumer.MyList)
{
Console.WriteLine(stringValue);
}
Type listType = listConsumer.MyList.GetType();
foreach (Type interfaceType in listType.GetInterfaces())
{
if (interfaceType.IsGenericType && interfaceType.GetGenericTypeDefinition() == typeof(ICollection<>))
{
// Attempting to get the value of the Count property via
// reflection throws an exception.
Console.WriteLine("Checking interface {0}", interfaceType.Name);
System.Reflection.PropertyInfo propInfo = interfaceType.GetProperty("Count");
int count = (int)propInfo.GetValue(listConsumer.MyList, null);
}
else
{
Console.WriteLine("Skipping interface {0}", interfaceType.Name);
}
}
Console.ReadLine();
}
}
试图通过反射在Count属性上调用GetValue会抛出以下异常:
System.Reflection类型的异常。TargetException'发生在Mscorlib.dll，但未在用户代码中处理
附加信息:Object does not match target type.
当试图获得Count属性的值时，显然框架正在向下调用System.Runtime.InteropServices.WindowsRuntime.IVector来调用get_Size方法。我不明白这个调用是如何在代理的底层对象(实际列表)上失败的。如果我不使用对象的代理，通过反射获得属性值可以正常工作。我做错了什么?我能完成我想要完成的事情吗?
Edit: Microsoft Connect站点已经打开了一个关于此问题的错误。
我认为这可能是。net框架中的一个bug。不知何故，RuntimePropertyInfo.GetValue方法为ICollection<>.Count属性选择了错误的实现，它似乎与WindowsRuntime投影有关。也许当他们把WindowsRuntime互操作放到框架中时，远程代码被重做了。
我将框架切换到目标。net 2.0，因为我认为如果这是一个错误，它不应该在那个框架中。转换时，Visual Studio删除了我的控制台exe项目上的"Prefer 32位"检查(因为这在2.0中不存在)。
总之，它可以在。net 2.0上运行32位和64位。它运行在。net 4上。64位的X。该异常是在。net 4中抛出的。仅限x32位。这看起来确实像个虫子。如果你可以运行64位，这将是一个解决方案。
注意，我已经安装了。net 4.6，它取代了。net框架v4.x的大部分内容。这可能就是问题出现的地方;在我得到一台没有。net 4.6的机器之前，我无法进行测试。
更新:2015-09-08
在只安装。net 4.5.2(没有安装4.6)的机器上也会发生。
更新:2015-09-07
这是一个较小的复制，使用相同的类:
static void Main(string[] args)
{
var myList = MyListProxy.CreateProxy(new[] {"foo", "bar", "baz", "quxx"});
var listType = myList.GetType();
var interfaceType = listType.GetInterface("System.Collections.Generic.ICollection`1");
var propInfo = interfaceType.GetProperty("Count");
// TargetException thrown on 32-bit .Net 4.5.2+ installed
int count = (int)propInfo.GetValue(myList, null);
}
我也尝试了IsReadOnly属性，但它似乎有效(没有例外)。
关于bug的来源，在属性周围有两层间接，一层是远程操作，另一层是称为MethodDef s的元数据结构与实际运行时方法的映射，内部称为MethodDesc。此映射专门用于属性(以及事件)，其中支持属性的get/set PropertyInfo实例的附加MethodDesc被称为Associates。通过调用PropertyInfo.GetValue，我们将这些关联的MethodDesc指针中的一个传递到底层方法实现，并且远程处理执行一些指针数学运算以在通道的另一端获得正确的MethodDesc。CLR代码在这里非常复杂，我没有足够的MethodTable的内存布局的经验，它持有这些MethodDesc记录，remoting使用(或映射它使用到MethodTable?)，但我想说，这是一个公平的猜测，remoting是抓取错误的MethodDesc通过一些糟糕的指针数学。这就是为什么我们看到一个类似但不相关的(就您的程序而言)MethodDesc - IVector<T>的UInt32 get_Size在调用时被调用:
System.Reflection.RuntimeMethodInfo.CheckConsistency(Object target)
System.Reflection.RuntimeMethodInfo.InvokeArgumentsCheck(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
ConsoleApplication1.MyListProxy.Invoke(IMessage msg) Program.cs: line: 60
System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
System.Runtime.InteropServices.WindowsRuntime.IVector`1.get_Size()
System.Runtime.InteropServices.WindowsRuntime.VectorToCollectionAdapter.Count[T]()
这是一个非常有趣的CLR错误，它的一些内脏在不幸中显示出来。你可以从堆栈跟踪中看出，它正在尝试调用VectorToCollectionAdapter的Count属性。
这个类相当特殊，它的实例永远不会被创建。它是。net 4.5中添加的语言投影的一部分，它使WinRT接口类型看起来像。net框架类型。它与SZArrayHelper类非常相似，SZArrayHelper是一个适配器类，它帮助实现非泛型数组实现泛型接口类型(如IList<T>)的错觉。
这里工作的接口映射是针对WinRT IVector<T>接口的。正如在MSDN文章中提到的，该接口类型被映射到IList<T>。内部的VectorToListAdapter类处理IList<T>成员，vectorcollectionadapter处理ICollection<T>成员。
您的代码强制CLR查找ICollection<>的实现。Count，它可以是一个。net类实现它，也可以是一个WinRT对象，将它公开为vector<>. size。很明显，您创建的代理让它很头疼，它错误地决定了WinRT版本。
如何应该找出哪个是正确的选择是相当模糊的。毕竟，您的代理可以是实际WinRT对象的代理，然后它所做的选择将是正确的。这很可能是一个结构性问题。它的行为如此随机，代码在64位模式下也能工作，这一点并不令人鼓舞。VectorToCollectionAdapter是非常危险的，请注意JitHelpers。UnsafeCast调用，此错误可能被利用。
好吧，通知当局，在connect.microsoft.com上提交错误报告。如果你不想花时间，请告诉我，我会处理的。解决方法很难找到，使用以winrt为中心的TypeInfo类来进行反射没有任何区别。消除抖动迫使它在64位模式下运行是一个创可贴，但很难保证。
我们目前正在用这种脆弱的干预(为代码道歉)来破解这个问题:
public class ProxyBase : RealProxy
{
// ... stuff ...
public static T Cast<T>(object o)
{
return (T)o;
}
public static object Create(Type interfaceType, object coreInstance,
IEnforce enforce, string parentNamingSequence)
{
var x = new ProxyBase(interfaceType, coreInstance, enforce,
parentNamingSequence);
MethodInfo castMethod = typeof(ProxyBase).GetMethod(
"Cast").MakeGenericMethod(interfaceType);
return castMethod.Invoke(null, new object[] { x.GetTransparentProxy() });
}
public override IMessage Invoke(IMessage msg)
{
IMethodCallMessage methodCall = (IMethodCallMessage)msg;
var method = (MethodInfo)methodCall.MethodBase;
if(method.DeclaringType.IsGenericType
&& method.DeclaringType.GetGenericTypeDefinition().FullName.Contains(
"System.Runtime.InteropServices.WindowsRuntime"))
{
Dictionary<string, string> methodMap = new Dictionary<string, string>
{ // add problematic methods here
{ "Append", "Add" },
{ "GetAt", "get_Item" }
};
if(methodMap.ContainsKey(method.Name) == false)
{
throw new Exception("Unable to resolve '" + method.Name + "'.");
}
// thanks microsoft
string correctMethod = methodMap[method.Name];
method = m_baseInterface.GetInterfaces().Select(
i => i.GetMethod(correctMethod)).Where(
mi => mi != null).FirstOrDefault();
if(method == null)
{
throw new Exception("Unable to resolve '" + method.Name +
"' to '" + correctMethod + "'.");
}
}
try
{
if(m_coreInstance == null)
{
var errorMessage = Resource.CoreInstanceIsNull;
WriteLogs(errorMessage, TraceEventType.Error);
throw new NullReferenceException(errorMessage);
}
var args = methodCall.Args.Select(a =>
{
object o;
if(RemotingServices.IsTransparentProxy(a))
{
o = (RemotingServices.GetRealProxy(a)
as ProxyBase).m_coreInstance;
}
else
{
o = a;
}
if(method.Name == "get_Item")
{ // perform parameter conversions here
if(a.GetType() == typeof(UInt32))
{
return Convert.ToInt32(a);
}
return a;
}
return o;
}).ToArray();
// this is where it barfed
var result = method.Invoke(m_coreInstance, args);
// special handling for GetType()
if(method.Name == "GetType")
{
result = m_baseInterface;
}
else
{
// special handling for interface return types
if(method.ReturnType.IsInterface)
{
result = ProxyBase.Create(method.ReturnType, result, m_enforce, m_namingSequence);
}
}
return new ReturnMessage(result, args, args.Length, methodCall.LogicalCallContext, methodCall);
}
catch(Exception e)
{
WriteLogs("Exception: " + e, TraceEventType.Error);
if(e is TargetInvocationException && e.InnerException != null)
{
return new ReturnMessage(e.InnerException, msg as IMethodCallMessage);
}
return new ReturnMessage(e, msg as IMethodCallMessage);
}
}
// ... stuff ...
}
m_coreInstance这里是代理正在包装的对象实例。
m_baseInterface是对象要用作的接口。
这段代码拦截了在VectorToListAdapter和vectorcollectionadapter中进行的调用，并通过methodMap字典将其转换回原来的调用。
条件句部分:
method.DeclaringType.GetGenericTypeDefinition().FullName.Contains(
"System.Runtime.InteropServices.WindowsRuntime")
确保它只拦截来自System.Runtime.InteropServices.WindowsRuntime命名空间中的调用-理想情况下我们会直接针对类型，但它们是不可访问的-这可能应该更改为针对命名空间中的特定类名。
然后将参数强制转换为适当的类型，并调用该方法。参数转换似乎是必要的，因为传入的参数类型是基于从System.Runtime.InteropServices.WindowsRuntime命名空间中的对象调用的方法的参数类型，而不是方法调用到原始对象类型的参数;即System.Runtime.InteropServices.WindowsRuntime命名空间中的对象之前的原始类型劫持了该机制。例如，WindowsRuntime的东西拦截原始调用get_Item，并将其转换为调用Indexer_Get方法:http://referencesource.microsoft.com/#mscorlib/system/runtime/interopservices/windowsruntime/vectortolistadapter.cs,de8c78a8f98213a0,references。这个方法然后用不同的参数类型调用GetAt成员，然后在对象上调用GetAt(同样使用不同的参数类型)——这是我们在Invoke()中劫持的调用，并将其转换回具有原始参数类型的原始方法调用。
如果能够反射VectorToListAdapter和vectorcollectionadapter来提取它们的所有方法和嵌套调用就好了，但不幸的是，这些类被标记为内部。
这对我们来说是有效的，但我敢肯定它充满了漏洞——这是一个反复试验的例子，运行它看看什么失败了，然后添加所需的字典条目/参数转换。我们正在继续寻找更好的解决方案。
HTH