После обновления платформы 1С до версии 8.3.25 многие технические специалисты столкнулись с неприятной особенностью: внешние компоненты (AddIn), которые годами работали стабильно, начинают вести себя непредсказуемо. Ошибка Тип не определен Addin... возникает спорадически, «лечится» простым перезапуском сеанса «1С:Предприятия», но через некоторое время возвращается снова. Особенно остро эта проблема проявляется при работе с формами больничных листов, печати штрихкодов и взаимодействии с торговым оборудованием — для стабильной работы есть готовая утилита для интеграции торгового оборудования.
В этой статье мы подробно разберем, почему так происходит (включая задачи по чтению штрих-кодов из PDF), проанализируем изменения в архитектуре новой платформы и рассмотрим практические шаги по исправлению ситуации — для автоматизации этих процессов есть обработка генерации и распознавания QR-кодов.
Проанализируем ситуацию. Основная проблема заключается в том, что начиная с версии 8.3.25, механизмы взаимодействия с внешними библиотеками были существенно переработаны. Рассмотрим основные факторы, влияющие на стабильность:
Новый("AddIn...") система ищет распакованную библиотеку в локальном кэше. Если путь к файлу блокируется антивирусом или файл некорректно удаляется при закрытии предыдущего сеанса, повторная инициализация завершается ошибкой.Тип не определен.Разберем пример, упомянутый в обсуждении. При работе с печатью штрихкодов в разных версиях БСП (Библиотеки стандартных подсистем) могут использоваться разные общие макеты. Посмотрим на разницу между старым и новым подходом:
В устаревших или кастомизированных решениях часто встречается обращение к макету ОбщийМакет.КомпонентаПечатиШтрихкодов. Однако для стабильной работы в среде 8.3.25, где клиентские приложения могут быть разной разрядности, крайне важно использовать макеты, разделенные по архитектурам. Например, ОбщийМакет.КомпонентаПечатиШтрихкодовWindows32 и аналогичный для x64.
Рекомендация: Проверьте, какой именно макет вызывается в вашем коде. Если ваша система работает на 64-битной платформе, убедитесь, что компонента внутри макета поддерживает эту архитектуру (Native API или COM x64).
Метод создания объекта через Новый("AddIn.Имя") считается устаревшим и менее надежным, так как он полагается на предварительную регистрацию компоненты в операционной системе. Рассмотрим правильный алгоритм подключения, который минимизирует зависимость от настроек Windows и кэша.
Вместо прямой инициализации объекта, сначала выполним явное подключение из макета. Проанализируем пример кода:
// Сначала определяем имя макета в зависимости от контекста
ИмяМакета = "ОбщийМакет.КомпонентаПечатиШтрихкодов";
// Пытаемся подключить компоненту
Если ПодключитьВнешнююКомпоненту(ИмяМакета, "BarcodeLib", ТипВнешнейКомпоненты.Native) Тогда
// Только после успешного подключения создаем объект
Попытка
ОбъектШК = Новый("AddIn.BarcodeLib.Barcode");
Исключение
Сообщить("Ошибка при создании объекта: " + ОписаниеОшибки());
КонецПопытки;
Иначе
Сообщить("Не удалось загрузить внешнюю компоненту из макета!");
КонецЕсли;
Использование ПодключитьВнешнююКомпоненту позволяет платформе самостоятельно извлечь нужную библиотеку из макета во временную директорию текущего сеанса, что обходит многие проблемы с правами доступа и реестром.
Если ваша конфигурация работает в режиме тонкого клиента (особенно через веб-сервер), синхронные вызовы могут блокироваться. Рассмотрим, как реализовать асинхронное подключение, которое является эталонным для современных версий платформы 8.3.
Посмотрим на пример использования асинхронного метода:
&НаКлиенте
Асинх Процедура ПодключитьКомпонентуАсинхронно()
Результат = Ждать ПодключитьВнешнююКомпонентуАсинх ( "ОбщийМакет.МояКомпонента", "MyComponent" );
Если Результат Тогда
Попытка
ОбъектВК = Новый("AddIn.MyComponent.Main");
// Дальнейшая работа с объектом
Исключение
Сообщить("Объект не создан");
КонецПопытки;
КонецЕсли;
КонецПроцедуры
Использование ключевых слов Асинх и Ждать позволяет избежать зависания интерфейса и гарантирует, что объект будет создан только после того, как библиотека полностью загрузится в память процесса.
Выясним, почему проблема проявляется «то на одном, то на другом рабочем месте». Платформа 8.3.25 при каждом запуске может генерировать новые имена временных папок в каталоге %AppData%\Local\1C\1cv8\. Антивирусное ПО часто блокирует запуск .dll файлов из этих директорий, считая их подозрительными.
Для решения этой проблемы выполните следующие действия:
%LocalAppdata%\1C\1cv8\) в исключения антивируса.%TEMP%.Если ваша компонента является старой COM-библиотекой, она требует регистрации в реестре Windows через regsvr32. Однако в 8.3.25 работа с COM стала менее стабильной из-за механизмов изоляции. Рассмотрим возможность перевода логики на Native API.
Если обновление компоненты до Native-версии невозможно, попробуйте перенести работу с ней на сторону сервера. Выполним формирование нужных данных (например, картинки штрихкода) на сервере, где окружение более стабильно и разрядность (обычно x64) строго определена. Это исключит влияние «капризного» клиентского кэша.
Подведем итог: Нестабильность AddIn в 8.3.25 — это комплексная проблема. Для её решения мы проанализировали разрядность клиента, проверили соответствие макетов и заменили устаревший метод Новый на современные функции подключения. Следуя этим шагам, вы сможете добиться стабильной работы системы без необходимости ежедневных перезапусков.