Как заставить клиентское приложение .Net Core взаимодействовать со службой .Net Framework с помощью .Net Remoting

У меня есть клиентское приложение .Net Core (3.1), которому необходимо получать данные из приложения / службы .Net Framework (4.6.2). Связь службы .Net Framework была написана с использованием .Net Remoting. Насколько я понял, .Net Core не поддерживает некоторые функции из .Net Framework, в том числе .Net Remoting.

Как мне заставить клиентское приложение .Net Core получать данные из приложения .Net Framework? Невозможно изменить службу .Net Framework на .Net Core из-за некоторых ограничений по времени и опыту работы с этой службой.

Я думаю о создании еще одного библиотечного проекта, ориентированного на .Net Standard 2.0. На эту библиотеку будет ссылаться клиентское приложение .Net Core. Стандартная библиотека .Net по-прежнему будет использовать интерфейс .Net Remoting для связи с устаревшей службой. Это сработает?

Еще один тупой вопрос, как будет происходить настройка удаленного взаимодействия? Поскольку это библиотека, я не могу разместить в ней файл .config. Файл .config должен находиться в клиентском проекте. Но в клиентском проекте нет файла .config (в нем есть только appsettings.json и launchsettings.json). Я просто создаю / добавляю файл project.config? или есть эквивалентная структура .json?


c# .net-core .net-standard .net-framework-version .net-remoting
person chary    schedule 18.03.2020    source источник
comment
Вы обновляете приложение .Net Framework, чтобы использовать что-то более современное WCF / WebAPI / gRPC вместе с .Net Remoting. gRPC, вероятно, будет наиболее подходящим вариантом, и он поддерживается в .Net Framework начиная с версии 4.5.   -  person phuzi    schedule 18.03.2020
comment
SignalR также очень полезен для этого   -  person vasily.sib    schedule 18.03.2020
comment
@ vasily.sib Будет ли .Net Core api-вызов для .Net Framework работать, и наоборот? Допустим, прокси находится в .Net Framework, сможет ли .Net Core использовать интерфейсы API .Net Framework? И наоборот, существующей службе может потребоваться передать данные в приложение .Net Core. Если нет, будет ли SignalR работать с одним и тем же сценарием (отправка событий на разные платформы)?   -  person chary    schedule 18.03.2020
comment
@chary, да, было бы. Причина, по которой вы не можете использовать удаленное взаимодействие .net, заключается в том, что ядро ​​.net не поддерживает его (и это не планируется для реализации в будущем). Удаленное взаимодействие .net - практически мертвая технология (впрочем, как и WCF)   -  person vasily.sib    schedule 20.03.2020
comment
@chary Как вы в итоге решили свою проблему? Я столкнулся с тем же сценарием.   -  person Anthony Huang    schedule 17.12.2020

Ответы (1)


arrow_upward
1
arrow_downward

Это не сработает. У вас есть основное приложение, работающее в основной среде CLR. Он не может загрузить библиотеку, использующую функциональность, которая зависит от работы в неосновной среде CLR.

Вам нужно изменить язык, на котором говорят между двумя приложениями. Если вы «не можете» изменить существующую службу, возможно, вам нужно написать новое приложение, которое будет действовать как прокси. Он будет работать независимо вместе со службой и общаться удаленно с устаревшим приложением во время разговора, например, HTTP или что-то еще, поддерживаемое основным приложением .NET.

person Damien_The_Unbeliever    schedule 18.03.2020
comment
Будет ли .Net Core api-вызов для .Net Framework работать, и наоборот? Допустим, прокси находится в .Net Framework, сможет ли .Net Core использовать интерфейсы API .Net Framework? И наоборот, существующей службе может потребоваться передать данные в приложение .Net Core. Если нет, будет ли SignalR работать с одним и тем же сценарием (отправка событий на разные платформы)? - person chary; 18.03.2020