Как зарегистрировать comcntr.dll сразу для двух версий платформ 8.3?

← На главную

При работе с несколькими версиями платформы 1С:Предприятие 8.3 на одном сервере часто возникает классическая проблема: библиотека comcntr.dll (COM-соединитель) при обычной регистрации через regsvr32 перезаписывает данные в реестре. В результате в системе остается "активной" только та версия, которая была зарегистрирована последней. Это приводит к ошибкам в программах, ожидающих работу с другим релизом платформы. Проанализируем ситуацию и разберем по шагам, как заставить разные версии работать параллельно.

Почему возникает конфликт версий?

Выясним причину проблемы. Каждая библиотека COM-объекта имеет свой уникальный идентификатор — CLSID. У всех версий comcntr.dll в рамках ветки 8.3 (от 8.3.1 до 8.3.25 и выше) этот идентификатор одинаковый. Когда мы выполняем стандартную регистрацию, Windows просто обновляет путь к файлу .dll в реестре для этого конкретного CLSID. Рассмотрим ситуацию: если вы зарегистрировали версию 8.3.10, а затем 8.3.12, система будет всегда вызывать 8.3.12, даже если ваше приложение явно просит старую версию.

Способ 1. Использование служб компонентов COM+ (рекомендуемый)

Это наиболее надежный и профессиональный метод. Он позволяет изолировать каждую версию библиотеки в отдельном процессе и назначить им уникальные программные идентификаторы (ProgID). Разберем этот процесс подробно:

Откроем оснастку Службы компонентов (Component Services). Это можно сделать через "Панель управления" — "Администрирование" или введя dcomcnfg в строке поиска Windows.
Перейдем в дерево: Консоль корня — Службы компонентов — Компьютеры — Мой компьютер — Приложения COM+.
Создадим новое приложение. Нажмем правой кнопкой на папку Приложения COM+, выберем "Создать" — "Приложение".
В мастере установки выберем "Создать новое приложение". Введем понятное имя, например, 1C_COM_8.3.10. Способ активации укажем "Серверное приложение" (Server application).
Укажем пользователя, от имени которого будет запускаться процесс. Обычно это специально созданная доменная или локальная учетная запись с правами доступа к каталогам 1С.
После создания приложения раскроем его ветку, найдем папку Компоненты. Нажмем правой кнопкой — "Создать" — "Компонент".
Выберем "Установка новых компонентов" и укажем путь к файлу comcntr.dll нужной версии (например, из папки C:\Program Files\1cv8\8.3.10.XXXX\bin\).

Теперь самое важное: чтобы обращаться к этой конкретной версии из кода, нам нужно изменить её ProgID. В свойствах созданного компонента на вкладке "Общие" или через реестр можно убедиться, что теперь у нас есть изолированный объект. Однако стандартно в коде 1С используется вызов:


// Стандартный вызов
Соединитель = Новый COMОбъект("V83.COMConnector");

Чтобы использовать конкретную версию из COM+, в настройках компонента можно задать альтернативный идентификатор. Тогда вызов в коде будет выглядеть так:


// Вызов конкретной версии через COM+
Соединитель = Новый COMОбъект("V83.COMConnector.8310");

Способ 2. Принцип обратной совместимости 8.3

Рассмотрим альтернативный взгляд на проблему. Платформа 1С 8.3 обладает хорошей обратной совместимостью. Проанализируем ситуацию: в большинстве случаев comcntr.dll от более нового релиза (например, 8.3.23) прекрасно подключается к базам, работающим на старых релизах (8.3.10, 8.3.12).

Решение: Просто зарегистрируйте самую последнюю версию платформы, установленную на сервере, стандартным способом через regsvr32. Посмотрим на практику: в 90% случаев это решает все конфликты, так как новый COM-соединитель умеет взаимодействовать со старыми серверами приложений. Ошибки обычно возникают только при обратной ситуации (старый COM пытается подключиться к новой базе).

Способ 3. Использование Automation Server (V83.Application)

Если специфика вашей задачи позволяет, можно отказаться от V83.COMConnector в пользу V83.Application. Разберем, в чем разница:

COMConnector — это "легкое" соединение, работающее внутри вашего процесса. Оно не имеет интерфейса и потребляет меньше памяти.
V83.Application — это полноценный запуск клиентского приложения 1С. Он требует больше ресурсов, но позволяет более гибко управлять версией через параметры запуска.

Пример использования V83.Application:


// Запуск полноценного приложения
Соединение = Новый COMОбъект("V83.Application");
Результат = Соединение.Connect("Srvr=""ServerName"";Ref=""BaseName"";");

Нюансы разрядности (x86 против x64)

Часто проблема кроется не только в номере версии, но и в битности системы. Если ваше вызывающее приложение 32-битное, оно будет искать 32-битную DLL. Если 64-битное — соответственно, 64-битную. При использовании метода COM+ (Способ 1) эта проблема нивелируется, так как в настройках приложения COM+ на вкладке "Конструирование" (Pooling & Recycling) можно принудительно указать разрядность процесса dllhost.exe, который будет хостить вашу библиотеку.

Прямая правка реестра (для опытных пользователей)

Проанализируем еще один способ, который упоминался как "грязный". Можно вручную создать новые ветки в реестре HKEY_CLASSES_ROOT, скопировав структуру V83.COMConnector, но изменив имя и сославшись на новый CLSID, который вы сами сгенерируете. Однако мы не рекомендуем этот метод, так как любое обновление платформы или запуск "восстановления" установки 1С затрет ваши ручные изменения, и систему придется настраивать заново.

Подведем итоги

Мы рассмотрели несколько вариантов решения задачи. Оптимальный алгоритм действий выглядит так:

Сначала попробуйте просто зарегистрировать самую новую версию comcntr.dll. Скорее всего, она покроет потребности всех ваших программ.
Если это не помогло и возникают специфические ошибки совместимости, используйте Службы компонентов COM+ для создания изолированных окружений под каждую версию.
В коде 1С или внешних скриптах используйте обращение к созданным COM+ приложениям по их уникальным именам.

Использование COM+ не только решает проблему версионности, но и повышает стабильность системы: если COM-соединение "упадет" с критической ошибкой, оно не потянет за собой основное приложение, так как работает в изолированном процессе dllhost.exe.