Это практическое применение из предыдущей статьи .Net Core, 1C, динамическая компиляция, Scripting API.
По сути это продолжение .NET(C#) для 1С. Динамическая компиляция класса обертки для использования .Net событий в 1С через ДобавитьОбработчик или ОбработкаВнешнегоСобытия, но для кроссплатформенного .Net Core. Но в той разработке я использовал CodeDom. В .Net Core удобнее использовать Roslyn Scripting API.
В свое время делал вручную обертку для WhatsApp, а там более 30 событий. При этом весь процесс можно автоматизировать с помощью кодогенерации и в конечном итоге можно этот код динамически скомпилировать.
В «Создание компонент с использованием технологии Native API» есть метод для вызова внешнего события в 1С ExternalEvent. Синтаксис:
Параметры:
• Тип: WCHAR_T*. Строка с наименованием источника события.
• Тип: WCHAR_T*. Строка с наименованием события.
• Тип: WCHAR_T*. Строка c параметрами события.
Но в качестве wsData будем передавать ссылку на объект созданный из параметров события.
Итак начнем.
Сначала создадим описание класса на примере моего любимого System.IO.FileSystemWatcher, который в .Net Core находится в System.IO.FileSystem.Watcher
Чистые 1С ники могут пропустить вражеский код.
Создаем класс, подписываемся на события. В событии создаем анонимный класс из параметров и вызываем метод, который в итоге вызовет вышеописанныую функцию в 1С.
Для того, что бы закэшировать результат компиляции создадим класс.
Создаем поле:
Которое инициализируется при создании класса в статическом конструкторе. При компиляции используются сборки типов параметров и тип оборачиваемого объекта. Этот подход часто используется при универсальном создании сериализаторов.
Теперь мы можем вызвать делегат для создания объекта обертки для событий так.
Теперь перейдем к коду в 1С. В качестве получения кода на C# и 1С используется внешняя обработка ТестСобытийИзмененийВДиректории.epf.
Формируются методы обработчики по имени события которые вызываются через
Такой подход сокращает ручное написание кода. Ну и создание отслеживание изменений в директории
По окончании нужно позаботиться об освобождении ресурсов.
Теперь можно использовать не только методы и свойства объектов .Net, но и события. При этом используя только родной для 1С ка язык программирования. И ни одной строчки на вражеском языке.
В заключении я хочу поделиться своим недоумением по поводу обсуждения статей. Все обсуждение сводится к Русслишу и ъ.
Я подниму проблемы при использовании Native API в Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux
Так при создании Native API видны ноги из IDispatch. Но там использовались диспинтерфейсы для вызова только Invoke
1. Абсолютно не нужны методы FindMethod, FindProp, GetNParams, HasRetVal, GetParamDefValue
(IsPropReadable, IsPropWritable только для отладчика). Так как у методов bool CallAsProc, bool CallAsFunc, bool SetPropVal и bool GetPropVal есть возвращаемое значение об успешном выполнении. Информация об ошибке возвращается через AddError. Да и вызов по индексу это анахронизм от IDiapatch где было описание диспинтерфейсов для увеличения скорости вызова.
2. При возвращении методами SetPropVal и GetPropVal исключение не вызывается
3. Зачем то происходит установка свойств, там где в коде этого не требуется.
4. Вызывается метод как функция, там где метод вызывается как процедура.
5. Один из основных это нельзя вернуть и передать экземпляр ВК из методов ВК.
Я лично не вижу никаких проблем. Определить значение для такого типа и установить ссылку в поле pInterfaceVal.
В Native API есть структура
В которой можно использовать void* pInterfaceVal; IID InterfaceID. А в vt; указать, что это ВК. С недавних пор можно передавать byte[]. Так можно пойти и дальше.
Подсчет ссылок происходит на стороне 1С. Передавать можно в том числе и объекты 1С только на время вызова метода. Так при использовании IDispatch в 1С нет проблем при передачи IDispatch в параметрах метода. Сейчас скорость вызова метода ВК почти в 15 раз медленнее вызова из С++ только
И медленнее в 5 раз аналогичного метода 1С. При этом вместо одного метода вызывается FindMethod, GetNParams, CallAsFunc. А если вызывать напрямую без ВК то и скорость будет аналогичной с использованием внутренних методов.
Сейчас при передаче в метод ВК через свойство метод(Объект.Свойство) или в метод по ссылке без знач. 1С пытается присвоить значение, даже если это значение не изменилось. Можно в ВК предустмотреть передачу измененных параметров.
Сейчас на Windows множество компонент на COM. Те же ADO,Excel итд. Можно легко создать свою COM библиотеку на любом языке.
Поэтому при опросе почему не используют Использование сборок .NET в 1С 7.x b 8.x. Создание внешних Компонент
Большинство отвечает, что не намерены использовать продукт неизвестно от кого. Эта ситуация аналогична с ЯП Nemerle. Язык который мощнее C#, но за которым стоят энтузиасты никому не нужен. Но при этом все соглашаются, что если бы эта компонента была интегрирована в 1С на подобии ComОбъект то все ею бы пользовались.
Что касается кроссплатформенности, то .Net Core дает эту возможность. При этом эта технология сейчас активно развивается .NET Core Roadmap
Как я показал можно использовать любые классы .Net Core только на языке 1С. Можно использовать динамическую компиляцию скриптов или написать свою Сборку на C#, что значительно проще чем писать ВК.
Я знаю, что на данной площадке много разработчиков 1С. И у меня большая просьба к ним дать совет по развитию данной разработки. Если 1С не намерена изменять Native API, то я силы кину на что то другое. Хотя на данную разработку ушли годы и мне очень жалко её. Она как ребенок.
Я готов бесплатно участвовать в исследовательском проекте по применение .Net Core в 1С. Главное, что бы силы были потрачены не зря.
А возможности кроссплатформенного использования .Net Core в 1С колосcальные. Но вот мне интересно почему 1С не нужны? Вот ответ на этот вопрос я хотел бы услышать. Что касается Linux то на мои вопросы, чего не хватает по сравнению с Windows основным было это
В свое время работя с Торговым оборудованием обязательно были SDK на C#. Даже под WiCE. Многие были интероп обертками над нативными библиотеками. С появлением .Net Core будут делать под NetStandart. И на Линукс станет повеселее.
Исходники и примеры можно скачать Здесь
По сути это продолжение .NET(C#) для 1С. Динамическая компиляция класса обертки для использования .Net событий в 1С через ДобавитьОбработчик или ОбработкаВнешнегоСобытия, но для кроссплатформенного .Net Core. Но в той разработке я использовал CodeDom. В .Net Core удобнее использовать Roslyn Scripting API.
В свое время делал вручную обертку для WhatsApp, а там более 30 событий. При этом весь процесс можно автоматизировать с помощью кодогенерации и в конечном итоге можно этот код динамически скомпилировать.
В «Создание компонент с использованием технологии Native API» есть метод для вызова внешнего события в 1С ExternalEvent. Синтаксис:
bool ExternalEvent(WCHAR_T* wsSource, WCHAR_T* wsMessage, WCHAR_T* wsData)
Параметры:
• Тип: WCHAR_T*. Строка с наименованием источника события.
• Тип: WCHAR_T*. Строка с наименованием события.
• Тип: WCHAR_T*. Строка c параметрами события.
Но в качестве wsData будем передавать ссылку на объект созданный из параметров события.
Итак начнем.
Сначала создадим описание класса на примере моего любимого System.IO.FileSystemWatcher, который в .Net Core находится в System.IO.FileSystem.Watcher
Чистые 1С ники могут пропустить вражеский код.
public class ВрапперДляSystem_IO_FileSystemWatcher
{
Action<string,string,object> СобытиеДля1С;
System.IO.FileSystemWatcher РеальныйОбъект;
public ВрапперДляSystem_IO_FileSystemWatcher(Action<string,string,object> СобытиеДля1С, System.IO.FileSystemWatcher РеальныйОбъект)
{
this.СобытиеДля1С = СобытиеДля1С;
this.РеальныйОбъект = РеальныйОбъект;
РеальныйОбъект.Changed += (sender,e) =>
{
var Changed = new { sender=sender,e=e};
this?.СобытиеДля1С("System_IO_FileSystemWatcher","Changed",Changed);
};
РеальныйОбъект.Created += (sender,e) =>
{
var Created = new { sender=sender,e=e};
this?.СобытиеДля1С("System_IO_FileSystemWatcher","Created",Created);
};
РеальныйОбъект.Deleted += (sender,e) =>
{
var Deleted = new { sender=sender,e=e};
this?.СобытиеДля1С("System_IO_FileSystemWatcher","Deleted",Deleted);
};
РеальныйОбъект.Error += (sender,e) =>
{
var Error = new { sender=sender,e=e};
this?.СобытиеДля1С("System_IO_FileSystemWatcher","Error",Error);
};
РеальныйОбъект.Renamed += (sender,e) =>
{
var Renamed = new { sender=sender,e=e};
this?.СобытиеДля1С("System_IO_FileSystemWatcher","Renamed",Renamed);
};
}
public static object СоздатьОбъект(Action<string,string,object> СобытиеДля1С, System.IO.FileSystemWatcher РеальныйОбъект)
{
return new ВрапперДляSystem_IO_FileSystemWatcher(СобытиеДля1С, РеальныйОбъект);
}
}
return new Func<Action<string,string,object>,System.IO.FileSystemWatcher,object>(ВрапперДляSystem_IO_FileSystemWatcher.СоздатьОбъект);
Создаем класс, подписываемся на события. В событии создаем анонимный класс из параметров и вызываем метод, который в итоге вызовет вышеописанныую функцию в 1С.
Для того, что бы закэшировать результат компиляции создадим класс.
public class КомВраперДляСобытий<T>
{
public static readonly Func<Action<string, string, object>, T, object> СоздательОбертки;
public static Func<Action<string, string, object>, T, object> СоздатьОбертку()
{
Type типРеальногоОбъекта = typeof(T);
string ТипСтрРеальногоОбъекта = типРеальногоОбъекта.FullName;
var ИмяКласса = "ВрапперДля" + ТипСтрРеальногоОбъекта.Replace(".", "_").Replace("+", "_");
var ДСМВ = new ДляСозданияМодуляВрапера();
string строкаКласса = ДСМВ.СоздатьОписания(типРеальногоОбъекта);
var scr = Microsoft.CodeAnalysis.Scripting.ScriptOptions.Default;
var Сборки = ДСМВ.СборкиВПараметрах.Keys.ToArray();
scr = scr.WithReferences(Сборки)
.WithImports("System");
var res = (Func<Action<string, string, object>, T, object>)Microsoft.CodeAnalysis.CSharp.Scripting.CSharpScript.EvaluateAsync(строкаКласса, scr).Result;
return res;
}
static КомВраперДляСобытий()
{
СоздательОбертки= СоздатьОбертку();
}
}
Создаем поле:
public static readonly Func<Action<string, string, object>, T, object> СоздательОбертки;
Которое инициализируется при создании класса в статическом конструкторе. При компиляции используются сборки типов параметров и тип оборачиваемого объекта. Этот подход часто используется при универсальном создании сериализаторов.
Теперь мы можем вызвать делегат для создания объекта обертки для событий так.
public static void ВызватьВнешнееСобытиеСОбъектом(string Источник,string Событие, object Данные)
{
// Задача из объекта Данные получить строку
// И вызвать внешнее событие в 1С
// И в зависимости от переданного типа получить строковое представление.
var ДанныеДля1с = AutoWrap.ОбернутьОбъект(Данные);
string res="";
if (Данные == null)
res = "";
else if (ДанныеДля1с is AutoWrap)
res = ((AutoWrap)ДанныеДля1с).ПолучитьСсылку();
else
res = ДанныеДля1с.ToString();
AutoWrap.ВызватьВнешнееСобытие1С(Источник, Событие, res);
}
public static object СоздатьОберткуДляСобытий(Object ОбъектССобытиями)
{
Type тип = ОбъектССобытиями.GetType();
Type genType = typeof(КомВраперДляСобытий<>);
Type constructed = genType.MakeGenericType(new Type[] { тип });
var ИмяСвойства = "СоздательОбертки";
var fi = constructed.GetField(ИмяСвойства);
Delegate функция = (Delegate)fi.GetValue(null);
// Получили делегат
// И из него получим объект обертку для событий который передадим в 1С для хранения ссылки на него
object обертка = функция.DynamicInvoke(new Action<string,string,object>(ВызватьВнешнееСобытиеСОбъектом), ОбъектССобытиями);
return обертка;
}
Теперь перейдем к коду в 1С. В качестве получения кода на C# и 1С используется внешняя обработка ТестСобытийИзмененийВДиректории.epf.
Процедура СообщитьОбИзменении(знач Событие)
e=Событие.e;
Если e<>Неопределено Тогда
e=ъ(e);
ChangeType=ъ(e.ChangeType);
Сообщить( e.FullPath + " " + Врап.ВСтроку(ChangeType.ПолучитьСсылку()));
КонецЕсли;
КонецПроцедуры // СообщитьОбИзменении
// параметр Данные:Анонимный Тип
// Свойства параметра
// sender:System.Object
// e:System.IO.FileSystemEventArgs
Процедура Changed(Данные)
Сообщить("Changed "+Врап.ВСтроку(Данные.ПолучитьСсылку()));
СообщитьОбИзменении(Данные)
КонецПроцедуры
// параметр Данные:Анонимный Тип
// Свойства параметра
// sender:System.Object
// e:System.IO.FileSystemEventArgs
Процедура Created(Данные)
Сообщить("Created "+Врап.ВСтроку(Данные.ПолучитьСсылку()));
СообщитьОбИзменении(Данные)
КонецПроцедуры
// параметр Данные:Анонимный Тип
// Свойства параметра
// sender:System.Object
// e:System.IO.FileSystemEventArgs
Процедура Deleted(Данные)
Сообщить("Deleted "+Врап.ВСтроку(Данные.ПолучитьСсылку()));
СообщитьОбИзменении(Данные)
КонецПроцедуры
// параметр Данные:Анонимный Тип
// Свойства параметра
// sender:System.Object
// e:System.IO.ErrorEventArgs
Процедура Error(Данные)
Сообщить("Error "+Врап.ВСтроку(Данные.ПолучитьСсылку()));
СообщитьОбИзменении(Данные)
КонецПроцедуры
// параметр Данные:Анонимный Тип
// Свойства параметра
// sender:System.Object
// e:System.IO.RenamedEventArgs
Процедура Renamed(Данные)
Сообщить("Renamed "+Врап.ВСтроку(Данные.ПолучитьСсылку()));
СообщитьОбИзменении(Данные)
КонецПроцедуры
Функция ОбернутьОбъектНеопределенногоТипа(знач Ссылка)
Если Ссылка=null или Ссылка=Неопределено Тогда
возврат неопределено
КонецЕсли;
Если ТипЗнч(ссылка)=Тип("Строка") Тогда
Если найти(Ссылка,"ёЁ<Ьъ>№_%)Э?&")= 1 Тогда
возврат ъ(Ссылка)
КонецЕсли;
КонецЕсли;
возврат Ссылка
КонецФункции // ОбернутьОбъектНеопределенногоТипа()
Процедура ОбработкаВнешнегоСобытия(Источник, ИмяСобытия, Данные)
Сообщить(Источник);
Если Источник = "System_IO_FileSystemWatcher" Тогда
Объект= ОбернутьОбъектНеопределенногоТипа(Данные);
Выполнить(ИмяСобытия + "(Объект)");
КонецЕсли;
КонецПроцедуры // ОбработкаВнешнегоСобытия
Формируются методы обработчики по имени события которые вызываются через
Объект= ОбернутьОбъектНеопределенногоТипа(Данные);
Выполнить(ИмяСобытия + "(Объект)");
Такой подход сокращает ручное написание кода. Ну и создание отслеживание изменений в директории
Процедура Остановить()
Если watcher<>Неопределено Тогда
watcher.EnableRaisingEvents = false;
КонецЕсли;
КонецПроцедуры
Процедура КнопкаВыполнитьНажатие(Кнопка)
Остановить();
WatcherСборка=ъ(Врап.Сборка("System.IO.FileSystem.Watcher"));
WatcherТип=ъ(WatcherСборка.GetType("System.IO.FileSystemWatcher"));
NotifyFilters=ъ(WatcherСборка.GetType("System.IO.NotifyFilters"));
Директория=ОтслеживаемыйКаталог;//"c:\tmp\";
watcher=ъ(Врап.Новый(WatcherТип.ПолучитьСсылку(),Директория));
//watcher.NotifyFilter = NotifyFilters.LastAccess | NotifyFilters.LastWrite
// | NotifyFilters.FileName | NotifyFilters.DirectoryName;
// Only watch text files.
LastAccess=ъ(NotifyFilters.LastAccess);
LastWrite=ъ(NotifyFilters.LastWrite);
FileName=ъ(NotifyFilters.FileName);
DirectoryName=ъ(NotifyFilters.DirectoryName);
рез=ъ(Врап.OR(LastAccess.ПолучитьСсылку(),LastWrite.ПолучитьСсылку(),FileName.ПолучитьСсылку(),DirectoryName.ПолучитьСсылку()));
watcher.NotifyFilter=рез.ПолучитьСсылку();
watcher.Filter = "*.*";
watcher.IncludeSubdirectories = true;
watcher.EnableRaisingEvents = true;
СоздатьОбертку(Watcher);
КонецПроцедуры
По окончании нужно позаботиться об освобождении ресурсов.
Процедура ПриЗакрытии()
Если watcher<>Неопределено Тогда
Остановить();
Врап.ЗакрытьРесурс(watcher.ПолучитьСсылку());
watcher=Неопределено;
ОберткаСобытий=Неопределено;
GC=ъТип("System.GC");
GC.Collect();
GC.WaitForPendingFinalizers();
Врап= Неопределено;
КонецЕсли
КонецПроцедуры
Теперь можно использовать не только методы и свойства объектов .Net, но и события. При этом используя только родной для 1С ка язык программирования. И ни одной строчки на вражеском языке.
В заключении я хочу поделиться своим недоумением по поводу обсуждения статей. Все обсуждение сводится к Русслишу и ъ.
Я подниму проблемы при использовании Native API в Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux
Так при создании Native API видны ноги из IDispatch. Но там использовались диспинтерфейсы для вызова только Invoke
1. Абсолютно не нужны методы FindMethod, FindProp, GetNParams, HasRetVal, GetParamDefValue
(IsPropReadable, IsPropWritable только для отладчика). Так как у методов bool CallAsProc, bool CallAsFunc, bool SetPropVal и bool GetPropVal есть возвращаемое значение об успешном выполнении. Информация об ошибке возвращается через AddError. Да и вызов по индексу это анахронизм от IDiapatch где было описание диспинтерфейсов для увеличения скорости вызова.
2. При возвращении методами SetPropVal и GetPropVal исключение не вызывается
3. Зачем то происходит установка свойств, там где в коде этого не требуется.
4. Вызывается метод как функция, там где метод вызывается как процедура.
5. Один из основных это нельзя вернуть и передать экземпляр ВК из методов ВК.
Я лично не вижу никаких проблем. Определить значение для такого типа и установить ссылку в поле pInterfaceVal.
В Native API есть структура
struct _tVariant
{
.....
_ANONYMOUS_STRUCT struct
{
void* pInterfaceVal;
IID InterfaceID;
}
......
TYPEVAR vt;
};
В которой можно использовать void* pInterfaceVal; IID InterfaceID. А в vt; указать, что это ВК. С недавних пор можно передавать byte[]. Так можно пойти и дальше.
Подсчет ссылок происходит на стороне 1С. Передавать можно в том числе и объекты 1С только на время вызова метода. Так при использовании IDispatch в 1С нет проблем при передачи IDispatch в параметрах метода. Сейчас скорость вызова метода ВК почти в 15 раз медленнее вызова из С++ только
public static bool CallAsFunc(int Target, IntPtr ИмяМетодаPtr, IntPtr ReturnValue, IntPtr МассивПараметров, int РазмерМассива)
И медленнее в 5 раз аналогичного метода 1С. При этом вместо одного метода вызывается FindMethod, GetNParams, CallAsFunc. А если вызывать напрямую без ВК то и скорость будет аналогичной с использованием внутренних методов.
Сейчас при передаче в метод ВК через свойство метод(Объект.Свойство) или в метод по ссылке без знач. 1С пытается присвоить значение, даже если это значение не изменилось. Можно в ВК предустмотреть передачу измененных параметров.
Сейчас на Windows множество компонент на COM. Те же ADO,Excel итд. Можно легко создать свою COM библиотеку на любом языке.
Поэтому при опросе почему не используют Использование сборок .NET в 1С 7.x b 8.x. Создание внешних Компонент
Большинство отвечает, что не намерены использовать продукт неизвестно от кого. Эта ситуация аналогична с ЯП Nemerle. Язык который мощнее C#, но за которым стоят энтузиасты никому не нужен. Но при этом все соглашаются, что если бы эта компонента была интегрирована в 1С на подобии ComОбъект то все ею бы пользовались.
Что касается кроссплатформенности, то .Net Core дает эту возможность. При этом эта технология сейчас активно развивается .NET Core Roadmap
Как я показал можно использовать любые классы .Net Core только на языке 1С. Можно использовать динамическую компиляцию скриптов или написать свою Сборку на C#, что значительно проще чем писать ВК.
Я знаю, что на данной площадке много разработчиков 1С. И у меня большая просьба к ним дать совет по развитию данной разработки. Если 1С не намерена изменять Native API, то я силы кину на что то другое. Хотя на данную разработку ушли годы и мне очень жалко её. Она как ребенок.
Я готов бесплатно участвовать в исследовательском проекте по применение .Net Core в 1С. Главное, что бы силы были потрачены не зря.
А возможности кроссплатформенного использования .Net Core в 1С колосcальные. Но вот мне интересно почему 1С не нужны? Вот ответ на этот вопрос я хотел бы услышать. Что касается Linux то на мои вопросы, чего не хватает по сравнению с Windows основным было это
Главная проблема — клиентов на линукс перевести. А тут главный тормоз — работа с торговым оборудованием. Плохо дело с готовыми и надежными дровами под Native API под всякое разное. А высокоуровневая байда как-то и не держит особо. Технически, во всяком случае.
В свое время работя с Торговым оборудованием обязательно были SDK на C#. Даже под WiCE. Многие были интероп обертками над нативными библиотеками. С появлением .Net Core будут делать под NetStandart. И на Линукс станет повеселее.
Исходники и примеры можно скачать Здесь
Поделиться с друзьями
littleG
Отличная статья.
Спасибо.
Serginio1
Большое спасибо! Это вдохновляет. А то руки уже опускаются.