2012-07-04 8 views
8

Derivé varias clases de varias excepciones. Ahora vs da una advertencia como en el título de esta pregunta.Derivado de Exception classes warning: CA2237: Mark ISerializable types with SerializableAttribute

1. ¿Puede alguien explicar las implicaciones de suprimir esta regla?

2. ¿Puede explicar la regla de here diciendo "No suprima una advertencia de esta regla para las clases de excepción porque deben ser serializables para funcionar correctamente en todos los dominios de la aplicación."?

Gracias.

P.S. Bueno, yo también tengo una respuesta. De hecho, debe marcar las excepciones como serializables. Funcionan bien sin este atributo en el mismo dominio de aplicación. Sin embargo, si intenta atraparlo desde otro dominio, tendrá que ser serializado para cruzar los límites de la aplicación. Y esa es la razón principal que encontré para esto.

Respuesta

12

Esto no es exactamente una advertencia de Visual Studio, es una advertencia producida por la herramienta FxCop. Que puedes ejecutar desde el menú VS Analyze. FxCop es un analizador estático que busca errores comunes en un programa .NET que un compilador no marcará. La mayoría de sus advertencias son bastante oscuras y rara vez son problemas realmente serios, debes tratarlos como "¿has pensado en esto?" tipo de herramienta.

El pequeño factoid que está tratando de recordarle aquí es que la clase Exception implementa ISerializable y tiene el atributo [Serializable]. Lo cual es un requisito bastante difícil, hace que el objeto Base de excepción se pueda serializar en los dominios de la aplicación. Necesario porque Exception no se deriva de MarshalByRefObject. Y es necesario permitir que el código que ejecute en otro dominio de aplicación arroje excepciones que pueda capturar.

Así que FxCop observa que no hizo lo mismo para su propia clase derivada de excepción. Lo cual es realmente solo un problema si alguna vez tiene la intención de tener un código que arroje su excepción ejecutada en otro dominio de la aplicación. FxCop no es lo suficientemente inteligente como para saber si lo haces, así que solo puede recordarte que va mal cuando lo haces. Es bastante raro, así que no dude en ignorar la advertencia cuando aún no sabe si lo hará o si le suena chino.

+0

Después de leer un poco y jugar con los límites de AppDomain .NET de hecho comenzó a dar sus propias excepciones diciendo que estas clases no tienen [Serializable]. Un punto interesante sobre appDomain.CreateInstance (..., classNameForThisDomain, ...) es que crea y ejecuta classNameForThisDomain en un dominio de aplicación distinto del en el que estamos ejecutando solo cuando esta clase se deriva de MarshalByRefObject. ¡Pero si no lo hace, classNameForThisDomain se cargará en el mismo appdomain! – Nickolodeon

0

Si no va a usar múltiples AppDomain en su aplicación, creo que puede ignorarlo o suprimirlo.

+0

¿No todos los programas usan AppDomains? De [documentación de MSDN para 'System.AppDomain'] (https://msdn.microsoft.com/en-us/library/system.appdomain.aspx): *" Las instancias de AppDomain se usan para cargar y ejecutar ensamblajes. implementa un conjunto de eventos que permiten a las aplicaciones responder cuando se carga un ensamblado "*. Parece que cualquier aplicación que cargue un ensamblaje usa AppDomains. Y dado que cada programa probablemente cargaría 'System.dll', la documentación de MSDN implicaría que todo usa dominios de aplicaciones. –

+0

@IanBoyd: Creo que mi objetivo era usar más de 1 dominio de aplicación, es decir, crear el tuyo propio. – abatishchev