Ho aggiornato il nostro software da vs2008/.net 3.5 a vs2010/.net 4.0. Tutte le librerie di terze parti (le più rilevanti: nibernate 2.1.2 o 3.0.0, nunit 2.5.2) sono ancora compilate usando vs2008. Quando eseguo i test delle unità per la creazione del debug del nostro software, tutto funziona correttamente. Nella versione di rilascio, nunit riporta eccezioni su 33 di 228 test: System.InvalidProgramException : Common Language Runtime detected an invalid program.
Succede sempre sugli stessi test, sia per nunit-console che per il runner di prova di Resharper 5.0. Quando li eseguo usando il comando Resharper "debug unit-tests", tutti i test passano. Non fa differenza se eseguo i test singolarmente o in batch. L'eccezione si verifica sempre in prossimità di chiamate di query non pericolose, ma non posso dirlo con certezza dato che la traccia dello stack di generazione del rilascio è alquanto sparsa. Non dipende dal generatore bytecode nibernetico, la stessa eccezione appare per castello e linfu. Qualcuno ha un'idea di come eseguire il debug di questo?nunit su release build: "Common Language Runtime ha rilevato un programma non valido."
Modifica: la rimozione di Spring.NET non ha avuto alcun effetto su questo problema.
Edit: Quando accendo l'uscita di rilascio di configurazione di debug per piena invece pdb solo e disattivare il codice casella ottimizzare, l'eccezione scompare. Entrambe le impostazioni sono obbligatorie, se cambio solo una di esse rimane il bug. Tuttavia, un set diverso di test fallisce se ne cambio solo uno. Tutte le librerie di classi sono compilate per Qualsiasi CPU.
È possibile verificare se le configurazioni di rilascio e debug del progetto sono diverse? Ho visto alcuni casi, in cui qualcuno aggiunge solo X per eseguire il debug della configurazione ... lasciando la versione di configurazione obsoleta .. – Gishu
@Gishu: sono stato in grado di tracciare la differenza per l'output di debug e ottimizzare le impostazioni del codice - nessun'altra impostazione sembra influire su questo problema. –
Hmm .. Nessuna direzione definita qui. da alcune ricerche superficiali, sembra essere correlato a chiamate di dll di terze parti. http://bit.ly/g3iwnK Prova a ottenere lo stacktrace e la pubblicazione nel forum MS corretto: sembra essere un'area di nicchia (non esattamente il punto di forza di SO) – Gishu