Outlook 2016 VSTO-Addin: как избежать исключения System.AccessVioloationException для "устаревшей" ссылки на AppointmentItem?

Question

Как вы можете видеть, я проверил наличие assignItem! = Null и rtfBody.Length! = 0, хотя вызов assignItem.GetInspector выдает исключение System.AccessVioloationException. Это происходит, когда я запускаю надстройку Outlook через VisualStudio на более длительное время (несколько часов), а затем закрываю Outlook. Я считаю, что это вызвано тем, что Outlook уже завершает работу, поэтому AppointmentItem все еще существует, но некоторые вещи, связанные с COM, вышли из строя. Но это только смутное предположение. Вы хоть представляете, почему это происходит и как этого избежать?

Кроме того, я уже добавил попытку / уловку, например:

catch (Exception ex)
{
   log.Info(ex.Message);
   return 0;
} 

Но исключение не перехватывается. Поэтому мне нужно дополнительно перехватить SystemExceptions, я понимаю, верно?

Answer 1

Это происходит, когда я запускаю свой надстройку Outlook через VisualStudio на более длительное время (несколько часов), а затем закрываю Outlook.

Среда CLR предоставляет объекты COM через прокси, называемый вызываемая оболочка времени выполнения (RCW). Хотя RCW кажется обычным объектом для клиентов. NET, его основная функция - маршалинг вызовов между клиентом. NET и COM-объектом. Итак, если COM-сервер не существует (Outlook закрыт), ваши вызовы RCW не имеют никакого смысла.

По умолчанию, начиная с. NET 4.0, среда CLR не передает эти исключения в управляемый код, и блоки try / catch (и другие предложения обработки исключений) не вызываются для них. Если вы абсолютно уверены, что хотите продолжить обработку этих исключений, вы должны применить атрибут HandleProcessCorruptedStateExceptionsAttribute к методу, чьи предложения обработки исключений вы хотите выполнить. CLR доставляет исключение поврежденного состояния процесса в соответствующие предложения исключения только в методах, которые имеют атрибуты HandleProcessCorruptedStateExceptionsAttribute и SecurityCriticalAttribute.

Вы также можете добавить элемент <legacyCorruptedStateExceptionsPolicy> в файл конфигурации вашего приложения. Это гарантирует, что исключения поврежденного состояния будут доставлены вашим обработчикам исключений без атрибута HandleProcessCorruptedStateExceptionsAttribute или SecurityCriticalAttribute. Этот элемент конфигурации не влияет на приложения, которые были скомпилированы в версиях, предшествующих. NET Framework 4, но запущенных в. NET Framework 4 или новее; Исключения из поврежденного состояния будут по-прежнему доставляться для этих приложений. Атрибут HandleProcessCorruptedStateExceptionsAttribute игнорируется, когда он встречается в частично доверенном или прозрачном коде, потому что доверенный узел не должен позволять ненадежной надстройке перехватывать и игнорировать эти серьезные исключения.

Дополнительные сведения о поврежденном процессе исключения состояния, см. запись Обработка исключений поврежденного состояния в блоге CLR Inside.

Вы также можете обрабатывать следующие события класса AppDomain:

• AppDomain.UnhandledException запускается, когда исключение не обнаружено. Начиная с. NET Framework 4, это событие не возникает для исключений, которые нарушают состояние процесса, таких как переполнение стека или нарушения доступа, если только обработчик событий не является критичным с точки зрения безопасности и имеет атрибут HandleProcessCorruptedStateExceptionsAttribute.
• AppDomain.FirstChanceException запускается, когда в управляемом коде генерируется исключение, прежде чем среда выполнения выполнит поиск в стеке вызовов обработчика исключений в домене приложения.