Есть еще момент. Клиент на начальном этапе получает ссылку на тип со статическими методами. В данном случае GetType, GetAssembly. Никто не мешает поместить туда другой тип с другим набором методов. При этом несложно сделать универсальную сериализацию параметров на основе CopyTo добавив в перечисление EnumVar новое значение и при мериализации указвать это значение, затем строковое представление типа и сериализованное в Json строку значение. А эвены можно передавать на клиента отдельно.
То есть из существуещей разработки можно сделать различные варианты. Было бы желание.
Кстати, что касается WFF, то можно ограничить число экспортируемых типов, необходимых для функционирования удаленного приложения. Все передаваемые типы легко контролируются.
Кстати при работе в Web Api ты так же хранишь состояние сессии.
Если мы говорим об песочнице аналоге AppDomain, то на данный момент я не нашел, но с выходом NetStandard 2 и .net Core 2 то там уже вроде будут NamedPipes. Кроме того, можно отрыть только определенные порты.
Зачем песочнице доступ к БД? Суть AppDomain это возможность выгружать сборки, работа с нестабильным оборудованием с использованием натива. Если это не чужой код, то какие могут быть атаки. А проблема плагинов она будет и в моем решении и в обычном решении. Просто в моем решении можно прикрыть кучу дыр, за счет прав пользователя.
Здесь еще один момент, по уму это все должна сделать MS. Ибо я никто и звать меня никак. А вещь нужная, при этом нет встроенной технологии типа Remoting. По сути введение псевдоинтерфейсов (аналог анотации типов в TypeScript) решают проблему типизации. Внутри то так или иначе тоже самое.
Плюс работа с Reflection. Если в большом .Net есть метод типа InvokeMember, то для .Net Core я сам реализовать поиск нужного метода, плюс поиск дженерик метода с выводом типа, поиск методов расширений итд. Это тоже было бы неплохо иметь в стандартных библиотеках как методы расширений по аналогии с GetTypeInfo.
Помоему все просто. Получаете тип создаете объекты. Единственно, что нет автоматической сериализации для не строк чисел, GUID и byte[]. По сравнению с WCF и Remoting все значительно проще.
Наконец, .NET Core — это нижележащая инфраструктура, от которой зависит .NET Native. Когда проектировали .NET Native, стало понятно, что .NET Framework не подойдет в качестве фундамента для библиотек классов этой инфраструктуры. Дело в том, что .NET Native статически связывает инфраструктуру с приложением, а затем удаляет все лишнее, что не нужно приложению. (Здесь я сильно упрощаю общую картину, но идею вы уловили. Подробнее на эту тему см. «Inside .NET Native» по ссылке bit.ly/1UR7ChW.)
Ну для локал сервера разрыва соединения не замечал. Кроме всего есть режим с подключением отключением.
Есть System.IO.Pipes.dll в \.nuget\packages\System.IO.Pipes\4.3.0\ref\netstandard1.3\, но напрямую подключить не удалось.
Ну во первых это нужно для AppDomain, а для безопасности можно код выполнять в терминальной сессии, под определенными правами пользователя.
Спасибо! Суть то в том, что ты первый кто заинтересовался моими разработками.
Я один. При этом 1С ник, который решил интегрировать .Net в 1С. Ноги растут оттуда.
Я мог бы сделать и реальную кроссплатформенность, но главное показать как это работает.
Можно добавить использование JS объектов и функций на стороне .Net.
Что касается out of process каждый решает сам. Например по опыты в 1С приходится сочетать свои сборки и например тот же AngleSharp проще использовать на стороне 1С итд.
Можно использовать динамическую компиляцию итд.
Использовать out of process несколько сложнее.
Для Net технологий однозначно. Это и UWP и Xamarin с выходом NetStandard 2 станут полностью совместимы с .Net Core 1.2
Но к нему присматриваются и Samsung с Tizen с Xamarin Forms
Вот я с C++ не очень дружу. Они кстати тоже через файлы распространяют.
Ну Angular 2 то развивается и WebPack тоже. Сейчас с ним разберусь.
У меня есть статья про 1С, Linux, Excel, Word, OpenXML,ADO и Net Core
Сейчас NetStandard 2 и .Net Core 1.2 выйдут и возможностей будет близки к взрослому .Net
Скорость вызова из натива метода принимающего int и возвращающего int составляет порядка 500 000 вызовов в секунду. Для JavaScript- Native-Managed CEF, ES6, Angular 2, TypeScript использование классов .Net Core. Создание кроссплатформенного GUI для .Net с помощью CEF
Составляет порядка 60 000 вызовов ( но например итератор поряка 170 000).
То для Tcp/Ip это порядка 14 000. Так, что затраты на Reflection минимальны, по сравнению с маршалингом.
То есть из существуещей разработки можно сделать различные варианты. Было бы желание.
Если мы говорим об песочнице аналоге AppDomain, то на данный момент я не нашел, но с выходом NetStandard 2 и .net Core 2 то там уже вроде будут NamedPipes. Кроме того, можно отрыть только определенные порты.
Зачем песочнице доступ к БД? Суть AppDomain это возможность выгружать сборки, работа с нестабильным оборудованием с использованием натива. Если это не чужой код, то какие могут быть атаки. А проблема плагинов она будет и в моем решении и в обычном решении. Просто в моем решении можно прикрыть кучу дыр, за счет прав пользователя.
Плюс работа с Reflection. Если в большом .Net есть метод типа InvokeMember, то для .Net Core я сам реализовать поиск нужного метода, плюс поиск дженерик метода с выводом типа, поиск методов расширений итд. Это тоже было бы неплохо иметь в стандартных библиотеках как методы расширений по аналогии с GetTypeInfo.
У меня это все реализовано.
Что в начальном примере непонятно?
Там описывается Refit: The automatic type-safe REST library for .NET Core, Xamarin and .NET
Есть System.IO.Pipes.dll в \.nuget\packages\System.IO.Pipes\4.3.0\ref\netstandard1.3\, но напрямую подключить не удалось.
Ну во первых это нужно для AppDomain, а для безопасности можно код выполнять в терминальной сессии, под определенными правами пользователя.
По сути внешне все остается тем же
Я один. При этом 1С ник, который решил интегрировать .Net в 1С. Ноги растут оттуда.
Я мог бы сделать и реальную кроссплатформенность, но главное показать как это работает.
Можно добавить использование JS объектов и функций на стороне .Net.
Что касается out of process каждый решает сам. Например по опыты в 1С приходится сочетать свои сборки и например тот же AngleSharp проще использовать на стороне 1С итд.
Можно использовать динамическую компиляцию итд.
Использовать out of process несколько сложнее.
Chromium Embedded Framework (CEF) Automated Builds
Кроме того использовать Net Core отсюда
.Net Core All downloads
Плюс я не пробовал на Linux, то возможно надо будет изменить загрузку .Net Core
Вот моя первая статья Кроссплатформенное использование классов .Net из неуправляемого кода. Или аналог IDispatch на Linux
На просторах интернета было найдено решение: Hosting .NET Core Clr in your own process и simpleCoreCLRHost и
initializeCoreCLR createDelegate и
unixinterface
Суть подключения заключается в загрузке библиотеки coreclr.dll, получения нужных интерфейсов и запуск CLR Runtime Host.
Там кстати там WebPack без поддержки Es6
Хотя они все так или иначе пересекаются. Спасибо!
Но к нему присматриваются и Samsung с Tizen с Xamarin Forms
Да и Googlу тоже заинтересован Выпуск .NET Core 1.1. Google присоединился к .NET Foundation. Samsung выпустил .NET для Tizen
Ну Angular 2 то развивается и WebPack тоже. Сейчас с ним разберусь.
У меня есть статья про 1С, Linux, Excel, Word, OpenXML,ADO и Net Core
Сейчас NetStandard 2 и .Net Core 1.2 выйдут и возможностей будет близки к взрослому .Net