Создание библиотек DLL для параллельных сборок
При создании собственных параллельных сборок следуйте рекомендациям по созданию параллельных сборок и создайте все библиотеки DLL, используемые в сборке, в соответствии со следующими рекомендациями:
DLL-библиотеки должны быть разработаны таким образом, чтобы несколько версий могли выполняться одновременно и в одном процессе, не влияя друг на друга. Например, многие приложения размещают несколько подключаемых модулей, для каждого из которых требуется другая версия одного компонента. Разработчик параллельной сборки должен разрабатывать и тестировать, чтобы обеспечить правильную работу нескольких версий компонента при одновременном выполнении в одном процессе.
Если вы планируете предоставить компонент в качестве общего компонента в системах, предшествующих Windows XP, необходимо продолжить установку компонента в этих системах в качестве общего компонента с одним экземпляром. В этом случае необходимо убедиться, что ваш компонент обладает обратной совместимостью.
Оцените использование объектов, если в системе выполняется несколько версий сборки. Определите, требуются ли для разных версий сборки отдельные структуры данных, такие как файлы, сопоставленные с памятью, именованные каналы, зарегистрированные сообщения и классы Windows, общая память, семафоры, мьютексы и аппаратные драйверы. Все структуры данных, используемые в версиях сборок, должны быть обратно совместимыми. Определите, какие структуры данных можно использовать в разных версиях и какие структуры данных должны быть закрытыми для версии. Определите, требуют ли общие структуры данных отдельные объекты синхронизации, такие как семафоры и мьютексы.
Некоторые объекты, такие как классы окон и Атомы, уникально именуются для каждого процесса. Объекты, такие как классы окон, должны версионироваться для каждой сборки с помощью манифеста. Для таких объектов, как Atom, используйте идентификаторы, относящиеся к версии, если вы не планируете предоставлять общий доступ между версиями. Если вы используете идентификаторы для конкретной версии, используйте номер версии из четырех частей.
Не включайте саморегистрирующийся код в библиотеку DLL. DLL-библиотека в параллельной сборке не может быть саморегистрирующейся.
Определите все имена версий в библиотеке DLL с помощью инструкций #define. Это позволяет изменять все разделы реестра из одного расположения. При выпуске новой версии сборки необходимо изменить только эту инструкцию #define. Например:
#define MyRegistryKey "MyAssembly1.0.0.0"Храните все непредусмотримые данные в каталоге Temp.
Не помещайте данные пользователей в глобальные расположения. Сохраняйте данные приложения отдельно от пользовательских данных.
Назначьте всем общим файлам версию, зависящую от имени приложения.
Назначьте версию всем сообщениям и структурам данных, используемым в межпроцессах, чтобы предотвратить непреднамеренный общий доступ.
Ваша библиотека DLL не должна зависеть от ресурсов, общих для версий, которые могут не существовать, например, разделов общей памяти, которые не являются общими для разных версий сборки.
Если вы добавите новые функции, которые не соответствуют контракту совместимости двоичного интерфейса исходной библиотеки DLL, необходимо назначить новый CLSID, ProgId и имя файла. Будущие версии вашей параллельной сборки должны использовать этот CLSID, ProgId и имя файла. Это предотвращает конфликт, если версия библиотеки DLL, которая не является параллельной, регистрируется поверх параллельной версии.
Если вы повторно используете тот же CLSID или ProgId, проверьте, что сборка совместима с предыдущими версиями.
Инициализировать и задать параметры по умолчанию для сборки в коде сборки. Не сохраняйте параметры по умолчанию в реестре.
Назначение версий всем структурам данных.
Ваша библиотека DLL должна сохранять состояние параллельной сборки, как описано в Создание хранилища состояния для параллельных сборок.