2012-07-13 22 views
6

Sto usando LINQPad per testare il codice (che grande prodotto, devo dire) ma ora sto riscontrando un'eccezione quando provo a impostare Thread.CurrentPrincipal su un IPrincipal personalizzato che è marcato con il SerializableAttribute a seguito di un esempio che illustrano il problemalinqpad e personalizzato IPrincipal serializzabile

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"); 
     } 
    } 
} 

Quando eseguo questo codice in LINQPad (C# programma come lingua) ottengo la seguente eccezione

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

se mi tolgo la Serializable attributo tutto va bene Sembra un problema correlato all'architettura AppDomain utilizzata da LINQPad e all'incapacità del framework di trovare l'assembly che definisce MyCustomPrincipal. Inoltre, credo che la definizione di MyCustomPrincipal in un altro assembly e il suo inserimento nel GAC risolverebbe il problema, ma non è un'opzione per me. Qualcuno ha un'idea?

Grazie, Marco

EDIT: Non so se potrebbe aiutare, ma ho avuto lo stesso problema con SqlDependency.Start: mettere Serializable sul IPrincipal reso il quadro di gettare un errore lamentandosi del fatto che non riesce a trovare l'assembly che definisce il tipo di IPrincipal. Ho risolto con un trucco vergognoso:

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

Questo sembra un problema LINQPad. Lo esaminerò in modo più dettagliato e postback. –

+0

@JoeAlbahari hai qualche aggiornamento su questo? È davvero fastidioso e non ho trovato soluzioni alternative – mCasamento

+0

Ho pensato di aver trovato una risposta qui: http://stackoverflow.com/questions/11489673/preventing-thread-currentprincipal-from-propagating-across-application-domains, ma non funziona con LINQPad perché le chiamate tra domini vengono avviate da entrambi i lati. Un sacco * di comunicazioni continua in LINQPad tra i domini host e worker - ci sono più di una dozzina di metodi - quindi non è solo una questione di hacking in una singola chiamata. –

risposta

0

Un trucco che è possibile utilizzare è assegnare un nome sicuro all'assembly contenente l'entità personalizzata e inserirlo nella Global Assembly Cache. In questo modo, qualsiasi applicazione può trovare l'assembly desiderato, non è una soluzione ideale perché in seguito dovrai rimuoverlo. In ogni caso installare nella GAC ​​se si dispone di Visual Studio installato eseguire un prompt dei comandi VS ed eseguire il seguente:

gacutil -i nameofassembly.dll

+0

Grazie per la tua risposta, l'ho già provato e funziona. Considero più una soluzione alternativa che una soluzione reale, ma è meglio di niente. Sto segnalando questo come la risposta, tuttavia. – mCasamento

0

salto nel buio, ma potrebbe essere una cosa di firma a causa di assemblee di attraversamento?

+0

forse, ma come posso firmare un assembly che esiste solo in memoria? Dovrebbe essere fatto all'interno di LINQPad, non dovrebbe? – mCasamento

0

Questo sembra essere un problema di serializzazione in LinqPad. vedo Joseph Albahari, creatore di Linqpad, ha confermato questo nei vostri commenti.

In conclusione: abbiamo bisogno di una correzione in LinqPad per questo. Non so di nessun lavoro in giro.