← На главную

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

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

Ошибка System.Reflection.TargetException: Объект не соответствует конечному типу при вызове событий из DataReceivedHandler — это классический симптом нарушения потоковой безопасности. Суть проблемы заключается в следующем:

1. Событие DataReceived в классе SerialPort генерируется средой .NET в отдельном фоновом потоке из пула нитей (Thread Pool).
2. 1С работает в своем основном потоке, который управляет интерфейсом и логикой приложения.
3. Когда вы вызываете метод testEvent() из обработчика события порта, вы пытаетесь «достучаться» до объектов 1С из «чужого» потока.
4. Платформа 1С строго следит за тем, чтобы все вызовы методов компонентов происходили из того же контекста, в котором компонента была инициализирована. Попытка вызова из фонового потока приводит к конфликту доступа к памяти и мгновенному падению процесса (Access Violation).

Тот факт, что проблема проявляется на одних компьютерах и отсутствует на других, объясняется особенностями планировщика ОС и загрузкой процессора: иногда фоновому потоку «везет» выполнить вызов в нужный момент, но полагаться на это при разработке нельзя.

Способ решения №1: Микросервисная архитектура (рекомендуемый подход)

Современным стандартом надежности является вынос работы с «тяжелым» или нестабильным оборудованием во внешний процесс (микросервис). Рассмотрим плюсы такого подхода:

• Изоляция процессов: Если код на C# упадет с ошибкой, это приведет к остановке только вашего микросервиса, а не всей базы 1С.
• Удобство отладки: Вы можете запускать микросервис отдельно от 1С и использовать все инструменты Visual Studio для пошаговой отладки.
• Независимость: Обновление логики работы с оборудованием не требует перерегистрации компоненты или перезапуска 1С.

Как реализовать связь:

Вместо попытки заставить ВК «кричать» в 1С, настройте обмен через HTTP. 1С может периодически опрашивать микросервис, либо, если требуется мгновенное оповещение, опубликуйте HTTP-сервис на стороне 1С. В этом случае ваш микросервис при получении данных от считывателя просто отправляет POST-запрос на адрес опубликованного HTTP-сервиса 1С.

Способ решения №2: Синхронизация потоков внутри ВК

Если вы хотите сохранить текущую архитектуру с использованием ВК, необходимо правильно передать данные из фонового потока в основной поток 1С. Не вызывайте методы 1С напрямую из обработчика DataReceivedHandler.

Порядок действий:

1. Создайте потокобезопасную очередь данных (например, ConcurrentQueue) внутри вашего класса компоненты.
2. В обработчике DataReceivedHandler только сохраняйте полученные данные в эту очередь.
3. Используйте механизм PostMessage (через Windows API), чтобы послать системное сообщение главному окну 1С.
4. При получении такого сообщения 1С должна выполнить процедуру ОбработкаВнешнегоСобытия, внутри которой она безопасно заберет накопленные данные из вашей очереди через публичный метод компоненты.

Этот метод исключает прямые вызовы из фоновых потоков и полностью устраняет причину «вылетов».

Способ решения №3: Опрос через таймер

Это самый простой в реализации, но менее оперативный метод. Вы можете не генерировать события из ВК вообще, а хранить данные во внутреннем буфере (свойстве компоненты).

Алгоритм:

1. В 1С создайте ПодключитьОбработчикОжидания с интервалом, например, 100-200 мс.
2. В процедуре обработчика вызывайте метод компоненты ЕстьНовыеДанные().
3. Если метод возвращает Истина, вызывайте ПолучитьДанные(), чтобы считать информацию из буфера.

Этот способ позволяет избежать сложной синхронизации потоков, так как все вызовы происходят исключительно из основного потока 1С.

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