Подтвердить что ты не робот

Как избежать SerializationException: Тип не разрешен для члена XXX при тестировании компонента, который использует LogicalCallContext

Недавно я начал использовать следующее исключение в моем unit test (NUnit) коде, когда EF пытается загрузить информацию из App.config:

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

Это происходит как с бегуном GUI NUnit, так и с R # VS-интегрированным бегуном. Вот быстрая unit test, которая воспроизводит проблему:

[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) домену приложения, который затем пытается загрузить мою сборку и не может найти ее, потому что она не находится в папке bin. Фактически, я подтвердил, что копирование моей сборки в папку с бегункой NUnit - это еще один способ устранить проблему.

На данный момент кажется, что использование MarshalByRefObject - лучший вариант. Тем не менее, я бы хотел здесь, если есть лучшие варианты и/или если кто-то может предложить подробное объяснение того, что происходит и почему. Есть ли недостатки в использовании MarshalByRefObject здесь?

Это отличается от этого вопроса, потому что я уже определил MarshalByRefObject как потенциальное решение и пытаюсь понять проблему более подробно/понять последствия of MarshalByRefObject. Ответ на этот пост - это всего лишь выноска MarshalByRefObject без дополнительной дополнительной информации.

4b9b3361

Ответ 1

Я думаю, что это хорошее объяснение, почему вы получаете эту ошибку.

Можно ли использовать контекст логического вызова в unit test в VS 2010?

Я искал, что это хороший вариант. Я никогда не нахожу ответа, кроме MarshalByRefObject. Итак, почему вы должны наследовать свой объект вместе с ним. Это хорошее объяснение

Маршал по значению

Объекты действительны только в домене приложения, в котором они созданы. Любая попытка передать объект в качестве параметра или вернуть его в результате не удастся, если объект не будет получен из MarshalByRefObject или помечен как Serializable. Если объект помечен как Serializable, объект будет автоматически сериализован, перенесен из одного домена приложения в другой и затем десериализован для получения точной копии объекта во втором домене приложения. Этот процесс обычно упоминается как маршал по значению.

Это источник. Это полезно для концепций сериализации подставок

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

Спасибо, этот вопрос я искал и узнал хорошие вещи.