Работа с внешними библиотеками, написанными на языке C#, часто вызывает вопросы при интеграции с 1С, особенно если целевой средой выступает не самая новая операционная система, такая как Windows Server 2008 R2. Давайте разберем по шагам, как правильно подготовить библиотеку, чтобы она корректно регистрировалась и работала с 32-битной или 64-битной 1С.
Первое, с чего стоит начать — это выбор правильной версии .NET Framework. Для Windows Server 2008 R2 наиболее стабильным и совместимым вариантом является использование .NET Framework 4.6.1. Использование более новых версий (например, .NET 5 или .NET Core) в данной ОС может потребовать сложной настройки зависимостей, поэтому лучше придерживаться классического варианта.
При создании проекта в Visual Studio выбирайте тип проекта Библиотека классов (.NET Framework). Если нужная версия Framework отсутствует в списке выбора при создании проекта, вам необходимо установить Developer Pack для соответствующей версии через установщик Visual Studio или сайт Microsoft.
Для того чтобы ваша DLL стала доступной для 1С как COM-объект, необходимо убедиться, что классы и интерфейсы помечены атрибутами ComVisible(true). Это позволяет 1С обращаться к методам вашего класса через COM-интерфейс.
При настройке проекта укажите целевую платформу AnyCPU. Это позволит DLL успешно работать как в 32-битных, так и в 64-битных процессах, что критически важно, так как сервер 1С может использовать 32-разрядный COM-коннектор.
Одной из самых частых ошибок является попытка регистрации DLL через regsvr32. Для .NET сборок этот метод не подходит, так как они не являются классическими COM-серверами. Вам необходимо использовать утилиту RegAsm.exe.
Разберем процесс регистрации по шагам:
RegAsm.exe из папки Framework:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe "ВашПутьКФайлу\MyLibrary.dll" /codebase
RegAsm.exe из папки Framework64:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe "ВашПутьКФайлу\MyLibrary.dll" /codebase
Ключ /codebase обязателен, так как он записывает полный путь к сборке в реестр, что позволяет 1С найти файл библиотеки после перезагрузки.
В процессе обсуждения мы столкнулись с тем, что результаты вычисления хеша SHA-1 в 1С и в C# могут не совпадать. Это происходит из-за различий в методах канонизации XML. 1С и .NET могут по-разному обрабатывать пробелы, переносы строк и атрибуты. Чтобы решить эту проблему, мы рекомендуем:
Приводить XML к каноническому виду перед передачей его в функцию хеширования. Если вы используете XmlDsigC14NTransform в C#, убедитесь, что именно этот алгоритм применяется и в 1С. Если стандартные средства 1С дают другой результат, самым надежным способом будет выполнение полной подготовки строки (канонизации) именно на стороне C#, передавая туда уже «сырую» или нормализованную строку, которую 1С должна отдать «как есть».
Если манипуляции с реестром вызывают трудности или вы хотите избежать проблем с правами доступа к реестру Windows, рассмотрите возможность использования вспомогательных компонентов, таких как NetObjectToIDispatch. Такие «врапперы» позволяют:
.NET сборки прямо из 1С.RegAsm..NET классов практически так же, как обычные объекты 1С.Этот подход значительно упрощает процесс отладки и обновления кода, так как вам не нужно каждый раз перерегистрировать библиотеку в системе после внесения изменений в код C#.
Подводя итог: для успешной работы на Windows Server 2008 R2 придерживайтесь связки .NET Framework 4.6.1, используйте RegAsm для регистрации и всегда проверяйте, что XML, участвующий в хешировании, канонизирован одинаковым способом на обеих сторонах интеграции.