Почему при вызове COM-сервера на C# из 1С возникает ошибка «Базовое соединение закрыто»?

Работа с COM-объектами, написанными на .NET Framework, является классическим сценарием интеграции 1С с внешними библиотеками. Однако, часто разработчики сталкиваются с тем, что код, идеально работающий в отладчике Visual Studio, выдает загадочные ошибки при запуске непосредственно из платформы 1С. Разберем, почему возникает ошибка «Базовое соединение закрыто: Непредвиденная ошибка при передаче» и как с этим бороться.

Понимание природы проблемы

Ошибка «Базовое соединение закрыто» чаще всего указывает на сбой на этапе «рукопожатия» (handshake) между клиентом и сервером. Важно понимать, что когда мы вызываем методы DLL из 1С через COMОбъект, платформа 1С загружает CLR (Common Language Runtime) внутрь своего процесса. В этот момент вступают в силу ограничения безопасности и сетевые политики, которые могут отличаться от тех, что используются в сеансе отладки Visual Studio.

Шаг 1: Проверка настроек TLS

Одной из наиболее частых причин сброса соединения является несовпадение версий протоколов безопасности. По умолчанию старые версии .NET Framework могут пытаться использовать устаревшие протоколы SSL/TLS, которые современные сервера уже не поддерживают. Чтобы исправить это, принудительно укажите использование TLS 1.2 в статическом конструкторе вашего класса:

using System.Net;

public class MyComClass 
{
    static MyComClass() 
    {
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
    }
}

Шаг 2: Управление жизненным циклом и проблема блокировки DLL

Многие разработчики сталкиваются с тем, что файл DLL «заблокирован» системой даже после выполнения кода в 1С. Вызов COMОбъект = Неопределено в 1С лишь удаляет ссылку на экземпляр класса, но не выгружает сборку из памяти. Процесс 1cv8.exe продолжает удерживать DLL, пока не будет завершен полностью.

Рассмотрим, как правильно организовать работу:

1. Реализуйте интерфейс IDisposable: Добавьте в ваш класс метод очистки ресурсов. Хотя это не гарантирует моментальную выгрузку из памяти (так как AppDomain остается активным), это позволит корректно закрыть соединения и потоки.
2. Используйте теневое копирование (Shadow Copy): Если вы активно разрабатываете DLL, настройте в конфигурации вашего проекта использование теневых копий. Это позволит заменять файл библиотеки без перезагрузки 1С.
3. Вынос в отдельный процесс: Если стабильность является критическим фактором, рассмотрите возможность написания COM-сервера не как DLL, а как отдельного EXE-приложения. Это позволит вам перезапускать серверную часть независимо от 1С, просто завершая процесс через TaskKill или программно.

Шаг 3: Модель потоков (Threading Model)

Платформа 1С работает в однопоточном режиме (STA - Single Threaded Apartment). Если ваш COM-объект на C# настроен на работу в многопоточном режиме (MTA), при обращении из 1С могут возникать непредсказуемые исключения. Проверьте атрибуты вашего класса:

[ComVisible(true)]
[Guid("ваш-guid-здесь")]
[ProgId("MyProject.MyClass")]
[ClassInterface(ClassInterfaceType.None)]
public class MyComClass : IMyInterface 
{
    // Реализация методов
}

Убедитесь, что все операции, которые вы планируете вызывать из 1С, потокобезопасны и не требуют сложных контекстов, которые недоступны в рамках STA.

Рекомендации по отладке

Поскольку ошибка возникает до выполнения кода, логирование является вашим главным инструментом. Разберем простой способ внедрения: создайте простейший метод, который пишет текст в лог-файл на диске, вызываемый самым первым в конструкторе класса. Если файл не создается — проблема в самой регистрации COM-объекта (regasm) или в правах доступа пользователя, под которым работает 1С.

Помните, что запуск из Visual Studio происходит под вашим текущим пользователем, а 1С на сервере может запускаться под учетной записью «USR1CV8». Убедитесь, что у этой учетной записи есть полные права доступа к папке, где лежит ваша DLL и ко всем зависимым файлам.

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