Question

当EF尝试从App.config加载信息时，我最近开始在单元测试（NUnit）代码中遇到以下异常：

System.Runtime.Serialization.SerializationException : Type is not resolved for member [my type name], [my assembly name]

NUnit GUI运行器和R＃的VS集成运行器都会发生这种情况。这是一个快速单元测试，可以重现这个问题：

[Test]
public void Test()
{
    // adding 
    // ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
    // here fixes things, probably because the configuration is cached

    CallContext.LogicalSetData("FooSlot", new Foo()); // removing this line fixes things
    ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None); // fails with above exception
}

[Serializable] // removing this gives a different exception complaining that Foo is not Serializable
public class Foo // : MarshalByRefObject // this fixes things
{ 
}

使用融合日志查看器，我发现失败是

的结果

FILE_NOT_FOUND HRESULT

错误。基本上，似乎打开配置以某种方式导致Foo对象被发送回到原来的（nunit runner）app域，然后尝试加载我的程序集并找不到它，因为它不在bin文件夹中。事实上，我确认将我的程序集复制到NUnit runner bin文件夹是另一种解决问题的方法。

此时，似乎使用MarshalByRefObject是最佳选择。但是，如果有更好的选择和/或有人可以提供有关正在发生的事情和原因的详尽解释，我会喜欢这里。在这里使用MarshalByRefObject是否有任何不利之处？

这与this question不同，因为我已经将MarshalByRefObject确定为潜在的解决方案，并且正在尝试更深入地理解问题/理解MarshalByRefObject的含义。该帖子的答案只是MarshalByRefObject的标注，没有任何有用的额外细节。

Answer 1

我认为这是一个很好的解释，为什么你会收到这个错误。

Is it possible to use the logical call context within a unit test in VS 2010?

我搜索了什么是好的选择。除了MarshalByRefObject，我找不到任何答案。那你为什么要用它继承你的对象呢？这是很好的解释

Marshal By Value

对象仅在创建它们的应用程序域中有效。除非对象派生自MarshalByRefObject或标记为Serializable，否则任何将对象作为参数传递或将其作为结果返回的尝试都将失败。如果对象标记为Serializable，则对象将自动序列化，从一个应用程序域传输到另一个应用程序域，然后反序列化以在第二个应用程序域中生成对象的精确副本。此过程通常称为按值编组。

这是来源。它适用于Understading Object Serialization Concepts

https://msdn.microsoft.com/en-us/library/ms973893.aspx

谢谢你这个问题，我搜索并学到了很多东西。

如何避免SerializationException：在测试使用LogicalCallContext的组件时，不会为成员XXX解析类型

1 个答案: