Все сделал. Сейчас пишу статью на Хабре.
Написал статью CEF, ES6, Angular 2, TypeScript использование классов .Net Core для расширения возможностей

Добавил еще статью про события


CEF, Angular 2 использование событий классов .Net Core

Здравствуйте, Serginio1, Вы писали:

S>Есть идея иметь доступ из TypeScript к методам и свойствам классов .Net.
А не проще
https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api
?

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>>Есть идея иметь доступ из TypeScript к методам и свойствам классов .Net.
S>А не проще
S>https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api
S>?

Это значительно сложнее. Суть делать все на стороне клиента ASP.NET Core, Angular 2, SignalR для чайников

Сервер выступает только для получения и отправки данных, а все что связано с HTML и простыми функциями можно делать на клиенте.
По сути это замена Silverlight

Так или иначе удобнее делать вызов через методы аля WCF

Здравствуйте, Serginio1, Вы писали:

S> Это значительно сложнее. Суть делать все на стороне клиента
Нативный / managed код на клиенте? Ну так поднимите там любой web api-host, несложно абсолютно.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>> Это значительно сложнее. Суть делать все на стороне клиента
S>Нативный / managed код на клиенте? Ну так поднимите там любой web api-host, несложно абсолютно.

И смысл? Либо я должен все методы и классы прописать на стороне web api-host/ При этом данные получать не ввиде метода, в ввиде

http.get('/api/SampleData/WeatherForecasts').subscribe(result => {
            this.forecasts = result.json();

Который можно получить более удобоваримо и сразу с автоматической оберткой

this.forecasts = await wrap.WeatherForecasts();

Эту обертку можно сделать и к нативу и Вэб сервисам и к HTTP сервисам.

Кстати и в 1С лучше будут использовать через Вэб или HTTP сервисы нежели напрямую работать с объектами .Net.
Хотя удобнее сразу работать с классами .Net все в одном месте и так же проблема с объектами. Хранить их на сервере или сериализовывать передавая туда и обратно
Мой подход удобнее чем WCF.
Но он никому не нужен. Я дурак.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>> Это значительно сложнее. Суть делать все на стороне клиента
S>Нативный / managed код на клиенте? Ну так поднимите там любой web api-host, несложно абсолютно.

Ну смотря какая логика. Возьмем пример нынешнего Xamarin. Xamarin.Forms очень беден, поэтому многие делают общую логику отдельно (которая может быть сложной),
а морду рисуют для каждой ОС отдельно.

Сейчас для отличных от Win декстопов нет UI.
Но например у тебя есть приложение на UWP или WPF. Можно выделить логику отдельно, а морду нарисовать на Angular 2
Разница использования .Net кода только в том, что все методы асинхронные. При этом можно подписываться к событиям 1С,.Net Core. Динамическая компиляция класса обертки для получения событий .Net объекта в 1С. Для Вэб апи нужно городить SignalR или WebSocket.
То есть перенести приложение достаточно легко, в отличие от web api-host.

Но вот мне интересно, а чем тебе не нравится мой вариант. Чем он хуже web api-host?
Я вижу только одни достоинства.

Здравствуйте, Serginio1, Вы писали:

S> Ну смотря какая логика. Возьмем пример нынешнего Xamarin. Xamarin.Forms очень беден, поэтому многие делают общую логику отдельно (которая может быть сложной),
S>а морду рисуют для каждой ОС отдельно.
Таки посмотри вот это и вот это. Нет смысла ломиться в открытую дверь


S> Сейчас для отличных от Win декстопов нет UI.
S>Но например у тебя есть приложение на UWP или WPF. Можно выделить логику отдельно, а морду нарисовать на Angular 2
Если есть человек пять, которые несколько лет будут работать на доведение до ума интеропа, биндинга и прочего-прочего-прочего — ок. Если нет — затея из серии писать в одно лицо СУБД.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>> Ну смотря какая логика. Возьмем пример нынешнего Xamarin. Xamarin.Forms очень беден, поэтому многие делают общую логику отдельно (которая может быть сложной),
S>>а морду рисуют для каждой ОС отдельно.
S>Таки посмотри вот это и вот это. Нет смысла ломиться в открытую дверь

Ну моложцы развиваются. Но это не для декстопа.

S>> Сейчас для отличных от Win декстопов нет UI.
S>>Но например у тебя есть приложение на UWP или WPF. Можно выделить логику отдельно, а морду нарисовать на Angular 2
S>Если есть человек пять, которые несколько лет будут работать на доведение до ума интеропа, биндинга и прочего-прочего-прочего — ок. Если нет — затея из серии писать в одно лицо СУБД.
Ну во первых оно уже работает для 1С. Сделано за две недели одним человеком при этом программистом 1С.
Биндинг уже есть в Angular 2.

Здравствуйте, Serginio1, Вы писали:

S> Ну моложцы развиваются. Но это не для декстопа.
Десктоп как рынок жив только для профессионального софта. В моде нынче рынок консумеров, для которых компьютер — чисто бытовое устройство, как телевизор или мясорубка.
Всё остальное — веб.

S>>Если есть человек пять, которые несколько лет будут работать на доведение до ума интеропа, биндинга и прочего-прочего-прочего — ок. Если нет — затея из серии писать в одно лицо СУБД.
S> Ну во первых оно уже работает для 1С. Сделано за две недели одним человеком при этом программистом 1С.
Нет. Сделано — это не есть код. Сделано — это есть продукт. Т.е. помимо кода — сайт, документашка и community, как минимум. Иначе мы обсуждаем вещь, которая интересна только автору и которая загнётся сразу же, как только автор потеряет к ней интерес.

S>Биндинг уже есть в Angular 2.
К значениям из хоста — нет. Подсказка: как только дело от примитивных текстовых полей переходит, скажем, к гриду или дереву с возможностью перетаскивания узлов, так всё сразу становится ооочень тоскливо.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>> Ну моложцы развиваются. Но это не для декстопа.
S>Десктоп как рынок жив только для профессионального софта. В моде нынче рынок консумеров, для которых компьютер — чисто бытовое устройство, как телевизор или мясорубка.
S>Всё остальное — веб.

Корпоративный софт является профессиональным? Я в нем работаю.

S>>>Если есть человек пять, которые несколько лет будут работать на доведение до ума интеропа, биндинга и прочего-прочего-прочего — ок. Если нет — затея из серии писать в одно лицо СУБД.
S>> Ну во первых оно уже работает для 1С. Сделано за две недели одним человеком при этом программистом 1С.
S>Нет. Сделано — это не есть код. Сделано — это есть продукт. Т.е. помимо кода — сайт, документашка и community, как минимум. Иначе мы обсуждаем вещь, которая интересна только автору и которая загнётся сразу же, как только автор потеряет к ней интерес.
Поэтому я и вышел с опросом идеи. Но кстати есть кроссплатформенная замена COM XPCOM

Я предлагаю легкий способ замены COM для использования классов .Net Core
Понятно, что если я и зделаю, то мало кто будет пользоваться.
Но я не пойму в чем идея то плоха?


S>>Биндинг уже есть в Angular 2.
S>К значениям из хоста — нет. Подсказка: как только дело от примитивных текстовых полей переходит, скажем, к гриду или дереву с возможностью перетаскивания узлов, так всё сразу становится ооочень тоскливо.
Ну и Angular 2 развивается.

Здравствуйте, Serginio1, Вы писали:

S>>Десктоп как рынок жив только для профессионального софта.
S> Корпоративный софт является профессиональным? Я в нем работаю.
Да.

S>Поэтому я и вышел с опросом идеи. Но кстати есть кроссплатформенная замена COM XPCOM
Которая просто костыль для портирования аддонов? У меня плохие новости.


S>Но я не пойму в чем идея то плоха?
Сама идея — замечательная, но только пока мы обсуждаем в духе "за всё хорошее и против всего плохого". Как только переходим к реальной жизни, так сразу начинаются реальные проблемы. Поддержка там, перфоманс, простота использования, наличие специалистов на рынке, вот это всё.


S>>>Биндинг уже есть в Angular 2.
S>>К значениям из хоста — нет. Подсказка: как только дело от примитивных текстовых полей переходит, скажем, к гриду или дереву с возможностью перетаскивания узлов, так всё сразу становится ооочень тоскливо.
S> Ну и Angular 2 развивается.
Такое впечатление, что вы не читаете то, что вам пишут и вместо этого подставляете первый ответ из гугла, без обид. Нет, angular не развивается в направлении "двусторонний сериализуемый биндинг".

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>>>Десктоп как рынок жив только для профессионального софта.
S>> Корпоративный софт является профессиональным? Я в нем работаю.
S>Да.

S>>Поэтому я и вышел с опросом идеи. Но кстати есть кроссплатформенная замена COM XPCOM
S>Которая просто костыль для портирования аддонов? У меня плохие новости.

Ну я говорю пока про Native Client Messaging System
Такая же система обмена есть и в EDGE/ Кстати а у тебя не ссылочки на создания плагинов для Edge в VS.
Так или иначе роль обертки минимальна.

S>>Но я не пойму в чем идея то плоха?
S>Сама идея — замечательная, но только пока мы обсуждаем в духе "за всё хорошее и против всего плохого". Как только переходим к реальной жизни, так сразу начинаются реальные проблемы. Поддержка там, перфоманс, простота использования, наличие специалистов на рынке, вот это всё.

1. Поддержка. Если этим заинтересуется тот же гугл поддержка обеспечена!
2. Перфоманс. Но мы же не будем в циклах крутить вызовы. Обычно нужно просто получить событие от хоста и передать данные на хост при событии на клиенте. Это обычная логика GUI/
3. Ну синтаксис использования то мало отличается от C#, а TypeScript набирает обороты.


S>>>>Биндинг уже есть в Angular 2.
S>>>К значениям из хоста — нет. Подсказка: как только дело от примитивных текстовых полей переходит, скажем, к гриду или дереву с возможностью перетаскивания узлов, так всё сразу становится ооочень тоскливо.
S>> Ну и Angular 2 развивается.
S>Такое впечатление, что вы не читаете то, что вам пишут и вместо этого подставляете первый ответ из гугла, без обид. Нет, angular не развивается в направлении "двусторонний сериализуемый биндинг".

Может быть я не совсем понял. Но например через Proxy можно подсунуть любой объект который будет взаимодействовать с хостом, а в нем автоматическая сереализация десериализация параметров.
Можно кстати сделать и синхронный вызов. Нужно посмотреть как там с мьютексами семаформаи эвентами.

Здравствуйте, Sinix, Вы писали:
S>Если есть человек пять, которые несколько лет будут работать на доведение до ума интеропа, биндинга и прочего-прочего-прочего — ок. Если нет — затея из серии писать в одно лицо СУБД.

Там интеропа то нет. Есть просто вызов нескольких статических методов .Net.
Плюс один нативный метод для событий.

typedef bool(STDMETHODCALLTYPE *ManagedCallAsFunc)(const __int32, const wchar_t*, tVariant* pvarRetValue, tVariant* paParams, const __int32  lSizeArray);
    typedef int(STDMETHODCALLTYPE *ManagedGetNParams)(const __int32, const wchar_t*);
    typedef bool(STDMETHODCALLTYPE *ManagedGetPropVal)(const __int32, const wchar_t*, tVariant*);
    typedef bool(STDMETHODCALLTYPE *ManagedSetPropVal)(const __int32, const wchar_t*, tVariant*);
    typedef void(STDMETHODCALLTYPE *ManagedSetDelegate)(void*(*) (long), void(*) (const wchar_t*), void(*) (wchar_t*, wchar_t*,wchar_t*));
    typedef void(STDMETHODCALLTYPE *ManagedDeleteObject)(const __int32);
    typedef void(STDMETHODCALLTYPE *ManagedSetPath)(const wchar_t*);

То есть на стороне н

bool BaseNetObjectToNative::SendEvent(wchar_t *Data)
    {
        return m_iConnect->ExternalEvent(L"NetObjectToNative", L"NetObjectToNative", Data);
    }

Вот и все взаимодействи на стороне натива.
А вот на стороне .Net там немного покруче. Там и параметы массивы, ref параметры, автовывотд дженерик типов, поиск методов расширений и опять же с дженериками.

Но то, что сделано на строне .Net легко применить при любом изменении WEB плугина
Опять же есть поддержка событий и асинхронных методов через динамическую компиляцию.

Опять же посмотри на Unmanaged API Reference

Я предлагаю значительно более легковесную замену. При этом сейчас нет ни Unmanaged API Reference ни Ireflect для .Net Core

Уважзаемый alex_public мне посоветовал
cef / JavaScriptIntegration

Можно и без асинхронности вызова обычных методов обойтись.

При этом можно зарегистрировать различные обработчики.

В итоге можно вызывать асинхронные методы например добавив кллючевое слово async, а для свойств можно использовать @ в начале свойства

 let url= "https://msdn.microsoft.com/ru-ru/library/hh551745(v=vs.118).aspx");
    let response= await client.async.GetStringAsync(url);
    let response= client.GetStringAsync(url).@Result;

для ref параметров можно использовать класс обертку

class RefParam{
isRefparam=true;
constructor(public Value:any);
}

Нашел способ использования CEF в Visual Studio
Building the 64-bit version of Chromium Embedded Framework on Windows

Для VS 2017 cmake.exe -G "Visual Studio 15 2017"
Буду благодарен ссылочкам на проекты CEF В Visual Studio.

Исходя из cef / JavaScriptIntegration
По сути то мне нужно реализовать окно и

class ClientApp:public CefApp,public CefRenderProcessHandler ,public CefBrowserProcessHandler 
{ 
public:
    ClientApp(void);
    ~ClientApp(void);
    //implement CefApp
    virtual CefRefPtr<CefRenderProcessHandler> GetRenderProcessHandler()OVERRIDE { return this; }
    virtual CefRefPtr<CefBrowserProcessHandler> GetBrowserProcessHandler()OVERRIDE { return this; }
    //implement CefRenderProcessHandler
    virtual void OnContextCreated(CefRefPtr<CefBrowser> browser,CefRefPtr<CefFrame> frame,CefRefPtr<CefV8Context> context) OVERRIDE;
    IMPLEMENT_REFCOUNTING(ClientApp)
};

И несколько

class MyV8Handler : public CefV8Handler
{
public:
    CMyV8Handler(void);
    ~CMyV8Handler(void);
    virtual bool Execute(const CefString& name,
        CefRefPtr<CefV8Value> object,
        const CefV8ValueList& arguments,
        CefRefPtr<CefV8Value>& retval,
        CefString& exception) OVERRIDE;
    IMPLEMENT_REFCOUNTING(CMyV8Handler);
};

Browser Life Span

Здравствуйте, Serginio1, Вы писали:

Честно говоря, учитывая что ты нашел все необходимые материалы — в чём вопрос-то?

Если есть желания связаться с CEF — вопросы лучше задавать на оригинальном форуме (там больше людей в теме).
Если есть необходимость — я могу помочь в скайпе (направить в нужную сторону или попытаться объяснить на пальцах по мере возникновения вопросов), как делаются те или иные вещи в CEF.

В плане JS->Native вызовов всё сводится к нескольким подходам:

1. XHR и в browser process реализуется resource handler. Преимущество: renderer->browser IPC достаётся бесплатно. Недостаток: только асинхронные вызовы.

2. V8Handler/V8Accessor. Преимущество: выставляем любой JS API. Недостаток: renderer->browser IPC бесплатно не достаётся, но посылку сообщений делаем через CefProcessMessage (только асинхронный обмен). Если нужен иной IPC — никто не помешает создать. В принципе это самый универсальный вариант.

3. Используем CEF's message router. Как бы всё готово, но по сути делает оно тоже что и (2), выставляя готовый шлюз в JS.

Так или иначе на стороне JS должна быть какая-то клиентская библиотека (генерённая?) выставляющая вменяемый API для потребления, поэтому каким именно образом оно реализовано (1-3) обычно не так уж важно.

Здравствуйте, fddima, Вы писали:

Ах, для CefGlue v1 (это для CEF 1), я делал автоматический экспозер C# объектов в JS. Для CefGlue v3 я такой функциональности не делал. Хотя нехило бы воскресить. В принципе там рутины больше.

UPD: Но сейчас, если бы я начал это делать — я бы поддержал это дело ещё лучше — от async/await до колбэков. Хотя с ещё большей вероятностью все вызовы из JS сделал бы асинхронными, т.к. блокировка потоков — это как то чего в хроме лучше не делать. Хотя в принципе можно. Вопрос насколько это необходимо.

Здравствуйте, fddima, Вы писали:

Здравствуйте, Serginio1, Вы писали:

S> Огромное спасибо за ответ. 2 дня боролся. Но поборол. У меня опыта на С++ мало. Вспоминаю, то что забыл и учу то, что не знал. Но сегодня подключил
Молодец.
Не многие юзеры начинаю с вики, и в итоге задают глупые вопросы.

S> У CEF есть и dev tools. Но вот нужно правильно подключить файлы из CefClient. Разберусь.
S>Главное сдвинулся с мертвой точки. Еще раз огромное спасибо!
devtools открываются просто вызовом метода из CefBrowserHost по моему. Для этого от CefClient ничего не нужно. Из cefclient обязательно перенеси манифест приложения, иначе потом напорешься на всякие неприятные штуки.

Во всём остальном вроде всё норм, в смысле с моей стороны добавить нечего — дерзай!

PS: Потом, когда получится что-то интересное (если это публично доступно), не забудь похвастаться в соответствующим разделе форума по CEF.

Здравствуйте, fddima, Вы писали:

F>Здравствуйте, Serginio1, Вы писали:

S>> Огромное спасибо за ответ. 2 дня боролся. Но поборол. У меня опыта на С++ мало. Вспоминаю, то что забыл и учу то, что не знал. Но сегодня подключил
F> Молодец.
F> Не многие юзеры начинаю с вики, и в итоге задают глупые вопросы.

Ну в Вики мало чего. Нужно реальный код смотреть. А его не так и много. Но разобрался.
S>> У CEF есть и dev tools. Но вот нужно правильно подключить файлы из CefClient. Разберусь.
S>>Главное сдвинулся с мертвой точки. Еще раз огромное спасибо!
F> devtools открываются просто вызовом метода из CefBrowserHost по моему. Для этого от CefClient ничего не нужно. Из cefclient обязательно перенеси манифест приложения, иначе потом напорешься на всякие неприятные штуки.

Ну я пока на sefSimple эксперементирую.
F> Во всём остальном вроде всё норм, в смысле с моей стороны добавить нечего — дерзай!

F> PS: Потом, когда получится что-то интересное (если это публично доступно), не забудь похвастаться в соответствующим разделе форума по CEF.

Спасибо! А то руки опускаются, что никому это не интересно

Кстати в Proxy можно переопределить new

    let HttpClient= NetWrap.GetType("System.Net.Http.HttpClient","System.Net.Http.dll");
    let HttpClientHandler = await NetWrap.GetType("System.Net.Http.HttpClientHandler","System.Net.Http");

    let client=new HttpClient(HttpClientHandler);

    let url= "https://msdn.microsoft.com/ru-ru/library/hh551745(v=vs.118).aspx");
    let response= await client.async.GetStringAsync(url);
    let response= client.GetStringAsync(url).@Result;

}

Кроме того можно реализовать enumerate для доступа через

for(let prop in list)

То есть код максимально приблизить к C#