Komunikacje miedzy Net and net Framewok

Hobbystycznie pisze projekt w w którym równoczenie uzywa AI i najnowszym mozliwych bibliotek, i antycznego API do stare apliakjci desktopowej. Biblioteki do AI pisane są w NET 8.0 i nie wspieraja NetFramewok, a kolei applikacja desktopowa uzywa NetFramewok, a jest nie kompatybilna z NET. Korzystanie z net standard tez odpada, poniważ netStandard moze być odpalony na obydu platormach ale nie moze odpalać kodu, z NetFramewok i NET naraz.

Nie wiem jak te dwie rzeczy ze soba polaczyć? Instanieje na to metoda biblioteka framework? Napisalem jednego potworka korzystajacego z plików tekstowych, teraz pisze drugiego korzystajacego z consoli, Ale to wszystko jest jak krew w piach. Jak to najlpiej rowziwazac, 'profesjonalnie'

Na jakim poziomie potrzebujesz tej komunikacji? Jak pliki są ok to pewnie restowe api też

a jakim poziomie potrzebujesz tej komunikacji? Jak pliki są ok to pewnie restowe api też

Potrzebuje wywołac kod w jednym i drugi środwisku i wymieć wyniki miedzy nimi. Wywowałnie skomplikowanej funkcji, z minimalnym inputem.
zwrotka DTO.

Rest APi troche over kill ale z drugiej strony brzmi prosto, wystarczy znaleźć jakas stara wersje MVC na net framework, 2 solucje, dto wspólny projekcie dla obu solucji. Przebudowywanie tego byly by upierdliwe ale ogolnie dobry pomysł.

Przepisanie appki desktopowej lub robinie z nia czego kolwiek nie wchodzi w gre, to cud ze dziala.

Jak wiesz że oba projekty będą zawsze odpalane na tym samym kompie to możesz użyć ipc. Mniej roboty niż wystawienie i konsumpcja restowego api i lepsza wydajność.

Noted. Udało mi sie zmusić konsole do dzialania, przy następnej porazce spróbuje i dam znać.

ed. Nie dziala pisze rest API.

@_flamingAccount - a sprawdzałeś memory mapped files?
https://learn.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files

Nie sądzę, że REST API jest najlepszym rozwiązaniem. Jeśli będziesz tym zarządzał technikami devops to może i tak, ale to i tak overkill. Jeśli ma to być aplikacja standalone to główna aplikacja powinna uruchomić drugą aplikacje i dbać o to, żeby proces tej drugiej żył/odpalał ponownie w trakcie krachu. Dalej komunikować się z nią, ale HTTP czy TCP nawet localhost to overkill, więc najlepiej po plikach.... albo - named pipe. No więc trzeba by opracować jakiś protokół client-serwer na named pipe i razem z zarządzaniem procesem podrzędnym ma się sposób komunikacji 2 aplikacji - teraz można przygotować do tego klasę API i gotowe!

Na szczęście MS wpadł na to wcześniej i zaimplementował to za nas. Technologia ta nazywa się COM+ DLL Surogate i w prosty sposób można łączyć aplikacje między różnymi dotnetami, a nawet miedzy różnymi językami czy nawet architekturami (32/64bit) i w eksrremalnych przykładach, nawet maszynami tworząc system rozproszony, napisany jak standalone. Tego ostatniego nie polecam, jednak architektura microserwisów jest lepsza, natomiast do takiego żenienia legacy i nowych rzeczy pasuje jak ulał. Jest to szeroko stosowane, ale diabelnie źle udokumentowane, natomiast da się. Znam wiele takich zastosowań w biznesie dużych korporacji - natomiast zazwyczaj ktoś kogoś tego uczy, lub ktoś uczy się ze skrawków nowych oraz legacy dokumentacji i zachowuje tą wiedzę dla siebie.

W praktyce jak przygotować poprawnie obiekt COM, oraz poprawnie w kodzie zadbać o jego rejestracje w rejestrze windows, i ew. reagowanie jak taki obiekt COM już jest zarejestrowany, to końcowo dla programisty użycie takiego obiektu nie różni się niczym. Tworzy się obiekt, przez new i w momencie wołania jakiejś metody czy property następuje komunikacja po named pipe, ale to jest ukryte dla nas i takie wywołanie nie różni się niczym od wywołania obiektu istniejącego w pamieci głównego procesu.

Jest jeszcze inny sposób, łatwy do zrobienia i możliwy do realizacji w sytuacji, gdy są spełnione warunki:

1. Można wyróżnić aplikację sterującą i sterowaną. W tym przypadku sterującą będzie aplikacja desktopowa w .NET Framework i aplikacja korzystająca z AI w .NET 8.0
2. Każda komunikacja jest z inicjatywy aplikacji sterującej. Znaczy to tyle, że za każdym razem, to aplikacja desktopowa będzie czegoś żądać od tej drugiej i dostanie odpowiedź. Ewentualnie obsłużenie inicjatywy tej drugiej aplikacji jest możliwe, ale komplikuje interpretację odpowiedzi lub wymagałoby częstego odpytywania, np za pomocą timera.

Jeżeli oba warunki są spełnione, to nie ma najmniejszego znaczenia, "w czym" są tworzone aplikacje, a wystarczy zrobić to następująco:

1. Aplikacja sterowana, czyli aplikacja obsługująca API to powinna być aplikacja konsolowa, która w pętli czyta ze standardowego wejścia do naciśnięcia Enter. Po odczytaniu "\n", czyli "Enter" aplikacja wykonuje czynność zależna od tego, jaki tekst wpłynąć do strumienia i sama wypisuje do standardowego wyjścia jakąś informację, zakończoną Enterem, czyli znakiem "\n". W C# będzie to odpowiednio Console.ReadLine i Console.WriteLine;
2. Aplikacja sterująca, czyli aplikacja desktopowa uruchamia aplikację sterowaną z przekierowaniem standardowych strumieni. W C#, to tu https://learn.microsoft.com/pl-pl/dotnet/api/system.diagnostics.process?view=net-8.0 jest opisane, jak to zrobić.
3. Aplikacja sterująca, czyli ta desktopowa w chwili, gdy ma coś dostać lub dać do aplikacji sterowanej, generuje odpowiedni tekst (najlepiej same znaki ASCII od 32 do 126, dane binarne można przekształcić do BASE64). Wygenerowany tekst wypisuje do przekierowanego strumienia wejścia i zaraz potem odczytuje linię tekstu z przekierowanego strumienia wyjścia. Aplkiacja sterująca będzie czekać na odczycie, aż dostanie odpowiedź w aplikacji sterowanej.
4. Teraz pozostaje wymyślić algorytm generujący i odczytujący napisy tak, żeby aplikacje "się rozumiały". Może to być czysty tekst, który łatwo przetworzysz, w wymyślony przez siebie sposób, może to być XML, JSON, cokolwiek. Właściwie to samo, co jakbyś chciał zrobić REST API.

Ogólnie idea z przekierowaniem strumieni jest podobna do REST API i działa na podobnej zasadzie, ale jest zdecydowanie łatwiejsza do zrobienia w przypadku dwóch niezależnych aplikacji na tym samym komputerze.

Zabrałem sie zaproblem jeszcze raz. Okazuje sie że tworzenie COM jest 100 razy prostsze niz mówią w tutorialach. Calośc sprowadza sie do Odpalenie Visual studio jako admin, zmieniania flagi w AssemblyInfo z true na false, przestawieniem jednego checkboxa w zakładce build oraz oznaczenia klas które chcemy opublikowac attrubutem com visible. Na koncu dodajemy reference przez add COM.

Jakie kolwiek rest api, systemy plików, applicaje w róznych processach, wszystko to wymieka przy prostocie użycia COM. Wiec na razie jest hura optymistycznie nastawiony.

@_flamingAccount powodzenia. W drugą stronę też się da to ogarnąć ale fakt, jest dużo wiedzy plemiennej na forach MS i nie ma jeszcze dopracowanego tutoriala. Niemniej u Ciebie jest w drugą stronę więc tragedii nie będzie. Pamiętaj, jednak, że jedna sprawa to używanie w VS, a druga sprawa to deploy do klienta. Musisz zadbać o poprawną rejestracje componentu przez instalator, administratora lub sam główny program.

Nie jestem też pewien, czy uda się odpalić obiekt z .NET 8.0 w procesie .NET Framework. Z racji, ze tutaj są inne wersje CLR może być konieczne jednak uruchomienie osobnego procesu - niemniej to jest też ukryte przed programistą i też w zależności od sposobu wykonania ogranicza się do specjalnego oznaczenia flagą lub zarejestrowania componentu w inny sposób. Wówczas oznaczona klasa jest powoływana w podległym procesie dllhost.exe. Jest to technologia DLL Surogate i jako taka po konfiguracji jest przezroczysta i programista nie musi się martwić zarządzeniem tym procesem. Ofc. warto być świadomym, że takie procesy potomne powstaną - chociażby polityki bezpieczeństwa na maszynie uruchomieniowej mogą na to nie pozwalać, lub trzeba to przegadać z security/adminami.

U mnie jest bład w disaynie i mam jedna abnominacje komunikajaca sie od NetFramework do chatu GDP. Prawidłowym rozwiazaniem jest przejsc na NET standard wszedzie gdzie sie da. Program startowy mieć w NET a do NetFramework rozmawiać przez COM. To jest ściezka która powinna rozwiaza wszystkie problemy i wyglada na wpierana przez MS.

Nie mam deploy'u i nie bede mieć tego problemu. Ja jestem i bede jedynym klientem.

Gdyby kiedys ktoś sie na tym wzrował lub szkolił AI, to wymaganym jest zeby dll byly typu lib oraz zalinkowane dll tez byly lib. Applicakcje konsowlowe nie wczytuja sie w runtime.
I przebudowanie jest tragiczne bo wymaga wolania rebuild recznie.