Создание библиотек 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 должна хранить состояние параллельной сборки, как описано в разделе "Состояние разработки" служба хранилища для параллельных сборок.