Новая версия 1С:Предприятие 8.2 конфликтует с C# и .Net framework
Суть конфликта 1С 8.2 с C# и .Net framework в следующем. В версии 8.2 1С анонсировала новый способ написания внешних компонент 1С с использованием так называемого Native API. Самое интересное, что на C# предложенный подход реализовать невозможно, а реализация Native API на VC++/CLI теоретически возможна, но при попытке подключения DLL, скомпилированных с опцией /CLR, происходит зависание 1С (версия 8.2.13.202). Еще один конфликт – в новой версии 1С нет поддержки технологии ActiveX, на основе которой многие разработчики вставляли в формы 1С свои WinForms-приложения.
15.12.2010 13:37 21 [+] [−] Перейти к публикации
| Цитата |
|---|
| Заметка эта написана больше не для критики, а чтобы определить новую для определенного круга .Net-разработчиков проблему, попытаться донести ее до 1С и постараться совместно решить в текущей или новых версиях популярного продукта 1С:Предприятие 8.2. |
Совместно решить ? с 1С ? - Ох, вряд ли.
Думаю , выкручиваться будет каждый разработчик ВК как сможет.
Разработчик ВК для 1с работает на свой страх и риск.
На свой страх и риск и действуют покупатели , покупающие такие ВК.
Такова жизнь.
того глядишь на java перейдем...шучу, но для многих, конечно неприятность, есть у кого-нибудь соображения на сей счет?
| Цитата |
|---|
| Совместно решить ? с 1С ? - Ох, вряд ли.
Думаю , выкручиваться будет каждый разработчик ВК как сможет. Разработчик ВК для 1с работает на свой страх и риск. На свой страх и риск и действуют покупатели , покупающие такие ВК. Такова жизнь. |
Я думаю, достаточно постараться решить силами заинтересованных разработчиков. Проблема общая.
Как я понял в случае с C++/CLR происходит, скорее всего, Loader Lock. Как бороться пока не знаю. При отладке и остановке в отладчике выдается такой стек вызовов:
ntdll.dll!_RtlCompareMemoryUlong@12() + 0x10 bytes
ntdll.dll!@RtlpFreeHeap@16() + 0x10b bytes
ntdll.dll!_RtlFreeHeap@12() + 0xe37 bytes
ntdll.dll!_RtlDebugFreeHeap@12() + 0x1f9 bytes
ntdll.dll!@RtlpFreeHeap@16() + 0x34d58 bytes
ntdll.dll!_RtlFreeHeap@12() + 0xe37 bytes
kernel32.dll!_HeapFree@12() + 0x14 bytes
> clr.dll!EEHeapFree() + 0x22 bytes
clr.dll!EEHeapFreeInProcessHeap() + 0x1e bytes
clr.dll!operator delete[]() + 0x30 bytes
clr.dll!ExecuteDLLForAttach() + 0x114 bytes
clr.dll!ExecuteDLL() + 0xc9 bytes
clr.dll!CorDllMainForThunk() + 0x6b bytes
mscoreei.dll!CorDllMainWorkerForThunk() + 0x74 bytes
mscoreei.dll!_VTableBootstrapThunkInitHelper@4() + 0x1d bytes
mscoreei.dll!_VTableBootstrapThunkInitHelperStub@0() + 0xc bytes
или
> clr.dll!SString::CaseCompareHelper() + 0x2a bytes
clr.dll!SString::EqualsCaseInsensitive() + 0x34fa5 bytes
clr.dll!PEImage::PathEquals() + 0x16 bytes
clr.dll!DomainAssembly::FindIJWModule() - 0x10 bytes
clr.dll!AppDomain::FindIJWDomainFile() + 0x4e bytes
clr.dll!ExecuteDLLForAttach() + 0xc5 bytes
clr.dll!ExecuteDLL() + 0xc9 bytes
clr.dll!CorDllMainForThunk() + 0x6b bytes
mscoreei.dll!CorDllMainWorkerForThunk() + 0x74 bytes
mscoreei.dll!_VTableBootstrapThunkInitHelper@4() + 0x1d bytes
mscoreei.dll!_VTableBootstrapThunkInitHelperStub@0() + 0xc bytes
Может кому-то будет полезно
| Цитата |
|---|
| mirco пишет:
думаю activeX или аналога точно не будет. а вот nativeApi поправят, но конечно не скоро... надо бы попробовать порисовать окна внутри 1с, может получиться придумать идею для замены activeX. Пока что я знаю только как всавить через поле html. |
Обходные пути можно поискать, но хотелось бы по возможности к NativeAPI подстроиться
(10) Может это разработчики 1С не стремятся, ...не знаю что там тебе приснилось, ты публикации автора видел? Elisy .Net Bridge например?
Ответили: (16)
| Цитата |
|---|
| v77 пишет:
Автору приснилось, что 1С должна работать с .NET, с которым никогда не собиралась работать. |
Автор не понял 1С. Внешние компоненты нацелены в первую очередь на разработчиков. Сообщество .Net-разработчиков намного больше, чем сообщество 1С-разработчиков. И .Net-разработчиков больше, чем С++ - разработчиков.
Я не прошу полноценной поддержки .Net в 1С, но ПодключитьВнешнююКомпоненту(ProgId) в сервере 8.2 можно же было оставить, как оставили его в клиенте 8.2. Проблем бы стало намного меньше.
(12) "Пока не отчаялся. А вот эти люди уже отчаялось и ничего хорошего от 1С не ждут:"
Не то чтобы я был на стороне тех кто отчаялся,НО:
Занимая монопольное положение на своем рынке , почему "1с" должна заботиться о .net-разработчиках ?
С какой стати ?
Что -то мне подсказывает , что при разработке нового релиза "1с" меньше всего думает о .net-разработчиках,
много их или мало.
Сколько решений на 1с , использующих .net ? - Оптимистичный ответ 0.5% !
Видя соотношение 99.5% против 0.5%, человек принимающий решение , вздохнет :
".net-разработчиков , конечно , жаль"
(11) Я не фанат .NET и мне эти бриджи и обиды на 1С по барабану.
NativeAPI сделан для С++ и с учетом того, что будет использоваться на Linux.
А ваши свистелки с пирделками 1С не обязана поддерживать. Колупайтесь сами. Кстати, могу за деньги прикрутить ваш .NET к NativeAPI.
Ответили: (19)
| Цитата |
|---|
| v77 пишет:
Кстати, могу за деньги прикрутить ваш .NET к NativeAPI. |
Хорошая идея. Готов оплатить "прикручивание" в пределах разумного для последующей общедоступной публикации. Решение должно быть на C# или VC++/CLR, подключаться по технологии Native API (не COM) из 1С 8.2 (Сервер) (без workaround`ов) с реализацией интерфейсов IComponentBase, IInitDoneBase, ILanguageExtenderBase, LocaleBase. Для простоты можно на основе примера с таймером от 1С NativeAPI. Без зависаний при вызове ПодключитьВнешнююКомпоненту из макета.
Сколько это будет стоить и в какой срок?
(16) По моему занятие фанатства надо оставить болельщикам футбола и иже с ними, а в делах сугубо рабочих, в зависимости от задачи, от того кому что удобней, ... ну и от привычки...насчет прикручивания неплохо бы, но меня это интересует пока лишь с точки зрения любопытства, поскольку задачи на 8.2 такой не стоит. Насчет того, что 1С определяет политику своих разработок сама
| Цитата |
|---|
| А ваши свистелки с пирделками 1С не обязана поддерживать |
Ответили: (20)
| Цитата |
|---|
| v77 пишет:
А что такое workaround? |
Workaround - обходной путь.
Например, обходным путем считается на сервере 8.2 обойти зависания Native API через написание отдельной DLL (без CLR), которая реализуя Native API будет возвращать ссылку void* pConnection из метода bool CAddInNative::Init. Далее ее можно передать уже в COM-объект на C# или VC++/CLR и получить полноценный ВК. По сути ВК - это самописный компонент плюс ссылка на pConnection.
Для такого варианта будет код:
&НаСервере
...
ПодключитьВнешнююКомпоненту("ОбщийМакет.NativeAPI", "NativeAPI", ТипВнешнейКомпоненты.Native);
AddIn = Новый("AddIn.NativeAPI");
intPtr = AddIn.GetConnectionIntPtr();
o = Новый COMОбъект("CSharp.COM");
o.SetConnection(intPtr);
В результате получим C#-объект на стороне сервера со ссылкой на Connection. Результат достигнут, но нужно, чтобы в одной dll (VC++/CLR) была реализация NativeAPI + .Net.
(21) наверное нет, хотя как на это посмотреть - все таки реализация не напрямую (23) по моему это совсем не простая задача...
Есть еще 3-й вариант пару-тройку сот рублей в пивбар, и не парится...конец недели все таки...
ЗЫ про пару тройку, миллионов, - можно просто придти в микрософт и они переделают под заказ? ...следующая версия платформы dot net Abramovich
или 1Ё от Прохорова - который работает на альтернативном источнике мыслей
Ответили: (29)
(30) неужели это то о чем я думаю ... addinnative...хм...
ЗЫ как быстро исполняются...хочу ВК самогенерирующую код... 
ЗЫ Дай пожалуйста описание, а то кот в мешке...или это просто демонстрация ВК на 8.2, говорящая "нет"...
скачай файлик заново
| Код |
|---|
Процедура TestNativeApi()
УстановитьВнешнююКомпоненту("ОбщийМакет.addinnative");
Сообщить(ПодключитьВнешнююКомпоненту("ОбщийМакет.addinnative", "Timer", ТипВнешнейКомпоненты.Native));
КонецПроцедуры
Процедура ПриНачалеРаботыСистемы()
TestNativeApi();
КонецПроцедуры |
(35) Это радостное известие означает, что не все еще потеряно. Давайте теперь с ОС разберемся. Предполагаю, что у вас могло заработать на XP или 2003. Вот дословно параметры моего запроса в 1С:
1. ДАННЫЕ ТЕКУЩЕГО КОМПЬЮТЕРА И КОНФИГУРАЦИИ
Версия 1С:Предприятия 8.0: 8.2.13.202
Конфигурация: Тестовая
Версия конфигурации: -
Операционная система: Microsoft Windows 7
Могу добавить, включен UAC. Установлен .Net framework 4.
Только что пришло сообщение от 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
в файле AddInNative.h, после #define __ADDINNATIVE_H__ нужно добавить #pragma managed(push, off), а перед #endif //__ADDINNATIVE_H__ #pragma managed(pop)
"
Постараюсь побыстрее проверить
(39) Работает. Принцип такой, что хотя весь проект и компилируется с опцией CLR, но на модуль AddInNative эта настройка не распространяется. Как развивать еще не думал, но этого достаточно, чтобы цивилизованно выдавать сообщение при попытке подключения по Native API: "Native API не поддерживается!" 
Толстый клиент обычное приложение
(47) Да, как это они работают на сервере 8.2? Можно ссылку на пример такого компонента? Насколько я знаю,
Вот что пишет Радченко:
"Вообще, в синтакс-помощнике описаны два варианта синтаксиса ПодключитьВнешнююКомпоненту():
1. ПодключитьВнешнююКомпоненту(<Местоположение>, <Имя>, <Тип>)
2. ПодключитьВнешнююКомпоненту(<ИдентификаторОбъекта>)
К сожалению дальше есть особенность, которая там не описана, но мы это исправим.
Первый вариант синтаксиса можно использовать и на клиенте, и на сервере и во внешнем соединении.
Второй вариант синтаксиса можно использовать только на клиенте."
Это значит, что на сервере работают только ВК, написанные по технологии NativeAPI. Подскажите мне, пожалуйста, как на C# повторить технологию NativeAPI, подобно примеру 1С на C++.
| Цитата |
|---|
| Мне тоже известны пути вставки ActiveX на управляемые формы 8.2. Но согласитесь, технологию такой вставки нужно рассматривать как обходной путь (workaround). Так как работу выполняет не 1С, а IE. |
Зачем пихать все ActiveX-ы на форму?
В 90% случаев достаточно использовать конструктор "Новый COMОбъект()". И все прекрасно работает и на сервере, и на клиенте, и на веб-клиенте.
(55) Новая версия - "8.2.13.202"
(56) Я заметил и разработчики 1С подтвердили: см. (39) . К сожалению - это не помогает, так как управляемый код из такой dll вызывать нельзя.
А проблема осталась - с тем же успехом 1С могло ответить - для нормальной работы примера, нужно убрать опцию /clr. Дело в том, что после предложенного решения 1С любое создание .Net-объекта сопровождается таким же зависанием. Например, вызов простого метода:
#pragma managed
void CAddInNative::InitializeManaged()
{
System::Object^ o = gcnew System::Object();
}
#pragma unmanaged
из методов CAddInNative::CallAsFunc или CAddInNative::Init
Проблема похожа на Loader Lock:
(57) Повторюсь - я веду речь о тонком клиенте и сервере 8.2.
1. Новый COMОбъект() создает COM-объект, а не ActiveX. ActiveX подразумевает визуаьлный компонент. Значит использование Новый COMОбъект() ограничено.
2. Если сравнивать использование NativeAPI и Новый COMОбъект() на сервере, то NativeAPI выиграет только за счет того, что подключение его кэшируется и он каждый раз не создается.
3. Внешние компоненты (NativeAPI и сделанные по старой технологии) имеют преимущество в том, что в них передается указатель на АПИ 1С. Это значит, например, что из ВК можно выдать сообщение в окно 1С, а из Новый COMОбъект() затруднительно. Из ВК можно вызвать метод глобального контекста (только для тонкого клиента), а из Новый COMОбъект() - тоже затруднительно.
| Цитата |
|---|
| Elisy пишет:
Повторюсь - я веду речь о тонком клиенте и сервере 8.2. 1. Новый COMОбъект() создает COM-объект, а не ActiveX. ActiveX подразумевает визуаьлный компонент. Значит использование Новый COMОбъект() ограничено. 2. Если сравнивать использование NativeAPI и Новый COMОбъект() на сервере, то NativeAPI выиграет только за счет того, что подключение его кэшируется и он каждый раз не создается. 3. Внешние компоненты (NativeAPI и сделанные по старой технологии) имеют преимущество в том, что в них передается указатель на АПИ 1С. Это значит, например, что из ВК можно выдать сообщение в окно 1С, а из Новый COMОбъект() затруднительно. Из ВК можно вызвать метод глобального контекста (только для тонкого клиента), а из Новый COMОбъект() - тоже затруднительно. |
1. ActiveX - не ком-объект? Ничем не ограничено. Работает, как на сервере, так и на клиенте. И не один год уже. И на всех платформах.
2. Каждый раз можно не создавать. У меня в статье описано хранение 1 объекта без создания каждый раз нового элемента.
3. У комобъекта прекрасно используются события, с помощью которых можно что угодно выводить и показывать в 1С.
(60) Если это из той же оперы, что и (30), то почитай ответ от 1С, которая фактически признала проблемы взаимодействия управляемого и неуправляемого кода в (39). Я повторюсь, что это решение зависает на 1С 8.2 см (35). А если это решение у одних зависает, а у других - нет, то это нестабильное решение, которое в нормальный продукт не вставишь.
| Цитата |
|---|
| Elisy пишет:
почитай ответ от 1С, которая фактически признала проблемы взаимодействия управляемого и неуправляемого кода в . |
Ничего они не признали. Они намекнули тебе, что проблема лежит за пределами кода 1с, и намекнули где искать решение.
А потом намекнули еще раз более прозрачно (чтобы даже тебе было понятно):
| Цитата |
|---|
| Из 1С пришел ответ:
"Технические вопросы совместного использования управляемого и неуправляемого кода правильней задавать компании-производителю. Специалисты компании 1С не имеют доступа к исходным кодам платформы .NET для детального анализа причин неработоспособности." |
| Цитата |
|---|
| Я повторюсь, что это решение зависает на 1С 8.2 см . А если это решение у одних зависает, а у других - нет, то это нестабильное решение, которое в нормальный продукт не вставишь. |
Та хамишь, и при этом еще хочешь чтобы я тебе дал "стабильное решение". А мне лень тратить свое время на решение твоих проблем.
Я хочу, чтобы до тебя дошла простая мысль: "описанное зависание - не проблема 1с и не проблема microsoft, а проблема твоего кода. И в твоих силах это исправить, если вникнуть в тему поглубже, а не орать на весь интернет что 1с с чем-то там конфликтует"
Ответили: (67)
| Цитата |
|---|
| Elisy пишет:
А то, получается, 20 человек поддерживают, а у 2х человек аргументов не хватает, начинают на личности переходить. |
20 плюсиков означают примерно следующее: кому-то из плюсанувших интересна тема "1с + .NET", кому-то интересна тема NativeAPI, кто-то считает что "1с--сакс". Я уверен, что никто из них не писал на C++/CLI.
А насчет аргументов... Я считаю, что достаточно (30) и (60)
| Цитата |
|---|
|
Та хамишь, и при этом еще хочешь чтобы я тебе дал "стабильное решение". А мне лень тратить свое время на решение твоих проблем. Я хочу, чтобы до тебя дошла простая мысль: "описанное зависание - не проблема 1с и не проблема microsoft, а проблема твоего кода. И в твоих силах это исправить, если вникнуть в тему поглубже, а не орать на весь интернет что 1с с чем-то там конфликтует" |
Где я написал, что хочу лично от тебя чего-либо. Я так понимаю, ты предложил решение, оно таким же образом зависает, как и мое. Спасибо, конечно, но этого я и сам достиг. В моих силах было найти в отладчике при зависании при инициализации CLR в методе Init:
ntdll.dll!_RtlEnterCriticalSection@4() + 0x17 bytes
ntdll.dll!_LdrLockLoaderLock@12() + 0x6b bytes
А это значит, что каким-то образом проблема относится к проблеме Loader Lock. Отрицательный результат - тоже результат. Виноват мой код, 1С или Microsoft, меня это уже мало интересует. Сейчас для меня становится очевидным, что нужно искать обходной путь.
Действительно, конструктивного диалога не получается, хотя steban и Душелов, в общем-то правы, описанной проблемы не наблюдал, а порывшись в интернете, набрел на автора этой публикации. На C++/CLI не писал, так, что (66) близок к истине, (хотя писал на шарпе). Так, что склоняюсь к мысли, что тестить надо больше, приводить проблемный код, а то говорить получается, то не о чем. Соглашусь с Гилевым (8).
(68)Блин, опять одно нытьё 
Vista sp2 32-бит, 1c 8.2.13.202, .NET Framework 4, UAC включен - 1с при загрузке компоненты не виснет и managed-код выполняется.
Win7 64-бит, 1c 8.2.13.202, .NET Framework 4, UAC включен - 1с при загрузке компоненты не виснет и managed-код выполняется.
Ответили: (72)
(71) Ты думаешь, я тебе не доверяю? Я верю тебе, что у тебя работает. Я верю cool.vlad4. Но твое решение постоянно(не временами) виснет у меня на машине также, как и мое. Ты можешь сейчас гарантировать стабильность такого решения всем разработчикам? Я нет. Допускаю, что влиять могут другие программы, вроде, антивируса на моей машине. Но как выявить, пока себе не представляю. По возможности при проверке все их отключил. При этом пример без опции CLR работает нормально - не зависает.
(73) Я прошу хочется же узнать в чем причина этого загадочного зависания, вдруг это заразно и у меня начнет виснуть
Ответили: (74)
Не привык пакостить исподтишка. Так что минус обосную:
1С решает определенный круг задач. И в описание этого круга задач поддержка .net не входит. Есть некий интерфейс позволяющий расширить круг задач, но это уже не к 1С, а к тем, кто расширяет. NativeAPI - достаточен для расширения, кроссплатформенный и хорошо документирован.
| Цитата |
|---|
| awk пишет:
1С решает определенный круг задач. И в описание этого круга задач поддержка .net не входит. |
Какой бы круг задач не решала 1С, ее функционал очень ограничен и во многих задачах требует расширения другими средствами. Чисто прагматически 1С только выиграет, если будет дружно работать с .Net/Java и др. популярными платформами.
| Цитата |
|---|
| awk пишет:
Есть некий интерфейс позволяющий расширить круг задач, но это уже не к 1С, а к тем, кто расширяет. NativeAPI - достаточен для расширения, кроссплатформенный и хорошо документирован. |
Наверное, мы с вами с разным NativeAPI работаем.
NativeAPI мне показался ущербным по сравнению с COM ВК, так как не поддерживает IDispatch (или схожего метода доступа) и доступ к глобальному контексту через AppDispatch. И можно ссылку на хорошую документацию по использованию в MS IE, где был бы описан загадочный интерфейс IAddInServiceEx? Похоже продуманность и кроссплатформенность NativeAPI закончилась с поддержкой IE, где доступ осуществляется все через тот же одноплатформенный COM.
Насчет документации (81) поддерживаю - было бы очень хорошо awk, если бы вы выложили ссылки...я бы плюс поставил...
ЗЫ А к кому обращатся по поводу мелких недочетов на сайте? К support-у? - 1. При ошибочной ссылке на самого себя (например (81) ), после изменения оной ошибки - внизу ссылка так и остается (82) к примеру. 2. При добавлении цитат в комментарий, не отображается поле ссылок на ответы к комментарию. Это все мелочи, но просто, если уж есть такие фичи, то пускай без багов.
Ответили: (83)
а вот никто не подумал, что поддержки .Net нет и быть не может, исходя из самой концепции управляемого приложения? Вот что априори знает сервер 1С о клиенте? Да неизвестно даже, на какой оси он крутится, в каком режиме работает! А любители .Net, покажите мне, как можно создать программу, которая, выполняясь на сервере, найдёт ваш .Net на клиенте (ага, на веб-клиенте, на линуксе, или, что уж там - давайте уж сразу на MeeGo).
Или вы хотите выполнять код на сервере и кидать на клиент результат? Тогда вам нужен VNC, а не 1С.
или вы хотите выполнять код на клиенте, с прямым доступом к ресурсам компьютера? Тогда вам с 1С вообще не по пути, используйте 1Сv77.
Ответили: (85)
(84) japopov,
| Цитата |
|---|
| а вот никто не подумал, что поддержки .Net нет и быть не может, исходя из самой концепции управляемого приложения? Вот что априори знает сервер 1С о клиенте? Да неизвестно даже, на какой оси он крутится, в каком режиме работает! А любители .Net, покажите мне, как можно создать программу, которая, выполняясь на сервере, найдёт ваш .Net на клиенте (ага, на веб-клиенте, на линуксе, или, что уж там - давайте уж сразу на MeeGo). |
Можно много рассуждать о теории и универсальности. Но сейчас на практике сервер и клиенты традиционно на Windows. И намного качественнее охватить эти 95% клиентов, чем делать непротестированные в должной мере сообществом решения на все случаи жизни и разные ОС.
| Цитата |
|---|
| Или вы хотите выполнять код на сервере и кидать на клиент результат? Тогда вам нужен VNC, а не 1С.
или вы хотите выполнять код на клиенте, с прямым доступом к ресурсам компьютера? Тогда вам с 1С вообще не по пути, используйте 1Сv77. |
Ничто не помешает обмениваться клиенту .Net с .Net-сервером через простые объекты или строковые сериализации. Также, как и сейчас обменивается клиент и сервер через вызов серверных функций и процедур. Достоинство 1С в том, что оно в первую очередь десктопное приложение с прямым и тем самым более быстрым доступок к ресурсам компьютера.
(85) Elisy, Невозможность использовать .Net и вообще OLE, ActiveX - это следствие выбранной реализации (управляемое приложение, а точнее, его самая универсальная реализация - тонкий клиент). Увы, искать обходные решения (это не так уж сложно, я же нахожу %) ).
И таки да, для Вас будет сюрпризом - 1С уже давно постепенно отказывается от поддержки именно Microsoft в сторону большей универсальности. Вы просто не успеваете за 1С...
Ответили: (87)
(86) japopov, все находят обходные решения. Статья говорит о том, что 1С некорректно работает с CLR С++ -приложениями и не более того. Все попытки связаться с разработчиками компании 1С закончились простыми отписками.
То, что делает 1С, может не идти с традиционным распространенным подходом и 1С будет вынуждена считаться с этим. Так, например, не убрала поддержку внешних компонент, написанных для 1С 8.1 или оставила работу с КОМ-объектами.
Ответили: (88)
(85) У нас вот сервер под Linux + PostgreSQL, например. Клиенты - да, под Windows.
(87) А смысл убирать то, что работает? Только вот, если таки будет в 8.2.16 полноценная платформа под Linux - там уж точно не будет ни COM-объектов, ни внешних компонент 7.7/8.0/8.1-style.
И думается мне, что немало организаций тогда выберет Linux для рабочих мест пользователей, как минимум из-за более высокой защищенности от вирусов и бесплатности.
А отписки - как раз очень хорошо свидетельствуют о том, что для 1С поддержка CLR - это не приоритетная задача. Не работает, ну и фиг с ним. Не нужно. По крайней мере, судя по вашим словам, так оно и есть с точки зрения 1С.
И нам с вами придется с этим считаться, либо уходить на другую платформу.
Я предпочту считаться. К тому же, кросс-плаформенность для приложений - это всегда плюс, как с точки зрения отлаженности софта (больше различных конфигураций для тестирования => большее количество выявленных багов), так и с точки зрения захвата рынка.
Hello всем. Есть проблема зависания, тема тут вроде об этом идёт. Пишу вменяемый почтовый клиент (ВК 1с 8.2) для IMAP+SMTP+SSL+TLS на c#. Долго решал проблему (при первой отправке письма через ВК она не возникает, зато при второй - сразу висит намертво), в итоге выяснилось, что сразу после второго вызова метода отправки вызывается IInitDone.Done(). Пока копаюсь дальше. Будет результат - отпишусь. Есть мысли, что проблема в том, что у clr остаются ссылки на объекты 1С... копаюсь в общем
(89) так и есть, проблема с методом GC.WaitForPendingFinalizers(). 1С запаздывает с освобождением памяти? Или что? В любом случае, очистку грехов вроде мусора пока оставляю на потом. Клиент ждёт ) найду решение, приемлемое для юзера и кодера - отпишусь тут. Кстати, чтобы ВК не висла при открытии, нужно записать нечто подобное (для c#)
public static object V8Object
{
get
{
return m_V8Object;
}
set
{
m_V8Object = value;
m_ErrorInfo = (IErrorLog) value;
m_AsyncEvent = (IAsyncEvent) value;
m_StatusLine = (IStatusLine) value;
m_IExtWndsSupport = (IExtWndsSupport)value;
}
}
всё это частные случаи. зависания связаны чаще всего с разницей в подходах к очищению мусора в 1С Технология внешних компонент (c++) и .net. вообще, я бы заколлекционировал случаи подвисания и поразбирался бы с ними. это дало бы ценнейший опыт. если висячая ВК?
Ответили: (93)
(92) a_mironov,
Дальше, чем включение опции CLR в пример от 1С Технологии ВК дело не пошло. Уже на этом этапе было зависание.
Причем эксперименты с #pragma unmanaged тоже результатов особых не дали, насколько помню.
Сейчас пока не охота возвращаться к этой теме из-за того, что новая технология ВК менее гибкая, чем COM ВК (нет возможности работать с объектами, а только с примитивными типами).
Ответили: (94)
Здравствуйте уважаемый Elisy. я вот нашел ваш .net bridge и пытался воспользоваться обработкой отсюда
вообщем ошибка происходит аж при загрузке внешней компоненты. у меня Windows 7 x64, платформа 1С 8.2.14.537, конфигурация "Управление торговлей" 10.3.14.5 (демка, но и не только на демке ошибка происходит), устанавливал .net bridge от имени администратора, путь к библиотеке в самой обработке менял, .net bridge версии 4.0.3.1 качал . эта ошибка происходит из-за описанной в данной теме проблемы? никак подключить эту компоненту на данной платформе не удастся? хотел просто испробовать многопоточность в 1С, но вот столкнулся с данной проблемой
Ответили: (98)
21 [+] [−] Перейти к публикации
Да-м жить становится интереснее...