При администрировании серверов 1С:Предприятие часто возникает ситуация, когда на одной физической или виртуальной машине необходимо запустить два разных релиза платформы. Это может быть связано с поддержкой старых баз, которые требуют специфической версии движка, и одновременным развитием новых проектов на актуальных релизах. Основная техническая сложность здесь заключается не в разделении портов или рабочих папок, а в работе библиотеки comcntr.dll, которая отвечает за COM-соединение.
В этой статье мы разберем, почему возникает конфликт, проанализируем механизмы работы Windows с COM-объектами и рассмотрим несколько способов обеспечения совместной работы разных версий коннектора.
Разберем ситуацию изнутри. Когда мы устанавливаем платформу 1С, библиотека comcntr.dll регистрируется в системном реестре Windows. Процесс регистрации создает запись с программным идентификатором (ProgID), который для всех версий 8.3 одинаков — V83.COMConnector.
Проанализируем путь в реестре: HKEY_CLASSES_ROOT\V83.COMConnector. В этой ветке указан уникальный идентификатор (CLSID), который, в свою очередь, ссылается на конкретный путь к файлу comcntr.dll в папке bin соответствующего релиза. При установке или регистрации новой версии платформы через regsvr32, старые данные в реестре просто перезаписываются. В результате система «видит» только ту версию библиотеки, которая была зарегистрирована последней. Если ваша база на релизе 8.3.18 пытается выполнить выполнение запросов через COM-подключение, а в системе зарегистрирован релиз 8.3.25, возникнет либо ошибка несоответствия версий, либо непредсказуемое поведение системы.
Это один из самых профессиональных и надежных способов изоляции. Рассмотрим этот метод подробнее. Вместо того чтобы полагаться на общую регистрацию библиотеки, мы создадим для каждой версии 1С отдельную «обертку» в операционной системе.
Выполним следующие шаги:
1C_COM_Connector_8_3_20.dllhost.exe.comcntr.dll из папки bin нужного релиза 1С.Этот метод позволяет изолировать выполнение библиотек. Однако стоит помнить, что программный вызов через Новый COMОбъект("V83.COMConnector") все равно может обращаться к последней зарегистрированной библиотеке. Для обращения к конкретному приложению COM+ иногда требуется использование суррогатных CLSID, что требует глубокой настройки реестра.
Выясним, можно ли заставить приложение использовать конкретную DLL, вообще не заглядывая в системный реестр. Да, для этого в Windows существуют манифест-файлы. Этот способ часто используется разработчиками для поставки компонентов вместе с приложением (Side-by-Side execution).
Разберем по шагам, как это реализовать:
.manifest.comcntr.dll и её уникальный CLSID.HKEY_CLASSES_ROOT.Этот метод идеален, если у вас есть стороннее ПО, подключающееся к 1С, но он трудноприменим, если вызовы происходят внутри самой платформы 1С между двумя базами, так как манифест пришлось бы создавать для самого процесса 1cv8.exe или rphost.exe, что крайне затруднительно.
Проанализируем более радикальный метод, который часто обсуждается на технических форумах. Если проблема в одинаковых именах V83.COMConnector, то почему бы не изменить это имя внутри самой библиотеки?
Внимание: данный метод является нарушением целостности файлов поставки и может привести к нестабильности. Рассмотрим его исключительно в ознакомительных целях:
comcntr.dll.V83.COMConnector.V82.COMConnect1. Важно: длина строки должна остаться неизменной.regsvr32.В коде 1С вызов будет выглядеть следующим образом:
// Вместо стандартного вызова
// Соединитель = Новый COMОбъект("V83.COMConnector");
// Используем измененное имя
Соединитель = Новый COMОбъект("V83.COMConnect1");
Этот метод требует изменения конфигурации, что не всегда допустимо, и полностью «слетает» при обновлении платформы.
Рассмотрим важный нюанс, о котором часто забывают. Библиотека comcntr.dll не работает сама по себе. Она зависит от множества других вспомогательных файлов (графические библиотеки, средства защиты, библиотеки работы с сетью). Для понимания таких связей можно использовать веб-инструмент для анализа зависимостей конфигураций 1С. Сами файлы зависимостей часто располагаются в папке C:\Program Files\Common Files\1C\1cv8\common.
Проанализируем ситуацию: если две разные версии COM-коннектора пытаются одновременно загрузить разные версии одной и той же зависимости из Common Files, процесс dllhost.exe (в случае с COM+) или rphost.exe может аварийно завершиться. В таких условиях также часто требуется удаление спящих сеансов 1С для восстановления работоспособности. Именно поэтому даже изоляция через COM+ не дает 100% гарантии стабильности при очень большой разнице в релизах платформы.
Выясним, стоит ли вообще бороться с COM-объектами в современных реалиях. Технологическое сообщество и сама фирма 1С все чаще рекомендуют отказываться от COM-соединений в пользу веб-технологий.
Посмотрим на альтернативы:
Если перед нами стоит задача запустить две версии 1С на одном сервере и обеспечить работу COM:
comcntr.dll раз и навсегда.Помните, что любые манипуляции с реестром и системными DLL — это временные меры, которые усложняют дальнейшую поддержку и обновление системы. Работайте структурно и выбирайте наиболее отказоустойчивые методы интеграции.