Почему не подключается DLL к 1С и как правильно разработать внешнюю компоненту?

← На главную

При разработке и расширении функционала систем на платформе 1С:Предприятие часто возникает необходимость вынести сложные расчеты или интеграционные механизмы в отдельные библиотеки (DLL). Однако при попытке подключить стандартную библиотеку, написанную, например, на C# (.NET), разработчики сталкиваются с тем, что платформа отказывается ее загружать. Рассмотрим подробнее, почему так происходит, проанализируем архитектурные ограничения 1С и разберем по шагам рабочие способы решения этой задачи.

В чем причина проблемы?

Типичная ошибка при создании внешних компонент — попытка загрузить обычную динамическую библиотеку, содержащую стандартные классы. Выясним причину, почему код обычного класса C# не будет работать в 1С напрямую. Платформа 1С:Предприятие не умеет взаимодействовать со случайными бинарными файлами. Для того чтобы успешно загрузить библиотеку через метод ПодключитьВнешнююКомпоненту, эта библиотека должна быть создана по строго определенным стандартам и содержать специфические интерфейсы взаимодействия, которые ожидает увидеть платформа 1С.

Существует два основных поддерживаемых стандарта для внешних компонент 1С:

Технология COM (ActiveX) — классический вариант, который работает только под управлением операционной системы Windows и требует регистрации библиотеки в системном реестре.
Технология Native API — современный кроссплатформенный стандарт 1С, позволяющий компоненте работать на Windows, Linux, macOS и мобильных платформах без регистрации в реестре.

Если ваша DLL представляет собой стандартную сборку .NET (как в случае с обычным классом расчетов), платформа 1С не сможет инициализировать ее как внешнюю компоненту. Ниже мы разберем четыре практических варианта решения этой проблемы.

Вариант 1. Адаптация библиотеки под технологию COM (Windows)

Если решение планируется использовать исключительно на компьютерах под управлением ОС Windows, мы можем доработать код C# так, чтобы класс стал доступен для вызова через COM-объекты. Для этого программисту на C# необходимо выполнить следующие действия:

Сделать класс и его методы публичными.
Добавить атрибут [ComVisible(true)] для интерфейса и класса.
Задать уникальный идентификатор Guid для сборки.
Зарегистрировать готовую DLL на целевом компьютере с помощью системной утилиты regasm.exe (желательно использовать ключ /codebase для явного указания пути).

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


Попытка
    Компонента = Новый COMОбъект("JTDLL.MathClass");
    Результат = Компонента.GetSumm(2, 3);
Исключение
    Сообщить("Не удалось запустить компоненту. Проверьте регистрацию DLL в системе!");
КонецПопытки;

Важное ограничение: Данный способ не является кроссплатформенным, требует прав администратора на клиентских машинах для регистрации библиотеки и не подходит для работы в веб-клиенте.

Вариант 2. Разработка полноценной Native API компоненты

Если нам нужна кроссплатформенность, стабильная работа на сервере 1С под Linux и загрузка компоненты напрямую из макета (без предварительной установки в ОС), библиотеку необходимо разработать по стандарту Native API. Обычно такие компоненты пишутся на C++, Rust или Delphi.

Разберем по шагам общую схему создания такой компоненты:

За основу берется официальный шаблон внешней компоненты (его можно скачать на ИТС). Шаблон содержит реализацию обязательного интерфейса IComponentBase.
В коде компоненты переопределяются методы инициализации, регистрации свойств и методов, которые будут видны в 1С.
Проект компилируется под целевые платформы (например, в .dll для Windows и в .so для Linux).
Все полученные файлы упаковываются в один ZIP-архив вместе с файлом манифеста (XML), где указывается, какой файл под какую операционную систему и разрядность процессора (x86/x64) нужно загружать.
ZIP-архив загружается в макет 1С как "Двоичные данные" и подключается стандартным кодом:


&НаКлиенте
Процедура ПодключитьКомпоненту()
    УстановитьРасширениеРаботыФайлов();
    РезультатПодключения = ПодключитьВнешнююКомпоненту("ОбщийМакет.МояКомпонентаNative", "MyComp", ТипВнешнейКомпоненты.Native);
    Если РезультатПодключения Тогда
        ОбъектКомпоненты = Новый("AddIn.MyComp.MyExtension");
    КонецЕсли;
КонецПроцедуры

Вариант 3. Использование готовых Native API «загрузчиков»

Что делать, если логику очень хочется писать именно на C#, но требования кроссплатформенности и загрузки из макета не позволяют использовать стандартный COM? Для этого существуют готовые решения-мосты (так называемые CLR Host компоненты).

Принцип их работы прост: в макет 1С помещается готовая внешняя компонента, написанная по стандарту Native API. Она умеет запускать среду выполнения .NET прямо внутри процесса 1С. Через эту промежуточную компоненту вы передаете путь или двоичные данные вашей C# библиотеки, и загрузчик позволяет вызывать любые методы из .NET. Единственным ограничением здесь выступает то, что передаваемые типы данных должны быть простыми (строки, числа, булевы значения).

Вариант 4. Использование технологии NativeAOT или Unmanaged Exports в C#

Современные версии платформы .NET (начиная с .NET 7 и 8) поддерживают компиляцию управляемого кода в нативный код (NativeAOT). Также в старых версиях .NET Framework можно использовать специализированные NuGet-пакеты (например, DllExport).

Этот подход позволяет экспортировать функции из C# библиотеки в классическом стиле C++. Таким образом, ваш программист на C# сможет реализовать необходимые интерфейсы 1С Native API непосредственно в среде разработки Visual Studio без использования C++. На выходе вы получите нативную DLL, которую 1С распознает стандартным образом.

Альтернативный вариант: вынос бизнес-логики в микросервис

Проанализируем ситуацию, когда расчетная библиотека получается слишком сложной, зависит от множества сторонних библиотек или требует специфического окружения. В этом случае попытка внедрить ее внутрь процесса 1С как DLL может привести к нестабильной работе всей системы (например, утечка памяти в компоненте способна «уронить» рабочий процесс сервера 1С rphost).

Рекомендуется рассмотреть альтернативный архитектурный паттерн — вынесение логики в отдельный веб-сервис (например, на ASP.NET Core):

Разработчик создает небольшое консольное или Web API приложение на C#, которое работает как самостоятельная служба.
Эта служба запускается локально или на выделенном сервере и слушает определенный порт.
1С общается с этой службой посредством отправки HTTP-запросов.

Посмотрим, как выглядит отправка запроса к такому сервису из кода 1С:


Соединение = Новый HTTPСоединение("localhost", 5000);
Запрос = Новый HTTPЗапрос("/api/math/getsumm?a=2&b=3");
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
    Результат = Ответ.ПолучитьТелоКакСтроку(); // Получаем результат вычисления
КонецЕсли;

Преимущества такого подхода очевидны: полная изоляция памяти 1С от стороннего кода, независимость от разрядности платформы (32- или 64-бит), легкая масштабируемость и простота обновления логики без необходимости изменять метаданные и конфигурацию 1С.