2012-07-13 12 views
6

Estoy usando LINQPad para probar el código (qué gran producto, debo decir) pero ahora encuentro una excepción cuando intento configurar el Thread.CurrentPrincipal en un IPrincipal personalizado que está marcado con el SerializableAttribute siguiendo un ejemplo que muestran el problemalinqpad y personalizado IPrincipal serializable

void Main() 
{ 
    Thread.CurrentPrincipal = new MyCustomPrincipal(); 
} 

// Define other methods and classes here 
[Serializable] 
public class MyCustomPrincipal : IPrincipal 
{ 
    public bool IsInRole(string role) 
    { 
     return true; 
    } 

    public IIdentity Identity 
    { 
     get 
     { 
      return new WindowsIdentity("RECUPERA\\m.casamento"); 
     } 
    } 
} 

Cuando ejecuto este código en LINQPad (C# programa como el lenguaje) me da la siguiente excepción

Type is not resolved for member 'UserQuery+MyCustomPrincipal,query_nhxfev, Version=0.0.0.0, 
Culture=neutral, PublicKeyToken=null' 
RuntimeMethodInfo: PluginWindowManager.get_Form() 

Si quito el Serializable atributo todo va bien Parece un problema relacionado con la arquitectura AppDomain que utiliza LINQPad y la incapacidad del marco para encontrar el ensamblado que define MyCustomPrincipal. Además, creo que definir MyCustomPrincipal en otro ensamblado y ponerlo en el GAC resolvería el problema, pero esa no es una opción para mí. ¿Alguien tiene una idea?

Gracias, Marco

EDITAR: No sé si podría ayudar, pero he tenido el mismo problema con SqlDependency.Start: poner en Serializable IPrincipal hecho que el marco para lanzar un error quejándose de que no puede encontrar el ensamblado que define el tipo de IPrincipal. He resuelto con un truco ignominiosa:

System.Security.Principal.IPrincipal principal; 
principal = System.Threading.Thread.CurrentPrincipal; 

System.Threading.Thread.CurrentPrincipal = null; 
try 
{ 
    SqlDependency.Start(connectionString); 
     m_SqlDependencyStarted = true; 
} 
catch (Exception ex) 
{ 
    throw (ex); 
} 
finally 
{ 
    System.Threading.Thread.CurrentPrincipal = principal; 
} 
+5

Esto se ve como un problema de LINQPad. Lo investigaré con más detalle y publicaré de nuevo. –

+0

@JoeAlbahari ¿tiene alguna actualización sobre esto? Es realmente molesto y no encontré ninguna solución – mCasamento

+0

. Pensé que había encontrado una respuesta aquí: http://stackoverflow.com/questions/11489673/preventing-thread-currentprincipal-from-propagating-across-application-domains, pero no funciona para LINQPad porque las llamadas entre dominios se inician desde ambos lados. Un * lote * de comunicaciones continúa en LINQPad entre los dominios del host y del trabajador (hay más de una docena de métodos), por lo que no se trata simplemente de piratear una sola llamada. –

Respuesta

0

Un truco que podría usar es darle un nombre fuerte al ensamblado que contiene el principal personalizado y ponerlo en el Caché de ensamblaje global. De esta forma, cualquier aplicación puede encontrar el ensamblaje que desee, no es una solución ideal porque tendrá que volver a quitarla después. De todos modos para instalar en la GAC ​​si tiene instalado Visual Studio ejecutar un símbolo del sistema VS y ejecute el siguiente:

gacutil -i nameofassembly.dll

+0

Gracias por su respuesta, ya lo probé y funciona. Considero más una solución alternativa que una solución real, pero es mejor que nada. Sin embargo, estoy señalando esto como la respuesta. – mCasamento

0

puñalada en la oscuridad, sino que podría ser una cosa firma debido a los conjuntos de cruce?

+0

tal vez, pero ¿cómo puedo firmar un ensamblaje que solo existe en la memoria? Debería hacerse dentro de LINQPad, ¿no es así? – mCasamento

0

Esto parece ser un problema de serialización dentro de LinqPad. Veo que Joseph Albahari, creador de Linqpad, ha confirmado esto en sus comentarios.

Conclusión: necesitamos una solución en LinqPad para esto. No sé de ningún trabajo alrededor.

Cuestiones relacionadas