Использование API контекста активации

Приложения могут управлять контекстом активации путем прямого вызова функций контекста активации. Контексты активации — это структуры данных в памяти. Система может использовать сведения в контексте активации для перенаправления приложения для загрузки определенной версии DLL, экземпляра COM-объекта или пользовательской версии окна. Дополнительные сведения см. в справочнике по контексту активации.

Интерфейс программирования приложения (API) можно использовать для управления контекстом активации и создания объектов с именованной версией и манифестами . В следующих двух сценариях показано, как приложение может управлять контекстом активации, напрямую вызывая функции контекста активации. Однако в большинстве случаев контекст активации управляется системой. Разработчикам приложений и поставщикам сборок обычно не нужно вызывать стек для управления контекстом активации.

• Процессы и приложения, реализующие уровни косвенного обращения или диспетчеризации.

  Например, пользователь управляет контекстами активации в цикле событий. При каждом доступе к окну, например путем перемещения мыши по окну, вызывается ActivateActCtx, который активирует текущий контекст активации для ресурса, как показано в следующем фрагменте кода.

HANDLE hActCtx;  
CreateWindow();  
...  
GetCurrentActCtx(&ActCtx);  
...  
ReleaseActCtx(&ActCtx);  

В следующем фрагменте кода функция API активирует соответствующие контексты активации перед вызовом CallWindowProc. При вызове CallWindowProc этот контекст используется для передачи сообщения в Windows. После завершения всех операций с ресурсами функция деактивирует контекст.

ULONG_PTR ulpCookie;  
HANDLE hActCtx;  
if(ActivateActCtx(hActCtx, &ulpCookie))  
{  
    ...  
    CallWindowProc(...);  
    ...  
    DeactivateActCtx(0, ulpCookie);  
}

• Уровень отправки delegator.

  Этот сценарий применяется к менеджерам, которые управляют несколькими сущностями с общим уровнем API, например диспетчер драйверов. Хотя он еще не реализован, примером этого будет драйвер ODBC.

  В этом сценарии средний слой может обрабатывать привязки сборок. Чтобы получить драйвер привязки для конкретной версии, издатели должны предоставить манифест и указать зависимости от определенных компонентов в этом манифесте. Базовое приложение не динамически привязывается к компонентам; Во время выполнения диспетчер драйверов управляет вызовами. При вызове драйвера ODBC на основе строки подключения он загружает соответствующий драйвер. Затем он создает контекст активации с помощью сведений в файле манифеста сборки.

  Без манифеста действие по умолчанию для драйвера — использовать тот же контекст, что и приложение, в этом примере версия 2 MSVCRT. Так как манифест существует, устанавливается отдельный контекст активации. При запуске драйвера ODBC он привязывается к сборке MSVCRT версии 1.

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

HANDLE hActCtx;  
ULONG_PTR ulpCookie;  
ACTCTX ActCtxToCreate = {...};  
hActCtx = CreateActCtx(&ActCtxToCreate);  
...;  
if (ActivateActCtx(hActCtx, &ulpCookie))  
{  
    ...  
    ConnectDb(...);  
    DeactivateActCtx(0, ulpCookie);  
}  
... 
ReleaseActCtx(hActCtx);