los ECI Detección en tiempo de compilación en MonoTouch

Question

estoy trabajando en un sistema de construcción para una aplicación bastante grande MonoTouch que está utilizando una gran cantidad de componentes de plataforma cruzada. Como resultado, a menudo nos encontramos con una situación en la que uno de esos componentes multiplataforma hace algo que no puede compilarse. Si ese algo realmente se ejecuta, la compilación del dispositivo se bloqueará. En ese punto, tenemos que rastrear dónde ocurrió el bloqueo, encontrar el método ofensivo y modificarlo para que no intente JIT en la compilación de MonoTouch.

Mi pregunta es, ¿hay una manera de detectar estas cosas durante el proceso de construcción? Al principio, tuvimos una expresión regular que intentó detectar métodos virtuales genéricos, pero también hay problemas con ciertos tipos de LINQ y lambdas que también intentarán JIT, y prefiero no intentar escribir mi propio analizador para detectarlos. todas. He intentado usar monodis AssemblyName.dll, y me dará muchos errores de método faltantes, pero la mayoría de ellos parecen ser inofensivos, y aunque no lo fueran, no me dice dónde están las referencias a dicho método. que puedo ver lo que hay que hacer. Además de eso, a veces se bloqueará con Abort trap: 6 o Bus error: 10 antes del final del montaje, lo que es bastante inútil. ¿Hay alguna forma mejor de detectar intentos de JIT en mi proceso de compilación?

Answer 1

Mi pregunta es, ¿hay una manera de detectar estas cosas durante el proceso de construcción?

Nº Usando el JIT (o más exactamente la excepción de que está tratando de usar el JIT) es un repliegue tiempo de ejecución cuando no se encuentra algo dentro del ejecutable nativo.

No es imposible (ni fácil) detectar (algunas/la mayoría) de las condiciones que conducen a la excepción usando su propia herramienta (incluso podría ser una regla Gendarme). Sin embargo este es un movimiento objetivo, puesto que estamos arreglando reported problemas por lo que tendrá que actualizar sus herramientas con cada nueva versión (o pasar tiempo de riesgo fijación de cosas que no son cuestiones más).

Lo que sería realmente útil (con o sin su propia herramienta) es reportar este tipo de cuestiones para que puedan ser rastreados y se convierten en parte del conjunto de pruebas de Xamarin.

He intentado usar monodis AssemblyName.dll

monodis requiere tener acceso a todas las referencias de ensamblado, de lo contrario no funcionará (y puede bloquearse).

Answer 2

En "detectar" parte: cuando a averiguar lo que causa problemas de construcción crean regla personalizada FxCop (s) que lo detecta y ejecutarlo en asambleas normales. De esta forma, no necesitará escribir su propio analizador.

Enlaces: FxCop - http://msdn.microsoft.com/en-us/library/bb429476%28v=VS.80%29.aspx Las reglas personalizadas para FxCop de cómo hacerlo: http://www.codeproject.com/Articles/30666/7-Steps-to-Write-Your-Own-Custom-Rule-using-FXCOP