Создание библиотек DLL для параллельных сборок

При создании собственных параллельных сборок следуйте указаниям по созданию параллельных сборок и создайте библиотеки DLL, используемые в сборке, в соответствии со следующими рекомендациями.

• Библиотеки DLL должны быть разработаны таким образом, чтобы несколько версий могли работать одновременно и в одном процессе, не мешая друг другу. Например, во многих приложениях размещается несколько подключаемых модулей, для которых требуется разная версия одного компонента. Разработчику параллельной сборки необходимо спроектировать и протестировать, чтобы убедиться, что несколько версий компонента работают правильно при одновременном запуске в одном процессе.

• Если вы планируете предоставить компонент в качестве общего компонента в системах, предшествующих Windows XP, необходимо продолжить установку компонента в этих системах в качестве общего компонента с одним экземпляром. В этом случае необходимо обеспечить обратную совместимость компонента.

• Оцените использование объектов , если в системе выполняется несколько версий сборки. Определите, требуются ли для разных версий сборки отдельные структуры данных, такие как сопоставленные в памяти файлы, именованные каналы, зарегистрированные сообщения и классы Windows, общая память, семафоры, мьютексы и аппаратные драйверы. Все структуры данных, используемые в разных версиях сборок, должны быть обратно совместимыми. Определите, какие структуры данных можно использовать в разных версиях, а какие структуры данных должны быть закрытыми для версии. Определите, требуются ли для общих структур данных отдельные объекты синхронизации, такие как семафоры и мьютексы.

• Некоторые объекты, такие как классы окон и atom, имеют уникальные имена для каждого процесса. Для каждой сборки с помощью манифеста должны быть версии таких объектов, как классы окон. Для таких объектов, как Atom, используйте идентификаторы для конкретных версий, если вы не планируете совместно использовать их в разных версиях. Если вы используете идентификаторы для конкретной версии, используйте четырехкомпонентный номер управления версиями.

• Не включать саморегистрирующийся код ни в одну библиотеку DLL. Библиотека DLL в параллельной сборке не может быть саморегистрируемой.

• Определите все имена для конкретных версий в библиотеке DLL с помощью инструкций #define. Это позволяет изменять все разделы реестра из одного расположения. При выпуске новой версии сборки необходимо изменить только этот оператор #define. Пример:

  #define MyRegistryKey "MyAssembly1.0.0.0"

• Храните все неперсистентные данные во временном каталоге.

• Не помещайте данные пользователей в глобальные расположения. Храните данные приложения отдельно от пользовательских данных.

• Назначьте всем общим файлам версию файла, которая зависит от имени приложения.

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

• Библиотека DLL не должна зависеть от совместного использования в разных версиях, которые могут не существовать, например от разделов общей памяти, которые не используются в разных версиях сборки.

• При добавлении новых функций, которые не соответствуют контракту совместимости двоичного интерфейса исходной библиотеки DLL, необходимо назначить новые CLSID, ProgId и имя файла. Затем для использования этих идентификаторов CLSID, ProgId и имени файла потребуются будущие версии параллельной сборки. Это предотвращает конфликт, когда версия библиотеки DLL, которая не является параллельной, регистрируется в параллельной версии.

• Если вы повторно используете тот же идентификатор CLSID или ProgId, проверьте, является ли сборка обратной совместимостью.

• Инициализируйте и задайте параметры по умолчанию для сборки в коде сборки. Не сохраняйте параметры по умолчанию в реестре.

• Назначьте версии всем структурам данных.

• Библиотека DLL должна хранить состояние параллельной сборки, как описано в статье Создание хранилища состояний для параллельных сборок.