2009-06-01 5 views
0

У меня есть функция, которая, я хочу быть уверен, скомпилирована JIT (т.е. прямо перед ее вызовом). Есть ли атрибуты или настройки сборки, которые обеспечат это? Если нет, то как я могу гарантировать, что функция скомпилирована JIT?Есть ли способ обеспечить компиляцию функции JIT?

Спасибо!

EDIT:

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

Мое понимание, что могут быть моменты, когда целые классы (или даже все приложение) могут быть Jitted - это может вызвать ошибку, которую я не мог уловить.

+4

Почему на земле вы хотите сделать это? –

+0

Хотите услышать это, его должно быть хорошо. – Will

ответ

2

Если я прочитал это правильно, вы беспокоитесь об ошибках, возникающих при первом компиляции класса/метода. Это требует осознания границ. Он доступен с дополнительным слоем.

Если что-то не так с SuspectType (т. Е. Требуемая сборка не загружается), попытка try/catch в следующем случае бесполезна, потому что сам Jitting of Scenario1() завершится с ошибкой.

void Scenario1() 
{ 
    try 
    { 
    var x = new SuspectType(); 
    ... 
    } 
    catch (..) { ... }  
} 

Это может быть переписано в виде

void Scenario1a() 
{ 
    try 
    { 
     Scenario1b(); 
    } 
    catch (..) { ... }  

} 

void Scenario1b() 
{ 
    var x = new SuspectType(); 
    ... 
} 

Но на комментарий Джона Скита, я не уверен, если это верно для CFX.

0

Возможно, я отвечаю на неправильный вопрос, но похоже, что вы в основном хотите перехватывать сбои сборок (целые классы JITted поражают защиту try/catch вокруг вызовов, но это побочный эффект использования явных охранников вокруг вызовов методов).

Если вы хотите поймать проблемы разрешения сборки, вместо указания попытки/уловить все возможные вызовы, вы можете просто прослушать глобальное событие AssemblyResolve и ответить на сбои загрузки сборки (мы говорим о сборках .Net здесь, сбои загрузки нативной dll пришлось бы отслеживать с помощью другого механизма).

static void Main() 
{ 
    AppDomain.CurrentDomain.AssemblyResolve += OnResolveFailure; 
    //... 
} 

static Assembly OnResolveFailure(object sender, ResolveEventArgs args) 
{ 
    //Do something here... 
} 

Недостатком этого является то, вы не можете сделать многое, кроме ищет сборки в другом месте (или регистрации ошибок). Конкретная и изящная логика, когда сбой разрешения не обеспечивается таким способом улавливания сбоев нагрузки.

+0

Я тоже пробовал что-то подобное, но, как вы уже сказали, я не могу сделать многое после этого, кроме журнала ошибки. Возможность обертывания вызова функции в try ... catch (что я делаю сейчас, и это работает ужасно), не беспокоясь о том, что механизм, на который я опишу (компиляция JIT), потерпит неудачу, является моей целью. Благодаря!! – Pwninstein

0

Это что-то, что ваше приложение должно быть в состоянии решить самостоятельно, или вы отлаживаете какую-то проблему загрузки сборки прямо сейчас?

Если последние, посмотрите журнал сварки. Это журнал, который генерируется подсистемой, которая проверяет и загружает сборки во время выполнения.

Вот статья: http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx