2012-04-04 21 views
6

Tengo un código de transferencia que usa DynamicMethod s ampliamente para permitir la precompilación, para un mejor rendimiento de arranque en frío. Me di cuenta de que DynamicMethod s se pueden JITted y se pueden ejecutar con las comprobaciones de visibilidad omitidas, lo que les permite acceder a tipos anidados privados, pero los ensamblados normales no pueden (¿o no? No veo ninguna opción obvia de cargador). ¿Cuál es la razón de esta decisión de diseño?¿Por qué se omiten las comprobaciones de visibilidad solo para métodos dinámicos?

+1

-unidad, ya que esto no está relacionado con Microsoft Unity. Puede leer esta publicación de blog, http://davedewinter.com/2010/11/21/tip-22-dynamicmethods-in-partial-trust/. Requiere ciertos permisos para hacerlo. Por lo tanto, si desea restringir dichos intentos, puede hacerlo. –

Respuesta

2

Necesito agitar un poco las manos respondiendo esta pregunta, CAS es siempre complicado. El argumento skipVisibility es relevante para las aplicaciones host confiables que generan código que se ejecuta en un entorno limitado. En tal caso, no es apropiado realizar comprobaciones cuando se genera el método, ya que el entorno de ejecución es incorrecto. Tiene que suceder cuando el método ejecuta dentro de la caja de arena. Donde está sujeto a las verificaciones CAS normales realizadas por el sandbox.

Estableciendo el argumento en true de hecho agrega una solicitud de permiso para ReflectionPermissionFlag.MemberAccess, necesaria para tener la oportunidad de obtener el método generado.

Topsy-turvy. Hay información de fondo en this MSDN article, sección "Adición de RestrictedMemberAccess a Sandboxed Domains".

Cuestiones relacionadas