Как исправить ошибку «DllRegisterServer не найдена» при регистрации внешней компоненты 1С на .NET?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При интеграции сторонних решений или оборудования с системой 1С программисты часто сталкиваются с необходимостью регистрации внешних компонент в операционной системе Windows. Одной из наиболее распространенных проблем является ошибка: «Модуль загружен, но точка входа DllRegisterServer не найдена». Попытки зарегистрировать библиотеку стандартным способом через утилиту regsvr32.exe заканчиваются неудачей. Давайте разберем природу этой ошибки и подробно рассмотрим, как правильно зарегистрировать такую компоненту в системе.

Выясняем причину возникновения ошибки

Для начала проанализируем ситуацию и поймем, почему операционная система выдает подобное сообщение. Утилита regsvr32.exe исторически предназначена для регистрации классических (unmanaged) COM-библиотек, написанных на языках C++ или Delphi. В процессе регистрации она обращается к DLL-файлу и пытается вызвать вшитую в него стандартную функцию DllRegisterServer, которая отвечает за внесение необходимых записей в реестр Windows.

Если внешняя компонента была разработана на платформе .NET (C# или VB.NET), она является управляемым (managed) кодом. В таких библиотеках по умолчанию нет и не может быть экспортируемой нативной функции DllRegisterServer. Соответственно, использовать утилиту regsvr32.exe для .NET-компонент абсолютно бесполезно — это всегда будет приводить к ошибке инициализации точки входа.

Решение 1: Правильная регистрация с помощью утилиты RegAsm

Для регистрации .NET-сборок в качестве COM-серверов в операционной системе Windows предусмотрена специализированная утилита — regasm.exe (Assembly Registration Tool). Она считывает метаданные из сборки и вносит в реестр записи, которые позволяют COM-клиентам (включая платформу 1С) беспрепятственно создавать .NET-объекты. При необходимости можно ознакомиться с практическим руководством по созданию внешних компонент из сборок .NET.

Рассмотрим по шагам, как правильно выполнить регистрацию с помощью пакетного файла (BAT-скрипта). При написании скрипта критически важно учитывать разрядность запускаемой платформы 1С и версию платформы .NET Framework.

Создадим текстовый файл с расширением .bat (например, register_com.bat) и поместим в него следующий код:


echo off
setlocal

rem Регистрация для 32-битных клиентов 1С (x86)
%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe "%~dp0AddIn_Bot_NET.dll" /codebase /tlb

rem Регистрация для 64-битных клиентов и серверов 1С (x64)
%SystemRoot%\Microsoft64\v4.0.30319\RegAsm.exe "%~dp0AddIn_Bot_NET.dll" /codebase /tlb

pause

Давайте подробно разберем ключевые параметры и особенности работы этого скрипта:

  1. Разрядность (Bitness): Обратите внимание, что мы вызываем regasm.exe дважды из разных папок: Framework (для 32-битных приложений) и Framework64 (для 64-битных). Если ваша база 1С запускается под 32-битным клиентом, а компоненту вы зарегистрируете только через 64-битный каталог, то 1С просто не сможет инициализировать объект. Рекомендуется регистрировать библиотеку в обоих режимах.
  2. Версия .NET Framework: Путь содержит значение v4.0.30319. Это актуально для библиотек, написанных под .NET Framework версий 4.0–4.8. Если внешняя компонента очень старая (создана под .NET 2.0–3.5), вам потребуется изменить версию в путях на v2.0.50727.
  3. Ключ /codebase: Этот параметр жизненно необходим. Без него утилита зарегистрирует библиотеку, но Windows будет искать сам DLL-файл только в глобальном кэше сборок (GAC). Ключ /codebase прописывает в реестр точный физический путь к текущему расположению вашей DLL-библиотеки.
  4. Ключ /tlb: Данный параметр генерирует и регистрирует библиотеку типов (файл с расширением .tlb), что позволяет COM-клиентам корректно распознавать типы данных и методы компоненты.

Если в будущем вам потребуется корректно удалить внешнюю компоненту из системы и очистить реестр, используйте скрипт разрегистрации с ключом /unregister:


echo off
setlocal

%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe /unregister "%~dp0AddIn_Bot_NET.dll"
%SystemRoot%\Microsoft64\v4.0.30319\RegAsm.exe /unregister "%~dp0AddIn_Bot_NET.dll"

pause

Решение 2: Безопасная регистрация без прав администратора (альтернатива отключению UAC)

Очень часто на форумах советуют полностью отключить контроль учетных записей (UAC) в Windows для успешного выполнения скриптов регистрации. Настоятельно рекомендуем избегать этого метода. Отключение UAC ставит под угрозу безопасность операционной системы, а в корпоративной среде это обычно запрещено групповыми политиками безопасности.

Зарегистрировать .NET-компоненту можно без прав администратора в контексте текущего пользователя. Для этого выполним следующие действия:

  1. На компьютере разработчика сгенерируем файл реестра с помощью следующей команды: regasm.exe ИмяКомпоненты.dll /regfile:addin.reg /codebase
  2. Откроем полученный файл addin.reg в любом текстовом редакторе (например, в Блокноте).
  3. Выполним автоматическую замену: найдем все упоминания ветки реестра HKEY_CLASSES_ROOT и заменим их на пользовательскую ветку HKEY_CURRENT_USER\Software\Classes.
  4. Сохраним изменения и запустим файл addin.reg на целевом компьютере под учетной записью обычного пользователя без административных прав.

После выполнения этой несложной операции библиотека будет успешно прописана в пользовательской ветке реестра. Платформа 1С сможет без проблем вызывать её методы, а безопасность операционной системы не будет нарушена.

Решение 3: Нюансы для современных компонент на .NET Core и .NET 5+

Проанализируем развитие технологий Microsoft. Если ваша внешняя компонента разработана не на старом .NET Framework, а на современных кроссплатформенных версиях (.NET Core, .NET 5, 6, 7 или 8), классический инструмент regasm.exe для нее использовать нельзя — его просто не существует в новых версиях платформы.

В современном .NET механизм работы с COM изменен. При сборке проекта с включенной поддержкой COM-видимости компилятор создает два файла: саму библиотеку ИмяКомпоненты.dll и специальный нативный файл-мост ИмяКомпоненты.comhost.dll. Этот файл-посредник берет на себя всю работу по взаимодействию с COM-интерфейсами ОС Windows.

Поскольку comhost.dll является классической нативной библиотекой, она уже содержит функции регистрации. Соответственно, в данном сценарии **нужно использовать стандартную утилиту** regsvr32.exe, но указывать именно файл-мост:

regsvr32.exe "%~dp0ИмяКомпоненты.comhost.dll"

Архитектурная альтернатива: переход на Native API

Использование технологии COM для подключения внешних компонент в 1С постепенно устаревает. Это привязывает вашу систему исключительно к ОС Windows и накладывает массу ограничений при работе в клиент-серверном режиме (особенно если сервер 1С работает под управлением Linux).

Современным стандартом разработки расширений является технология Native API от компании 1С. Рассмотрим преимущества её использования:

Для загрузки и инициализации такой компоненты в коде 1С используется метод УстановитьВнешнююКомпоненту. Посмотрим на практический пример реализации подключения:


&НаКлиенте
Процедура ПодключитьВнешнююКомпонентуNative()
    ИмяМакета = "ОбщийМакет.МояВнешняяКомпонента";
    
    // Платформа автоматически проверяет наличие компоненты на диске, при необходимости скачивает и регистрирует ее локально
    Если УстановитьВнешнююКомпоненту(ИмяМакета) Тогда
        Если ПодключитьВнешнююКомпоненту(ИмяМакета, "MyComponent", ТипВнешнейКомпоненты.Native) Тогда
            КомпонентаОбъект = Новый("AddIn.MyComponent.Extension");
            // Теперь объект готов к работе, можно вызывать его методы
            КомпонентаОбъект.ВыполнитьДействие();
        Иначе
            Сообщить("Не удалось подключить компоненту Native API в сеансе.");
        КонецЕсли;
    Иначе
        Сообщить("Не удалось установить внешнюю компоненту на локальный диск.");
    КонецЕсли;
EndProcedure

Для разработки под Native API на языке C# существуют готовые библиотеки-обертки (например, DllExport), которые позволяют экспортировать методы напрямую из управляемого кода, обеспечивая полную кроссплатформенность и стабильность работы вашего решения без использования COM-технологий. В качестве альтернативы можно использовать готовую компоненту Native API для загрузки .NET-сборок без регистрации в реестре.

← На главную