c# - Cómo evitar SerializationException: el tipo no se resuelve para el miembro XXX al probar un componente que usa LogicalCallContext
entity-framework configuration (1)
Recientemente comencé a golpear la siguiente excepción en mi código de prueba de unidad (NUnit) cuando EF intenta cargar información desde App.config:
System.Runtime.Serialization.SerializationException : Type is not resolved for member [my type name], [my assembly name]
Esto sucede tanto con el runner GUI de NUnit como con el runner integrado en VSR de R #. Aquí hay una prueba de unidad rápida que reproduce el problema:
[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
{
}
Usando el visor de registro de fusión, encontré que la falla fue el resultado de una
FILE_NOT_FOUND HRESULT
error. Básicamente, parece que abrir la configuración de alguna manera hace que el objeto Foo se envíe al dominio de aplicación original (nunit runner), que luego intenta cargar mi ensamblaje y no puede encontrarlo porque no está en la carpeta bin. De hecho, confirmé que copiar mi ensamblaje en la carpeta bin de NUnit runner es otra forma de solucionar el problema.
En este punto, parece que usar MarshalByRefObject es la mejor opción. Sin embargo, me encantaría estar aquí si hay mejores opciones y / o si alguien puede ofrecer una explicación detallada de lo que está sucediendo y por qué. ¿Hay alguna desventaja al usar MarshalByRefObject aquí?
Esto es diferente a esta pregunta , porque ya he identificado MarshalByRefObject como una solución potencial y estoy tratando de entender el problema con mayor profundidad / entender las implicaciones de MarshalByRefObject . La respuesta a esa publicación es solo una llamada a MarshalByRefObject sin ningún detalle adicional útil.
Creo que esta es una buena explicación de por qué recibes este error.
¿Es posible usar el contexto de llamada lógica dentro de una prueba de unidad en VS 2010?
Busqué cuál es la buena opción esta. Nunca encuentro ninguna respuesta excepto MarshalByRefObject. Entonces, ¿por qué debería heredar su objeto con él? Es buena explicacion
Mariscal por valor
Los objetos solo son válidos en el dominio de la aplicación donde se crean. Cualquier intento de pasar el objeto como un parámetro o devolverlo como un resultado fallará a menos que el objeto se derive de MarshalByRefObject o esté marcado como Serializable. Si el objeto está marcado como Serializable, el objeto se serializará automáticamente, se transportará de un dominio de aplicación a otro y luego se deserializará para producir una copia exacta del objeto en el segundo dominio de aplicación. Este proceso se suele denominar mariscal por valor.
Esta es la fuente. Es bueno para entender los conceptos de serialización de objetos.
https://msdn.microsoft.com/en-us/library/ms973893.aspx
Gracias a esta pregunta he buscado y aprendido cosas buenas.