Показать сообщение отдельно
Старый 28.08.2023, 11:50   #9  
Товарищ ♂uatr is offline
Товарищ ♂uatr
Участник
Аватар для Товарищ ♂uatr
MCBMSS
 
268 / 829 (28) +++++++
Регистрация: 23.10.2012
Привет.
Хотел выбрать простое и стабильное решение. Сложилось впечатление, что Pipe сюда идеально подходит.
Плюсом является нативная возможность его работы в асинхронном режиме.
Есть встроенный EventDrillDownPoller, обертка над PipeServer, который можно было слегка переработать для достижения целевого результата.
Вопрос остается только в отправке трафика (если бы) - для этих целей, по идее, подходит PipeClient.
Соответственно создаём pipeServer, pipeClient - отправляем трафик серверу и...ничего.
Читаем документацию по клиенту и поражаемся тем, насколько MS удалось придерживаться концепций "чистого кода":
https://learn.microsoft.com/en-us/do...-finops-dotnet)
Когда код настолько описывает себя, что даже и документация не нужна.
Самое полезное, что было в документации - имя сборки содержащей данный объект "Microsoft.Dynamics.AX.Xpp.Support.dll" (это помогло совершенно в ином вопросе).
Ну и не нашел ничего похожего в данной библиотеке, поэтому сделал необоснованный вывод, что PipeClient и PipeServer ничто иное как обертка над System.IO.Pipes.NamedPipeClientStream и System.IO.Pipes.NamedPipeServerStream соответственно.
Открываем тоже самое по серверу и видим чуть больше информации:
https://learn.microsoft.com/en-us/do...-finops-dotnet
Ну и получается, что MS ограничили возможность коммуникации на инкапсулированном от программиста уровне инициализации объекта.
Никто не запрещает подключить сборку System.Code.dll и отказаться от использования PipeServer и Client Аксапты в пользу аналогов из .Net и они работают - но речь уже не идёт о простом решении, чистов воды кастомизация.