Продолжаем отрабатывать корпоративный план по формированию правильного общественного мнения о компании Microsoft и ее технологиях :) Время такое.

Итак, вот вам техническая задачка. Насколько я смог найти, ее разъяснения нет даже у Рихтера. К самому решению я надеюсь придти потом, когда будет возможность «подолее невозбранно» посидеть за компьютером, а пока условие.

Как известно, .Net проектировался с оглядкой на возможность глубокого взаимодействия с нативным кодом и COM. Не будем разбираться сейчас, было ли это техническим или политическим решением, важно вот что — взаимодействие с неуправляемым кодом является сложной проблемой, и может попить немало крови разработчика там, где он не ожидал. Предлагаемая задача — одна из этих.

UPD: Решение тут: habrahabr.ru/blogs/net/69650

Итак, привожу решение проблемы из топика habrahabr.ru/blogs/net/69545 — про гарантированное освобождение неуправляемого ресурса.

Как правильно заметил товарищ adontz, проблема решается при помощи CER.
CER — это технология Constrained Execution Region, при помощи которой можно обезопасить свой код, гарантировав ему то, что на некотором его участке гарантированно _не_ случится асинхронного прерывания типа StackOverflow или ThreadAbort, или «отвалился» jitter — всякое бывает, и не всегда есть возможность оставить внешние ресурсы в консистентном состоянии.

В продолжение темы устойчивых приложений и CER (начало тут) — рассмотрим, как подготовить произвольный (или почти произвольный) участок кода для выполнения в регионе Constrained Execution.

Зачем такое надо? Помните, я говорил, что в процессе подготовки к CER происходит инспекция стека и пре-jitt. Но проинспектировать стек, если вызов происходит через интерфейс или виртуальный метод заранее невозможно. Поэтому такой код:

    ...
    RuntimeHelper.PrepareConstrainedRegions();
     try {}
    finally {
         obj.SomeVirtualMethod();
    }

скомпилируется, но в run-time не достигнет желаемого.