Uruchamianie aplikacji .NET w systemie Linux w 2015 r.

Question

TL; DR: jakie są obecnie opcje uruchamiania rozwiązania VS2015 w systemie Linux?

---

Mam aplikację .NET, która działa poprawnie w systemie Windows i otrzymała żądania przeniesienia jej do systemu Linux. Próbowałem bardzo ciężko zrozumieć, co to oznacza dzisiaj w 2015 roku, ale jestem bardzo zdezorientowany ze wszystkich starych postów wskazujących na Mono i nowych postów mówiących o vNext (i wciąż wspominając o Mono). Mam również dobre doświadczenie z .NET, ale ogólnie nie znam się na Linuksie ...

Śledziłem ostatnio przeprowadzony samouczek i udało mi się skompilować i uruchomić aplikację konsolową Hello World w systemie Linux. Wymagało to instalacji pewnych rzeczy, których nie znam, w tym Mono, a następnie uruchomienia niektórych poleceń "k" (przywracanie kpm, kompilacja kpm, uruchomienie k). Jednak teraz nie wiem, jak przejść do scenariusza mojego prawdziwego świata.

Mam roztwór VS2015, który ma wiele projektów, ale tylko 4 warto wspomnieć tutaj: - CommonStuff - ServiceCore - ServiceWindows/ServiceConsole

cały kod jest w projekcie ServiceCore (Biblioteka klas) , który sam ma odniesienie do CommonStuff (innej biblioteki klasy). ServiceWindows jest projektem usługi systemu Windows, który po prostu wywołuje główną funkcję ServiceCore, a ServiceConsole robi to samo, ale w aplikacji konsolowej (ze względu na debugowanie, ponieważ nie jest możliwe debugowanie projektu usługi Windows z Visual Studio).

Zarówno CommonStuff, jak i ServiceCore zawierają wiele bibliotek .NET, a także niektóre biblioteki dll innych firm. Nie ma jednak specyficznego dla systemu Windows kodu, nie ma w nim ani pinvoke, ani funky.

Jeśli uznamy ServiceConsole za aplikację, którą chcę uruchomić na Linuksie - co muszę zrobić, aby to się stało? Kompilowanie Hello World było jedną rzeczą, ale teraz, z wszystkimi odniesieniami do thoe ... Nie wiem, od czego zacząć. Ponadto, nie mogę nawet mieć kodu do kompilacji w Linuksie (zastrzeżony kod), więc potrzebuję kodu do kompilacji w systemie Windows i skompilowanej biblioteki dll/exe do uruchomienia bezpośrednio w Linuksie - czy to jest coś, co jest możliwe? Widziałem kilka postów mówiących, że Mono może uruchamiać skompilowane aplikacje, ale każdy Mono turorial, który widziałem zaczyna się od kompilacji. Również nie jestem pewien, co to jest vNext. Czytałem rzeczy o możliwości uruchomienia kodu w Linuksie, jeśli jest on przeznaczony dla .net 6 ... ale nie mam pojęcia, jak i co to znaczy.

Byłbym bardzo wdzięczny, gdyby ktoś mógł poświęcić trochę czasu, aby wyjaśnić w kilku szczegółach, jakie opcje są obecnie i czy jest to realistyczne dla profesjonalnej aplikacji lub czy jest to tylko dobre dla Hello Worlds.

Dzięki

EDIT: Ok, więc wydaje się, mogę skompilować mój kod w VS i jakoś go uruchomić w systemie Linux za pomocą Mono - w jaki sposób?

Answer 1

Często pracuję nad złożonymi aplikacjami wieloplatformowymi lub tylko dla systemu Linux, używając Visual Studio 2015 na Windows. Możesz po prostu skompilować go w VS, kopiować do Linuksa i uruchamiać - prawie zawsze to zadziała. Jeśli wykonujesz poważny rozwój, możesz może chcesz skompilować pod mono, aby wykryć niektóre brakujące \ różne podpisy, ale to nie jest wymagane .

Teraz usługę systemu Windows można zmienić na samą aplikację konsoli. Zasadniczo jest to po prostu aplikacja konsolowa zarządzana przez zewnętrzne narzędzie. W systemie Linux istnieją różne narzędzia, które pozwalają zarządzać (uruchom \ stop \ restart w przypadku awarii itd.) W aplikacjach "usługowych".

Dla aplikacji internetowych zwykle używam ServiceStack, który działa na mono bez problemów. Możesz nawet samo-hostować go ponownie jako aplikację konsolową, za Nginx. Możesz także hostować aplikacje asp.net pod apache \ nginx, z niewielkimi zmianami kodu lub bez nich.

Pół roku temu "przeportowałem" duży projekt, który był rozwijany przez 2 lata z serwera Windows na serwer CentOS 7, głównie przez kopiowanie rzeczy do centów i uruchamianie (z niewielkimi zmianami, bez ponownej kompilacji pod mono). Oczywiście ten projekt miał wiele niezależnych zależności, a niektórzy twórcy tych zależności nawet nie wiedzieli, że istnieje mono. Niemniej jednak po prostu zadziałały. I to rozwiązanie miało około 90 projektów VS.

Oczywiście nie każdy skomplikowany projekt jest tak łatwy do przeniesienia, szczególnie jeśli często korzystasz z bibliotek natywnych, ale zazwyczaj tak nie jest. Ponadto, jeśli pracujesz z serwerem sql, pamiętaj, że sterownik serwera sql w mono jest całkiem kiepski z mojego doświadczenia. Używam postgre i unikam serwera sql z mono, jeśli mam wybór. Praca z obrazami w mono nie jest zbyt dobra, nieporęczna i niestabilna. Unikałem za to korzystania z klasy Bitmap za wszelką cenę i zamiast tego wpinałem się w imagemagick C api. Ale musisz zrobić to tylko wtedy, gdy wykonujesz poważne i rozległe obrazowanie, dla podstawowych zadań jest w porządku.

Krótka historia - uruchomienie aplikacji .NET w Linuksie w 2015 roku nie stanowi obecnie problemu.