должны включаться в каждую сборку .NET, использующую службы COM+.
Следующий пример кода перечисляет их:
[assembly:ApplicationActivation(ActivationOption.Server)]
[assembly:ApplicationID('448934a3-324f-34d3-2343-129ab3c43b2c')]
[assembly:ApplicationName('SomeApplicationName')]
[assembly:Description('Description of your assembly here.')]
Рассмотрим каждый из этих атрибутов по очереди.
Ранее упоминалось, что существуют два вида приложений COM+ — серверные приложения и библиотечные приложения. Первый атрибут в коде примера — ApplicationActivation — позволяет определить, каким из этих видов приложений является определенная сборка. (Допустимые значения для этого атрибута определяются в перечислении ActivationOption, которое можно заметить внутри скобок атрибута.) Определяя тип приложения программным путем с помощью этого атрибута, можно избежать необходимости открывать менеджер службы компонентов и делать это вручную. Это перечисление имеет два значения: ActivationOption.Library и ActivationOption.Server.
Второй атрибут, ApplicationID, определяет присоединенный 128-битный уникальный идентификатор (GUID) сборки. (GUID являются идентификационными номерами, которые гарантируют уникальность в течение очень большого периода времени. Службы COM+ ожидают такой идентификатор от каждого приложения.) В коде примера случайно выбранный GUID не имеет ничего существенного, он присутствует только для целей демонстрации. Для каждой создаваемой сборки придется создавать свой собственный. Чтобы сделать это, можно использовать утилиту GuidGen.exe компании Microsoft, которая распространяется вместе с Visual Studio.
Третий атрибут в коде примера, ApplicationName, позволяет определить имя приложения службы COM+, которое будет создано для размещения сборки .NET, когда она импортируется в службы COM+. В данном примере используется значение SomeAppliсationName.
Четвертый и последний атрибут, ApplicationDescription, позволяет связать описание со сборкой, чтобы предоставить разработчикам некоторые идеи о том, что она делает.
Документация компании Microsoft определяет, что любая сборка .NET, использующая в соединении со службами COM+, должна применять все эти четыре атрибута.
Развертывание сборки для служб COM+
Развертывание сборки, использующейся со службами COM+, будет ненамного труднее, чем развертывание любой другой сборки .NET.
Первое: необходимо предоставить сборке сильное имя. Это делается с помощью утилиты sn.exe из SDK .NET (см. главу 10). sn.exe будет выводить файл сильного имени, на который можно ссылаться из командной строки, когда сборка компилируется, чтобы встроить сильное имя в компилированную сборку.
Второе: необходимо зарегистрировать сборку в глобальном кэше сборок (см. главу 10).
Если сборку будут использовать только управляемые клиенты (то есть, клиенты .NET), никаких дополнительных усилий по развертыванию не требуется. Когда управляемый клиент создает в сборке экземпляр обслуживаемого класса, CLR использует атрибуты в сборке для автоматической регистрации компонента в службах COM+.
Однако, если классы в сборке используются неуправляемым кодом, необходимо самостоятельно явно зарегистрировать сборку в службах COM+ до выполнения любой клиентской программы. Программа для выполнения этой регистрации, RegSvcs.exe, предоставляется компанией Microsoft как часть SDK .NET. Когда RegSvcs выполняется на компоненте .NET, она создает приложение COM+ с именем, указанным атрибутом ApplicationName в сборке, и импортирует сборку в него.
Для чего же требуется RegSvcs.exe?
Как можно помнить из предыдущей главы по взаимодействию COM, сборки .NET имеют архитектуру, отличную от архитектуры компонентов COM. Задача RegSvcs.exe состоит в разрешении этих различий, чтобы сборки .NET удовлетворяли интерфейсу, ожидаемому службами COM+. Чтобы выполнить свою работу, утилита RegSvcs.exe проделывает четыре вещи.
1.
2. Создает библиотеку типов для сборки .NET.
3. Импортирует библиотеку типов в приложение служб COM+.
4. Использует метаданные внутри DLL, чтобы правильно сконфигурировать библиотеку типов внутри приложения служб COM+.
RegSvcs не только заботится обо всех деталях импортирования сборки в службы COM+, но предоставляет также достаточно хороший контроль за тем, как это происходит. Этот контроль обеспечивается в форме дополнительных параметров командной строки. Вот синтаксис команды:
Regsvcs .
С помощью второго аргумента (COM+AppName) можно определить другое имя для создаваемого приложения COM+, предоставляя второй аргумент командной строки при вызове RegSvcs. Для еще большей гибкости можно определить имя файла библиотеки типов, которая создается при предоставлении третьего аргумента (TypeLibrary.tlb). Желательно всегда предоставлять эти аргументы при вызове RegSvcs, так как более ранние версии этой программы будут молчаливо перезаписывать любые существующие файлы, которые могут иметь такие же имена, как у вновь создаваемых файлов.
Предварительные итоги
Теперь мы знаем, как подготовить сборку .NET для применения вместе со службами COM+. Эта подготовка включает в себя:
□ Снаряжение сборки рекомендованными атрибутами сборки
□ Соединение классов прокси с внутренними 'рабочими' классами посредством атрибута ComEmulate
□ Развертывание сборок с помощью sn.exe, al.exe и, возможно, RegSvcs.exe
Имея общую информацию, перейдем к обсуждению использования конкретных служб COM+ из сборок .NET. Начнем с транзакций.
Использование транзакций со сборками .NET
Существуют две вещи, которые необходимо сделать, чтобы подготовить класс .NET для транзакций. Первое: необходимо изменить прокси класса с помощью атрибута для указания его уровня поддержки транзакций. Второе: необходимо добавить в класс код для управления его поведением, когда он участвует в транзакциях.
