Rilevamento di JIT in fase di compilazione in MonoTouch

Question

Sto lavorando a un sistema di compilazione per un'applicazione MonoTouch abbastanza grande che utilizza molti componenti multipiattaforma. Di conseguenza, spesso ci imbattiamo in una situazione in cui uno di quei componenti multipiattaforma fa qualcosa che non può essere compilato. Se qualcosa viene effettivamente eseguito, la build del dispositivo si bloccherà. A quel punto, dobbiamo rintracciare dove si è verificato l'incidente, trovare il metodo incriminato e hackerarlo in modo che non provi a JIT nel build di MonoTouch.

La mia domanda è, c'è un modo per rilevare queste cose durante il processo di compilazione? All'inizio avevamo una regex che provava a rilevare metodi virtuali generici, ma ci sono anche problemi con alcuni tipi di LINQ e lambda che proveranno a JIT, e preferisco non provare a scrivere il mio parser per rilevarli tutti. Ho provato a usare monodis AssemblyName.dll e mi daranno un sacco di errori di metodo mancanti, ma la maggior parte sembra innocua - e anche se non lo fossero, non mi dice dove sono i riferimenti a tale metodo che posso vedere cosa deve essere fatto. Inoltre, a volte si blocca con Abort trap: 6 o Bus error: 10 prima della fine dell'assembly, il che è piuttosto inutile. C'è un modo migliore per rilevare i tentativi di JIT nel mio processo di compilazione?

Answer 1

La mia domanda è: esiste un modo per rilevare queste cose durante il processo di generazione?

No. L'uso del JIT (o più precisamente l'eccezione che sta tentando di utilizzare JIT) è un fallback di runtime quando qualcosa non viene trovato all'interno dell'eseguibile nativo.

Non è impossibile (né facile) rilevare (alcune/più) condizioni che portano all'eccezione utilizzando il proprio strumento (potrebbe anche essere una regola Gendarme). Tuttavia si tratta di un obiettivo in movimento poiché stiamo risolvendo i problemi reported, quindi dovrai aggiornare gli strumenti con ogni nuova versione (o rischiare di passare del tempo a sistemare cose che non sono più problemi).

Ciò che sarebbe davvero utile (con o senza il proprio strumento) è quello di segnalare tali problemi in modo che possano essere monitorati e diventare parte della suite di test di Xamarin.

Ho provato con monodis AssemblyName.dll

monodis richiede di avere accesso a tutti i riferimenti di montaggio, altrimenti non funzionerà (e può andare in crash).

Answer 2

Sulla parte "detect": quando si capisce quale costrutto provoca problemi, creare le regole personalizzate FxCop che lo rilevano ed eseguirlo su assiemi normali. In questo modo non avrai bisogno di scrivere il tuo parser.

vicini: FxCop - http://msdn.microsoft.com/en-us/library/bb429476%28v=VS.80%29.aspx regole personalizzate per FxCop how-to: http://www.codeproject.com/Articles/30666/7-Steps-to-Write-Your-Own-Custom-Rule-using-FXCOP