Как открыть макет с двоичными данными драйвера в 1С и заменить в нем библиотеку DLL?

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

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

Что хранится внутри макета двоичных данных

Тип макета Двоичные данные не привязан к конкретному расширению: внутри может содержаться произвольный поток байтов — от исполняемых файлов и библиотек до картинок и упакованных архивов. В типовых конфигурациях на базе Библиотеки подключаемого оборудования (БПО) макеты драйверов (например, ДрайверШтрихМФискальныеРегистраторы) практически всегда представляют собой упакованный ZIP-архив.

Если выгрузить такой макет из конфигуратора на диск, файлу необходимо вручную присвоить расширение .zip. После этого его можно открыть любым стандартным архиватором. Внутри архива располагаются:

  1. Файл описания — манифест (обычно MANIFEST.XML или info.xml).
  2. Файлы внешних компонент (динамические библиотеки .dll для операционных систем Windows и .so для Linux).
  3. Дополнительные вспомогательные файлы и документация поставщика драйвера.

Почему 1С не видит замененную DLL

Проанализируем ситуацию, при которой разработчик помещает новую библиотеку в архив макета, но платформа 1С отказывается с ней работать. Для этого есть несколько ключевых причин:

  1. Несоответствие манифеста. Файл MANIFEST.XML строго регламентирует структуру поставки: в нем зафиксированы точные имена файлов библиотек, их версии, поддерживаемые операционные системы, архитектуры процессора и используемая технология (Native API или COM). Если поместить в архив файл с другим именем или не скорректировать манифест, загрузчик БПО не сможет сопоставить библиотеку с текущей средой выполнения.
  2. Кэширование внешних компонент платформой. При первой установке драйвера 1С извлекает бинарные файлы и сохраняет их в каталог кэша текущего пользователя операционной системы. Если обновить макет в конфигураторе, но оставить номер версии в манифесте прежним, платформа посчитает компонент уже установленным и продолжит вызывать старую версию библиотеки из кэша.
  3. Несовпадение разрядности клиента и библиотеки. Разрядность клиентского приложения 1С должна строго соответствовать разрядности библиотеки: 32-разрядный клиент 1С (x86) физически не может загрузить 64-разрядную библиотеку (x86_64), и наоборот.
  4. Несовместимость интерфейсов. Типовые механизмы БПО ожидают, что внешняя компонента разработана по стандарту «1С:Совместимо» (например, реализует интерфейс IComponentBase для Native API). Если разработчик пытается внедрить произвольную системную библиотеку производителя, не адаптированную под требования 1С, платформа не сможет вызвать типовые методы инициализации.

Способ 1. Корректная перепаковка макета по стандартам БПО

Рассмотрим, как правильно отредактировать макет, если новая библиотека поддерживает стандартные интерфейсы подключаемого оборудования 1С.

  1. В дереве метаданных конфигуратора откройте свойства нужного макета и сохраните его на диск, явно указав расширение .zip.
  2. Распакуйте архив в отдельную папку.
  3. Замените нужный файл .dll на новую версию, обращая внимание на разрядность (рекомендуется подготавливать сборки как для 32-битного, так и для 64-битного клиента).
  4. Откройте файл MANIFEST.XML в текстовом редакторе и скорректируйте параметры:
    
    <bundle>
        <component type="Native" os="Windows" path="ShtrihDriver_x86.dll" architecture="i386"/>
        <component type="Native" os="Windows" path="ShtrihDriver_x64.dll" architecture="x86_64"/>
        <version>2.1.0.1</version>
    </bundle>
    
    Обязательно увеличьте номер версии в теге version, чтобы платформа принудительно перезаписала устаревшие файлы в кэше.
  5. Запакуйте все файлы обратно в ZIP-архив. Важно: файлы MANIFEST.XML и .dll должны лежать в корне архива, а не во вложенной подпапке.
  6. Загрузите полученный архив обратно в макет конфигуратора через команду Загрузить из файла.

Способ 2. Штатное обновление драйвера через режим «1С:Предприятие»

Разберем более безопасный и рекомендуемый разработчиками БПО путь, не требующий снятия конфигурации с поддержки и прямого редактирования макетов.

  1. Подготовьте ZIP-архив с библиотеками и обновленным манифестом, как описано в предыдущем шаге.
  2. Запустите информационную базу в режиме 1С:Предприятие под учетной записью с административными правами.
  3. Перейдите в раздел Администрирование — Подключаемое оборудование — Драйверы оборудования.
  4. Найдите в списке нужный драйвер или добавьте новый элемент.
  5. Нажмите кнопку Функции — Установить драйвер из файла (либо Обновить из файла) и укажите подготовленный ZIP-архив.
  6. Платформа автоматически прочитает манифест, зарегистрирует новую версию в справочнике и при следующем открытии рабочего места обновит компоненту на клиенте без вмешательства в конфигуратор.

Способ 3. Прямая работа со сторонней DLL через программный код

Посмотрим на пример, когда сторонняя библиотека не разрабатывалась под стандарты БПО и представляет собой классический COM-сервер (ActiveX/COM). В этом случае стандартный механизм драйверов БПО использовать не получится — потребуется обращаться к объекту напрямую из встроенного языка 1С.

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


// Извлекаем макет с двоичными данными во временный файл
ДвоичныеДанныеМакета = УправлениеОборудованием.ПолучитьМакет("ДрайверШтрихМФискальныеРегистраторы");
ИмяВременногоФайла = КаталогВременныхФайлов() + "CustomDriver.dll";
ДвоичныеДанныеМакета.Записать(ИмяВременногоФайла);

// Если библиотека COM зарегистрирована в Windows, инициализируем ее напрямую по ProgID
Попытка
    ДрайверCOM = Новый COMОбъект("AddIn.CustomShtrihDriver");
    // Вызов методов сторонней библиотеки
    ДрайверCOM.Connect();
Исключение
    Сообщить("Не удалось инициализировать COM-объект: " + ОписаниеОшибки());
КонецПопытки;

Рассмотренный подход позволяет полностью обойти типовые ограничения БПО и работать с нестандартными или самописными библиотеками напрямую из модулей конфигурации.

← На главную