1С 8.2 зависает при подключении dll с опцией /CLR #522583

Добрый день, столкнулся с проблемой зависания CLR-библиотеки при подключении ее из 1С 8.2. Многие слышали о выходе новой версии 1С:Предприятие 8.2 и знают о планах отказаться от поддержки 8.1 в первом квартале 2011 года. В версии 8.2 1С анонсировала новый способ написания внешних компонент 1С с использованием так называемого Native API. Самое интересное, что на C# предложенный подход реализовать невозможно, а реализация Native API на VC++/CLI теоретически возможна, но при попытке подключения DLL, скомпилированных с опцией /CLR, происходит зависание 1С (версия 8.2.13.202). Простейший способ воспроизвести проблему зависания: включить опцию /CLR на проект-пример от 1С про таймер NativeAPI. Зазиповать DLL вместе с файлом MANIFEST.xml в макет кофигурации 1С 8.2 и выполнить следующий код на форме: &НаКлиенте Комментируя код, относящийся к клиенту или серверу, можно понять, что проблема характерна как для клиента, так и для сервера. Проблема серьезная для многих, так как она блокирует использование Native API ВК, написанных с применением .Net, на 1С.

Так если я не ошибаюсь, Native API кк раз и сделали для того, чтобы не тащить паровоз из .NET и COM'а. Не?

Native API сделали для возможности писать ВК на Linux

В 1С отписал?

:) А 1С прислушается?

Интересный вопрос: почему новая технология Native API уступает старой технологии COM отсутствием доступа к методам глобального контекста (AppDispatch)? Ведь все новое должно быть лучше старого...

Я думаю, потому что AppDispatch там не нужен. Вот тебе зачем он нужен?

AppDispatch - это доступ к более сотни функций 1С. Я, например, в 8.1 перевожу произвольный макет в byte[] используя вызов Base64String и обратный System.Convert.FromBase64String.

"а реализация Native API на VC++/CLI теоретически возможна" .NET наконец то стал компилить DLL которые понимают программы написанные не на .NET? Или этот геморрой ещё не вырезали?

Интересно, а в веб-клиенте ты чей AppDispatch ожидаешь получить?

ну это, мягко говоря, не правда Native API сделали для того чтобы компоненты можно было писать такие компоненты, которые могут работать везде где работает код 1С, на обычном клиенте, на сервере, web-браузере. Соответственно и в среде разных ОС Windows и Linux, т.к. сервера и браузеры могут работать на Linux. В Linux нет COM, соответственно Native компоненты COM не используют. Соответственно нет COM - нет и AppDispatch. Все просто у них. :)

Вы удивитесь, но C++ стал поддерживать формат .Net с 2003 года. Более того, видится усилия Microsoft от отказа от C++ в будущих Visual Studio.

В веб-клиенте я надеюсь увидить пространство имен JScript Web.GeneralContext. Меня это устроит - в нем представлены все методы глобального контекста.

Ды накой тут формат .NET, если нужно в .NET сделать dll обычную, не CLR

+11 1C:Предприятие в NativeAPI работает только с обычной dll

Это вранье. Native API не сможет работать на Internet Explorer (распространенный веб-клиент) - он ничего кроме ActiveX и COM не воспринимает. Насколько вы понимаете, Native API - это определения вида extern "C" long GetClassObject, которые с COM ничего общего не имеют. Если вы посмотрите в реализацию ВК на Internet Explorer, вы увидете "new ActiveXObject(...)", все обращения через IDispatch. В Linux нет COM, однако Native API изобилует определениями из COM  - достаточно посмотреть файл types.h - ничего лучше COM-определений 1С не придумала даже для linux: struct _tVariant, #define TV_I8, #define TV_INT_PTR, enum ENUMVAR Гипотетических пользователей Linux не так уж и много.

Native API не могут работать с Internet Explorer по определению, он признает только COM. см.

Я про Internet Explorer ничо и не спрашивал. Я говорю, что проблема в том, что .NET не делает обычных DLL, которые требует NativeAPI. В этом и проблема.

А может Вам заняться написанием NetBridge для навижн? Все условия: 1. работает только на винде 2. родная поддержка .нет 3. родной СОМ 3. никаких "гипотетических пользователей линукс"

:) У NetBridge далеко идущие планы - для англоговорящих 1С-разработчиков через сайт www.1centerprise.com. Это основа понятия 1C.Net:Предприятие. Рано или поздно с помощью компании 1С или без помощи компании 1С иностранцы оценят 1C:Enterprise со всеми ее недостатками. DotNet - для иностранцев важен. Ну а пока в России, а самое интересное и на Украине, ценят NetBridge, мы постараемся для своих пользователей сделать максимум, поставив на уши разработчиков 1С через тех.поддержку. Найдя обходные пути, но сборки .Net наших пользователей будут работать, начиная с версии 7.7 и кончая 8.2.

Фанатик.

Почему я выразился "гипотетические пользователи Linux". 1С - традиционно Windows-приложение. Если клиент, то традиционно Windows, если СУБД, то традиционно MSSQL. Сколько у вас на памяти чистых Linux-клиентов? У меня ни одного. Даже на западе (в Италии), где преобладает Linux, мы собирали статистику. В средней компании 2 сервера: Windows и Linux, а клиенты все Windows. На кого нацелены все Linux-фичи 1C?

struct _tVariant почемы ты решил что определение этой структуры имеет какое-то отношение к COM? Потому что она имеет похожее название и назначение со структурой VARIANT применяющейся в COM? И то что объект Native ВК определяется с помощью нескольких интерфейсов тоже к СОМ отношения не имеет. Это всего лишь технология COM ТОЖЕ использует интерфейсы. В COM все интерфейсы должны быть унаследованы от IUnknown, в Native ВК интерфейсов это не так. Да там применяются интерфейсы как элементы языка С++, но COM тут непричем.

Да и вообще, вам нужен .NET это как бы определяет платформу только как Windows, а Native задумано как кросплатформенное решение. Зачем вам Native? Вам COM компонент вроде как достаточно, разьве нет?

Насамом деле, то что в Linux нет COM (или аналогичного общего универсального механизма) это не фишка его - это его беда. Например одно из ярких проявлений этой беды: если сервер 1С на linux, то регламентными заданиями, которые работают на сервере, нельзя организовать обмен данными между базами традиционными средствами: ComConnetor-а нету.. И нет никакого аналогичного средства доступа к данным базы.

Да потому что в клиенте 8.2 осталась поддержка COM-интерфейсов ВК, совместимых с 7.7. Вы думаете, что в 1С было реализовано 2 принципиально разных механизма работы с ВК? Я сомневаюсь. В подтверждение моих слов Internet Explorer, который не вписывается в технологию Native API - это так называемый "финт ушами" через COM. Нигде не сказано в документации о интерфейсе IAddInServiceEx для MSIE.

IAddInServiceEx это что?

>>Вы думаете, что в 1С было реализовано 2 принципиально разных механизма работы с ВК? Я сомневаюсь. Тут нечего сомневаться это написано в документации.

IAddInServiceEx - это бомба Native API, которая не описана в документации - это интерфейс работы ВК на IE, описанный в примере AddInIE->AddInIE.idl как

Самое интересное - этот интерфейс действующий, достаточно загнать IE-dll в CAB, подписать и вызвать ВК через ПодключитьВнешнююКомпоненту("","",..) из IE.

На счет IE и механизма загрузки компоненты в веб-клиентах вцелом - незнаю не смотрел не щупал.. Но механизм мне видится мне таким: сами браузеры никогда в жизни не будут цеплять простые dll полученные с web-сервера это не безопасно вообще-то, но там можно применить проверку каких-либо удостоверений. Для загрузки компонент например в IE может использоваться некий AtiveX получаемый с web-сервера под isapi расширением от 1С, как бы загрузчик Native компонент, он будет удостовереный сертификатом (его авторы - 1C), поэтому встанет по тихому, без вопросов. А вот грузить саму Native компоненту уже будет он, и предоставлять интерфейс объекта будет он. IAddInServiceEx - кстати не его ли интерфейс? по имени весьма подходит.

Ну вот чо, именно так у них и сделано. А он и не дожен быть описан к документации. Это часть реализации веб-клиента. Причем возможно что именно такая реализация для IE. Для хрома или оперы под которые работают под linux будет другая. Для эпполовского safary, например, может быть когда нить напишут третью.

Грамотно изложил. Теперь ждем прояснения в голове нашего юного гения...

В 8.2 COM компоненты кстати тоже нельзя загрузить на сервере как и в 8.1. Странные они.. COM компоненты нельзя, но зато запросто можно просто COM объекты, удивительно!

Это, блин, native API теперь каждый к своей родной тумбочке притянуть хочет :) ..кто-то к .NET, а кто-то к Delphi, да ведь Кирпич ;)

Ага. Только оно как то пока нафиг ненужно.

..в этом нет ничего плохого, конечно..

угу, вот снизойдет на 1С божья благодать, сделают они как-нибудь доступ к родным объектам 1С из компоненты - вот тогда попрет у всех. :)

:))) Ну тогда народ вабще не станет изучать родной язык 1С, все будут на сях обработки строчить. А для Elisy сделают отдельный брыдш на .NET, в качестве акта доброй воли.

Да он сам себе сделает, я честно говоря не верю что dll с /clr просто так вот не грузится.. надо искать причину.

А ты попробуй. только права учетке сервера задери по максимуму, дабы зарегить СОМ смог.

О спец-библиотеке для IE от 1С речи пока не идет. Хотя, полностью согласен, так было бы грамотнее всего сделать и такое решение гармонично бы вписалось в подход Native API. Не нужно было бы напрягать разработчиков частными подходами. Сейчас для IE с сервера получают .cab-файл, который устанавливается средствами Windows с регистрацией всех библиотек, если нужно. Далее идет создание объекта с именем в файле MANIFEST.xml через Web.AddIn.Adaptor=new ActiveXObject(<name>); и последовательный вызов у объекта методов интерфейса IAddInServiceEx через IDispatch.

Не у всех происходит зависание C++/CLR: Теперь я думаю, в чем проблема: Windows 7 виновата или установленный .Net framework 4.0.

блин... вот смотрю и думаю.... А как предполагается борьба с различными версиями .Нет у пользователя? ведь если ВК попадет к юзеру из макетов, то далеко не факт, что у него уже точно стоит .Нет4. Ответ есть на этот вопрос?

+а на W2k8Core и вообще .Нет по умолчанию не ставится...

NET'у - нет!!! Православный С/C++ наш выбор. Будет работать везде и всегда.

1С просто не сможет загрузить ВК - в коде на этом этапе можно сделать проверку.

У меня такое же было отношение к .Net, пока один проект не заставили итальянцы сделать на смешанном коде. При переписывании С++ (MFC) средствами .Net мы получили на 50% экономии кода. На столько же меньше ошибок и время на отладку. Получили сотни дополнительных .Net-контролов для интерфейса пользователя, а не 10-20, которые можно добавить на форму через RC-файл. Плюс меньше проблем с итальяно/английском локализацией.

>>Для эпполовского safary, например, может быть когда нить напишут третью. Цитата: Технологическая платформа 1С:Предприятия 8.2. Версия 8.2.13.202 Поддержка работы веб-клиента в браузерах "Safari" и "Google Chrome" включена в данную версию для целей бета-тестирования. Так что, уже.. но это, возможно, это для того сафари который на Windows работает, а не на МакОС, хотя надо проверять. будут расставлять .Нет4 через групповые политики, какие проблемы-то? Суть в том, что .Net это только Windows.

Раз уж сюда зашел продублирую Странно, что натив код может обнаружить сейв код как нативный. Видно я давно Рихтера не читал, но даже загрузка сейв кода происходит через СОМ ком обертку. Во первых непонятно зачем использовать NativeAPI там где можно работать через ком напрямую? ПодключитьВнешнююКомпоненту(<Местоположение>, <Имя>, <Тип>) NativeAPI это прежде всего для Линукса.

Если кому-нибудь интересно, написал свою версию вариантов подключения внешних компонентов в 1С 8.2 на примере .Net Bridge с учетом обходных путей. Полезно будет для других C#-разработчиков ВК. Способы подключения внешнего компонента зависят от режима работы (сервер, толстый, тонкий или веб клиент). Самым простым способом подключения считается подключение в качестве Com-объекта. Такой вызов возможен во всех клиентах 1С 8.2 и версиях 1С, включая версии до 8.2. При работе с веб-клиентом может потребоваться включение настройки "Разрешить сценарии".   1. net = Новый COMОбъект("Elisy.NetBridge"); Инициализация компонента Elisy.NetBridge.dll из 1С (например, в тонком клиенте) происходит следующим образом с использованием COM ProgID: Для некоторых случаев (например, в веб-браузере) этот вызов может происходить из макета с ZIP-содержимым таким образом: или нерекомендуемый вызов по пути к файлу, оставшийся для обратной совместимостьи с предыдущими версиями 1С:Предприятие: Примечание: На некоторых компьютерах под управлением Windows 7/Vista с включенным UAC при подключении Elisy .Net Bridge наблюдаются странные проблемы. Например, вызов Новый COMОбъект("Elisy.NetBridge") выдает ошибку «Класс не зарегистрирован» или вызов ПодключитьВнешнююКомпоненту("Elisy.NetBridge") возвращает ложь, хотя в реестре можно увидеть соответствующую запись. Решаются проблемы удалением инсталляции Elisy .Net Bridge и установкой этой же инсталляции с правами администратора или запуском тонкого клиента 1С или веб-браузера с правами администратора. Допустим вариант подключения .Net Bridge через описание на Html-странице с обращением к свойствам и методам средствами JScript. Такой вариант подходит для тонкого и толстого клиента.

Ну нативу понемногу приходит конец. Новые операционки напрополую используют Save платформы, а Windows Phone не дает SDK для натива. Так смотришь и 1С перейдет на ЯВУ или .Net. Не зря майкрософт линукс подкупает себе. Вот простенький врайнер Net объектов в COM Кстати вот врайпер Net объектов в COM

блажен, кто верует..

Увы такова тенденция, для нас атеистов "вера" чуждое явление.

+ Единствено, что нужно добавить обертку вокруг OUT и ref параметров

Только что пришло сообщение от 1С: Цитирую: "Просто включить опцию компилятора /clr недостаточно. Т.к. платформа взаимодействует с неуправляемым кодом, то дополнительно нужно применять директивы #pragma managed(push, off) #pragma managed(pop) #pragma unmanaged Это объясняется несовпадением C/C++ ABI с ABI управляемого кода. Так,в файле AddInNative.cpp из примера, перед функцией long GetClassObject(const WCHAR_T* wsName, IComponentBase** pInterface) нужно добавить директиву #pragma unmanaged " Постараюсь побыстрее проверить

Работает. Принцип такой, что хотя весь проект и компилируется с опцией CLR, но на модуль AddInNative эта настройка не распространяется. Как развивать еще не думал, но этого достаточно, чтобы цивилизованно выдавать сообщение при попытке подключения по Native API: "Native API не поддерживается!" :)

Можешь сильно не распинаться, умные люди про это здесь уже давно написали.

Зачем писать NativeApi если можно использоват СОМ ВК? Или я что то не догоняю? Так или иначе шлюз между нативом и сейвом это Com

Мельком взглянул - синтаксис старый, значит и статья скорее всего устарела.

Подключение с использованием COM ВК доступно только на тонком клиенте, сервер признает только Native API. COM ВК сейчас запускать нельзя.

Это кто тебе сказал?

Ты очень крут. Мельком по синтаксису и сразу всё понял. А я дурак на дату публикации смотрю. Очень, очень крут.

На сервере нельзя ПодключитьВнешнююКомпоненту(<ИдентификаторОбъекта>) а ПодключитьВнешнююКомпоненту(<Местоположение>, <Имя>, <Тип>) Параметры: Тип: Строка. Местоположение внешней компоненты. В качестве местоположения может использоваться: путь к файлу внешней компоненты в файловой системе (недоступно на веб-клиенте) (не ZIP-архив); полное имя макета, хранящего двоичные данные или ZIP-архив; URL к внешней комопненте, в виде двоичных данных или ZIP-архива, в формате, аналогичном ПолучитьНавигационнуюСсылку. <Имя> (обязательный) Тип: Строка. Символическое имя подключаемой внешней компоненты. Имя должно удовлетворять правилам именования встроенного языка. <Тип> (необязательный) Тип: ТипВнешнейКомпоненты. Тип подключаемой внешней компоненты. Не используется, если компонента упакована в ZIP-архив. Описание варианта метода: Подключает компоненты, выполненые по технологии Native API и COM. Компонента может храниться в информационной базе или макете конфигурации в виде двоичных данных или в ZIP-архиве. Для тонкого клиента и веб-клиента, компонента должна быть предварительно установлена методом УстановитьВнешнююКомпоненту.

Радченко сказал "Вообще, в синтакс-помощнике описаны два варианта синтаксиса ПодключитьВнешнююКомпоненту: 1. ПодключитьВнешнююКомпоненту(<Местоположение>, <Имя>, <Тип>) 2. ПодключитьВнешнююКомпоненту(<ИдентификаторОбъекта>) К сожалению дальше есть особенность, которая там не описана, но мы это исправим. Первый вариант синтаксиса можно использовать и на клиенте, и на сервере и во внешнем соединении. Второй вариант синтаксиса можно использовать только на клиенте."

Спасибо Вместо __gc class сейчас используется ref class вместо __gc __interface - interface class В документации сказано про __gc: "This topic applies only to version 1 of Managed Extensions for C++. This syntax should only be used to maintain version 1 code. See Classes and Structs (Managed) for information on using the equivalent functionality in the new syntax." а опция компилятора называется /clr:oldSyntax

Спасибо. Просветил. Теперь можно MSDN сносить за ненадобностью.

Значить Первый Вариант с ТипВнешнейКомпоненты.Com должен проходить?

В МСДН и сказано об устаревшем синтаксисе

Тоже обрадовался сперва. ТипВнешнейКомпоненты.Com на сервере игнорируется и берется ТипВнешнейКомпоненты.Native

Как??!! От, блин, а я уже снёс.

А шуму то, шуму то было, чуть не мировой заговор 1С против .NET'а.

А проблема осталась - с тем же успехом 1С могло ответить - для нормальной работы примера, нужно убрать опцию /clr. Дело в том, что после предложенного решения 1С любое создание .Net-объекта сопровождается таким же зависанием. Например, вызов простого метода: #pragma managed из методов CAddInNative::CallAsFunc или CAddInNative::Init Проблема похожа на Loader Lock:

То есть ты уже в своей компоненте из unmanaged кода вызываешь managed код, а в зависании виновата 1С?

Пиши опять в 1С. Раз ответили, пускай дальше отвечают. А ещё лучше подожди годик-другой. Кому нибудь приспичит сделать ВК на NativeAPI, он сделает и выложит. Или книжку купи какую нибудь чтоли, раз такой пытливый.

А иначе использовать опцию /CLR смысла нет. CLR подразумевает использование смешанного кода управляемого и неуправляемого. Сейчас я вижу, что 1С создает известную проблему "Loader Lock".

И при чем здесь loader lock? Он может возникнуть только при отработке DllMain, а твой код уже далеко вне этого.

Не тупи, это не 1С создает проблему loader lock, а в реализации загрузки смешанных сборок у MS есть косяк, могущий приводить к loader lock. Ну и я уже писал, что этой проблемой здесь не пахнет, твой код вызывается уже после DllMain.

В 1С написал. Печально, но пока это самое трезвое решение - ждать. Или начать искать обходные пути.

Не знаю, кто виноват, я хочу получить работающее решение. То что в 1С тоже не все гладко могу утверждать по 2м моментам: 1. Если в const WCHAR_T* GetClassNames возвратить в 1С ""(ничего), в первый вызов зависания не происходит. Зависание происходит на 2м вызове. 2. Если в bool CAddInNative::CallAsFunc написать всего 1 строку return false; , происходит вылет 1С.

Под отладчиком при зависании удалось поймать стек вызовов: ntdll.dll!_LdrLockLoaderLock@12  + 0x6b bytes     Похоже, действительно Loader Lock

спасибо. Надеюсь исправить в следующих весрсиях. А какая стоит у тебя?  С другой стороны использование ВК на сервере не совсем понятно. Для 7 ки это было нужно из-за передачи объектов 1С, и отсутствия доступа 1С как внутреннего сервера автоматизации. Интерфейс обратного вызова больше для клиента. В 8 ке же есть Коннектор и можно использовать IDispatch в полном объеме (правда пока не проверял). А в твоих задачах в чем перущество ВК перед IDispatch на сервере? Желаю успехов подружить натив с сейвом в одной DLL. Может применить 2 Нативную и нетовскую?

Спасибо. Через Сервер я думал сделать механизм доступности каких-то только серверных объектов для клиента. Сейчас клиент вообще ущербный получился. Например, на клиенте нельзя вызвать просто так команду вида: элемент = Справочники.Организации.НайтиПоКоду("111"); Да и вообще нельзя вызвать большую часть доступных в 8.1 методов - только через серверные процедуры. Есть мечта сделать что-то вида:

Версию специально нашел последнюю (8.2.13.202)

Вот только из чисто спортивного интереса уже буду следить за веткой! :) Складывается впечатление, что "чукча не читатель, чукча писатель" (С) Не мое :). Хоть доку по Технологии ВК читал? Про ограничения NativeAPI в курсе? Из компоненты объект в строке передавать будешь? :))) Как будет готова хотя бы пре-альфа компоненты, выложи плз куда-нибудь. Хочется в живую посмотреть на это чудо инженерной мысли. :)))

Все это можно( и даже намного проще) решить через IDispatch как например в Delphi аналог DCOMa через TCP. Но лучше конечно не делать из тонкого клиента толстого и большую часть вычислений делать на сервере. Удачи.

Обязательно выложу ))))). 1С тоже на месте не стоит. Может и ограничения снимет. Пока к мечте буду идти, может еще найду несколько достойных применений. Elisy LinqTo1C тоже сначала мечтой был, а сейчас уже небольшой доход приносить начал:

Спрячь и некому не показывай! Любой твой клиент, которому ты продал ЭТО, автоматически нарушает ЛС от 1С: ОПИСАНИЕ ПРАВ И ОГРАНИЧЕНИЙ, п.4, $3. Со всеми вытекающими. И в ответе можешь быть ты, т.к. ты продавец.

У нас разные взгляды на этот счет

Кстати во мнгих случаях проще использовать ВэбСервисы XDTO например

Наши взгляды никого, кроме участников этого форума, не интересуют. Главное, чтобы совпали взгляды юристов 1С и Ваших клиентов, при использовании ЭТОГО добра. А если они не совпадут, то можно попасть на нехилую кучу бабок за то, что Вы не проинформировали покупателя, что Ваш продукт нарушает ЛС правообладателя. А если у него еще и пострадает бизнес... то, возможно, еще потребуется компенсировать упущенную выгоду. Как-то так.

Лицензия 1С никому не интересна в данном контексте, так как сам запрет прямого доступа в лицензии 1С противоречит Гражданскому Кодексу РФ.

Из 1С пришел ответ: "Технические вопросы совместного использования управляемого и неуправляемого кода правильней задавать компании-производителю. Специалисты компании 1С не имеют доступа к исходным кодам платформы .NET для детального анализа причин неработоспособности."

Решено было не включать в версию .Net Bridge 4.0 поддержку Native API. При обращении по Native API выдается сообщение об отсутствии поддержки. В 4ю версию добавили только поддержку тонкого клиента 8.2. Выложено на: Анонс: