Одной из неприятных особенностей командной разработки проектов может стать проблема сопряжения различных модулей/блоков, написанных разными группами исполнителей. Естественно, вопросы взаимодействия модулей должны быть максимально подробно описаны в техническом задании на разработку (ТЗ), однако даже в этом случае возможны определенные сложности.

В статье рассматриваются отдельные вопросы совместимости программных компонентов объектной модели COM (Component Object Model, модель компонентных объектов) и платформы .NET. Если быть точнее, детально рассматривается одно из решений проблемы использования управляемых (managed, под управлением платформы .NET) библиотек классов языка C#, использующих функциональные возможности платформы .NET, в коде на языке C++ (здесь и далее имеется в виду неуправляемый код C++, unmanaged, под управлением операционной системы).

Все примеры реализованы в среде программирования MS Visual Studio 2012 под управлением ОС Windows 7, платформа .NET версии 4.0.

В статье не приводятся общие сведения о компонентах COM и .NET и их сравнение, поскольку указанные вопросы подробно рассмотрены в справочниках по программированию, например, в замечательных книгах [1], [2] и [3]. Следует ограничиться лишь указанием причин, в соответствии с которыми в той или иной ситуации возможен рассматриваемый случай подключения библиотек классов, написанных на C# с использованием функционала .NET, к проектам на C++.

Во-первых, возможны случаи, когда проект разработки программного обеспечения (ПО) планировался для одной группы разработчиков, а в процессе уточнения технического задания потребовалось включение дополнительных групп исполнителей, использующих другие средства и инструменты разработки. Во-вторых, некоторые неточности или погрешности при составлении ТЗ могут привести к тому, что задание на разработку вспомогательных модулей будет перенаправлено внутри основной группы от одной подгруппы исполнителей к другой подгруппе, использующей отличный язык и/или платформу программирования. Кроме того, в условиях сжатых сроков на выполнение заключительных этапов более рациональным может стать «умышленное» перераспределение задач между подгруппами программистов.

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

Далее рассматривается практический пример из проекта разработки специализированного ПО, предназначенного для анализа сетевого трафика. На одном из заключительных этапов группе разработчиков потребовалось в кратчайшие сроки добавить возможность оповещения администратора системы по электронной почте при наступлении определенного класса событий. При этом задание на разработку модуля отправки сообщений было поручено исполнителям из подгруппы, специализирующейся на использовании C#, с указанием требования возможности его применения в основном проекте на C++.

Реализация взаимодействия компонент .NET и COM

Следует отметить, что существует несколько способов использовать управляемые библиотеки классов из неуправляемого кода C++ [4]. Ниже представлен один из возможных вариантов решения рассматриваемого вопроса, рекомендованный MSDN (Microsoft Developer Network, подразделение компании Майкрософт, ответственное за взаимодействие с разработчиками) [5].

Этап 1. Разработка управляемой библиотеки классов SendMailViaDotNet.DLL (DLL, Dynamic Link Library, динамически подключаемая библиотека).

Для реализации возможности отправки письма по электронной почте используются стандартные классы SmtpClient, MailMessage, MailAddress пространства имен System.Net.Mail. Исходный код библиотеки с комментариями представлен ниже (тип создаваемого проекта в среде Visual Studio – Библиотека классов, язык C#, название – SendMailViaDotNet):

Библиотека содержит объявление интерфейса IMailer и его реализацию с двумя методами TestMail() и SendMail(). Первый метод используется для быстрого тестирования работы с электронной почтой (для отправки письма используется учетная запись почтового сервиса gmail.com с использованием протокола SSL, Secure Sockets Layer, уровень защищённых сокетов), а второй содержит непосредственно блок кода, отвечающий за подготовку и отправку сообщения.

Чтобы убедиться в работоспособности библиотеки, можно создать минимальный тестовый проект C#:

В результате выполнения программы будет отправлено письмо на ящик WeGpdbnggfTV5T9VLXIL@gmail.com, в чем можно убедиться с помощью веб-интерфейса gmail.com. Предварительно следует проверить настройки антивируса и брандмауэра на предмет разрешения приложениям обращаться во внешнюю сеть. Кроме того, необходимо разрешить доступ приложениям к электронной почте в настройках безопасности учетной записи gmail.com.

Этап 2. Подписание сборки строгим именем, построение библиотеки, регистрация сборки в реестре.

Для того, чтобы использовать разработанную библиотеку в рамках модели COM, следует соответствующим образом настроить параметры сборки (assembly) библиотеки в файле AssemblyInfo.cs (рис. 1).

Рис. 1 – Настройка параметров сборки библиотеки

Необходимо заменить строки

[assembly: ComVisible(false)]

[assembly: AssemblyKeyFile("")]

на следующие:

[assembly: ComVisible(true)]

[assembly: AssemblyKeyFile("SendMail.SNK")]

Параметр ComVisible отвечает за «видимость» сборки с точки зрения модели COM. Параметр AssemblyKeyFile указывает на ключевой файл, используемый для подписания сборки так называемым «строгим» именем.

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

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

Задать строгое имя для сборки можно как в свойствах проекта (вкладка Подписывание), так и с помощью утилиты sn.exe, устанавливаемой вместе с Visual Studio.

Наиболее простой способ запуска утилиты – с использованием Командной строки разработчика для Visual Studio (типовое расположение в главном меню: Пуск > Программы > Microsoft Visual Studio 2012 > Visual Studio Tools > Командная строка разработчика для Visual Studio 2012).

Параметры запуска утилиты:

sn.exe -k SendMail.SNK

Результатом выполнения будет являться созданный ключевой файл SendMail.SNK, содержащий пару открытого и закрытого ключей (рис. 2). Скопировав созданный файл в папку проекта SendMailViaDotNet, необходимо построить (перестроить) решение. При этом закрытый ключ из файла SendMail.SNK будет использован для подписи сборки, а открытый ключ будет включен в сборку для проверки подписи сторонними приложениями.

Рис. 2 – Создание ключевого файла SendMail.SNK

Для того, чтобы созданная библиотека стала COM-видимой, её необходимо зарегистрировать в реестре с помощью утилиты regasm.exe. Следует отдельно подчеркнуть, что подписание сборки с помощью sn.exe производится на стороне разработчика, а регистрация сборки утилитой regasm.exe осуществляется как на стороне разработчика, так и на стороне клиента.

Наиболее простой способ запуска утилиты regasm.exe – также с использованием Командной строки разработчика. Далее необходимо перейти в папку с созданной библиотекой SendMailViaDotNet.dll и запустить утилиту с параметрами (рис. 3):

RegAsm.exe SendMailViaDotNet.dll /tlb:SendMailViaDotNet.tlb /codebase

Параметр /tlb указывает на необходимость создания библиотеки типов для указанной сборки, содержащей описания доступных типов. Параметр /codebase дополнительно создает в реестре соответствующую запись с указанием пути к файлу сборки, не установленной в глобальном кэше сборок GAC (Global Assembly Cache). Не следует указывать этот параметр, если впоследствии планируется устанавливать сборку в GAC.

При попытке зарегистрировать сборку с параметром /codebase, не подписанную строгим именем, утилита regasm.exe выведет предупреждение RA0000 о возможных конфликтах при взаимодействии сборки со сторонними приложениями.

Рис. 3 – Регистрация сборки в реестре

Этап 3. Разработка проекта SendMailCPP.

На заключительном этапе необходимо разработать проект C++, импортирующий ранее созданную библиотеку типов SendMailViaDotNet.tlb (тип создаваемого проекта в среде Visual Studio – Консольное приложение Win32, язык C++, название – SendMailCPP). Для этого необходимо использовать директиву #import с указанием полного пути к библиотеке типов:

Программа инициализирует модель COM; создает указатель на интерфейс IMailer, объявленный в импортируемой библиотеке типов; вызывает описанный в интерфейсе метод тестовой отправки письма TestMail(); выводит результат отправки на экран и освобождает ресурсы.

Перед запуском приложения на клиентской стороне необходимо зарегистрировать библиотеку SendMailViaDotNet.dll с помощью утилиты regasm.exe. Условие наличия утилиты – установленная платформа .NET. При этом, поскольку инструменты разработчика Visual Studio, скорее всего, будут отсутствовать на клиентском компьютере, необходимо запускать regasm.exe с указанием полных путей к файлам (рис. 4). Указание параметров /tlb и /codebase на клиентском компьютере не требуется.

Рис. 4 – Запуск приложения SendMailCPP.exe на стороне клиента

Выводы

Рассмотренное решение реализует на практике возможность использования компонент .NET в рамках модели COM и может быть формализовано в виде последовательности следующих этапов:

1. Разработка управляемой библиотеки классов на языке C# с использованием функционала платформы .NET.
   
2. Подписание сборки строгим именем, построение библиотеки, регистрация сборки в реестре.
   
3. Разработка проекта с неуправляемым кодом на языке C++ с использованием функционала ранее созданной библиотеки классов.
   

   Приведенный пример имеет как положительные особенности, так и недостатки.
   

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

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