2012-01-31 29 views
5

Puede crear una versión .NET 4 de su aplicación para probar fue la inocente pregunta de los jefes, ¡seguro!System.TypeLoadException no se ha manejado/Se han violado las reglas de seguridad de herencia al anular el miembro

Pero después de cambiar nuestros 27 proyectos en nuestra aplicación Windows Forms a .NET 4 y recompilado, al poner en marcha la aplicación, me sale

System.TypeLoadException fue controlada
Mensaje = Herencia reglas de seguridad violadas al reemplazar el miembro: 'MyCustomORM.GetObjectData (System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)'. La accesibilidad de seguridad del método de anulación debe coincidir con la accesibilidad de seguridad del método que se está reemplazando.

Hmmm .....

MyCustomORM en efecto implementar la interfaz ISerializable y por lo tanto tiene este método

[Serializable] 
public abstract class MyCustomORM: IMyCustomORM, ISerializable, ICloneable, ISecurable 
{ 
    public virtual void GetObjectData(SerializationInfo info, StreamingContext context) 
    { 
     // do stuff here....... 
    } 
} 

y también tengo dos clases que se derivan de Exception que anulan la GetObjectData método.

¿Pero qué podría estar mal aquí? Alrededor de google he encontrado algunos atributos adicionales para pegar en mi método y el espacio de nombres - por lo que hice:

[assembly: SecurityPermission(SecurityAction.RequestMinimum, Execution = true)] 
namespace MyApplication.ORM 
{ 
    [Serializable] 
    public abstract class MyCustomORM: IMyCustomORM, ISerializable, ICloneable, ISecurable 
    { 
     [SecurityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.SerializationFormatter)] 
     public virtual void GetObjectData(SerializationInfo info, StreamingContext context) 
     { 
      // do stuff here....... 
     } 
    } 
} 

pero eso no cambia nada .....

La excepción ocurre incluso antes de mi primera línea de código en mi static Main() método se alcanza ....

He peinado a través del proyecto y eliminado todas las referencias a las viejas bibliotecas de .NET 1.1 (sí, la aplicación es tan antigua .....) y las reemplacé con sus contrapartes de .NET 4 (principalmente log4net). Todavía sin suerte ....

¿Alguna idea?

+1

Existe un 'indicador' para controlar este comportamiento. No recuerdo dónde. El error también indica que no puede usar 'virtual' allí. – leppie

+0

Además, 'GetObjectData' realmente no tiene sentido en una clase abstracta, ya que nunca podría volver a crear una instancia (a una instancia de un tipo abstracto). – leppie

Respuesta

6

¿El conjunto en el que reside la clase MyCustomORM está marcado con SecurityTransparentAttribute? Si es así, el problema se debe a cambios en el modelo de transparencia de seguridad entre .NET 3.5 y .NET 4.0. Para su escenario de prueba, puede simplemente optar por utilizar el mecanismo de transparencia anterior. Para ello, agregue el siguiente atributo de nivel de ensamblado:

[assembly: SecurityRules(SecurityRuleSet.Level1)] 

Para obtener más información sobre las diferencias entre los modelos de transparencia y de nivel 1. Nivel 2, ver http://blogs.msdn.com/b/shawnfa/archive/2009/11/12/differences-between-the-security-rule-sets.aspx.

+1

Todos los ensamblados parecen tener un atributo '[assembly: AllowPartiallyTrustedCallers]' –

+0

En las reglas de Nivel 2, APTCA da como resultado que todos los códigos en el ensamblado se tratan como transparentes a menos que se marquen como críticos. Especificar reglas de Nivel 1 a través de SecurityRulesAttribute debe abordar su problema inmediato, de forma muy similar a como lo hizo con SecurityTransparentAttribute. –

1

Sé que esto es bastante viejo, pero me encontré con este problema con uno de mis ensamblajes recientemente. Solo ocurrió en algunas máquinas y fue muy difícil determinar qué lo estaba causando. No solo quería poner ajustes de reglas de seguridad, así que después de mucha búsqueda me encontré con la herramienta SecAnnotate que se incluye con Visual Studio.

Using SecAnnotate to Identify Transparency Violations

Con la herramienta pude determinar que uno de mis montajes se refería a una versión anterior de un archivo DLL que contenía algunos de los atributos de seguridad que estaban causando el problema. La actualización de la referencia solucionó el problema.

La herramienta SecAnnotar parece una excelente manera de identificar cualquier violación que pueda haber pasado por alto accidentalmente o que no conocía.

Espero que esto ayude a alguien.

Cuestiones relacionadas