Обнаружение JIT во время компиляции в MonoTouch

Question

Я работаю над системой сборки для довольно большого приложения MonoTouch, которое использует много кроссплатформенных компонентов.В результате мы часто сталкиваемся с ситуацией, когда один из этих кроссплатформенных компонентов делает что-то, что невозможно скомпилировать.Если что-то действительно будет выполнено, сборка устройства завершится сбоем.В этот момент мы должны отследить, где произошел сбой, найти метод, вызывающий сбой, и взломать его, чтобы он не пытался выполнить JIT в сборке MonoTouch.

Мой вопрос: есть лиспособ обнаружить эти вещи во время процесса сборки?Сначала у нас было регулярное выражение, которое пыталось обнаружить универсальные виртуальные методы, но есть также проблемы с определенными типами LINQ и лямбда-выражений, которые также будут пытаться использовать JIT, и я бы предпочел не пытаться написать собственный анализатор для их обнаружения.все.Я попытался использовать monodis AssemblyName.dll, и это даст мне много пропущенных ошибок метода, но большинство из них кажутся безвредными - и даже если они не были, это не говорит мне, где ссылки на указанный методтак, чтобы я мог видеть, что нужно сделать.Кроме того, иногда он падает с Abort trap: 6 или Bus error: 10 до конца сборки, что совершенно бесполезно.Есть ли лучший способ обнаружить попытки JIT в процессе сборки?

Answer 1

У меня вопрос, есть ли способ обнаружить эти вещи в процессе сборки?

Нет. Использование JIT (или, точнее, исключение, что он пытается использовать JIT) - это запасной вариант времени выполнения, когда что-то не найдено внутри собственного исполняемого файла.

Это не невозможно (и не просто) обнаружить (некоторые / большинство) условия, приводящие к исключению, используя ваш собственный инструмент (это может быть даже правило Жандарм ). Однако это движущаяся цель, поскольку мы исправляем сообщенные проблемы, поэтому вам придется обновлять свои инструменты с каждой новой версией (или рискуете тратить время на исправление проблем, которые больше не являются проблемами ).

Что было бы действительно полезно (с вашим собственным инструментом или без него), так это сообщать о таких проблемах, чтобы их можно было отслеживать и стать частью набора тестов Xamarin.

Я пытался использовать monodis AssemblyName.dll

monodis требует наличия доступа ко всем ссылкам на сборки, иначе он не будет работать (и может привести к сбою).

Answer 2

В части «обнаружение»: когда вы выясняете, какая конструкция вызывает проблемы, создайте пользовательское правило (правила) FxCop, которое обнаружит его и запустите на обычных сборках. Таким образом, вам не нужно будет писать собственный парсер.

Ссылки: FxCop - http://msdn.microsoft.com/en-us/library/bb429476%28v=VS.80%29.aspx Пользовательские правила для инструкции FxCop: http://www.codeproject.com/Articles/30666/7-Steps-to-Write-Your-Own-Custom-Rule-using-FXCOP