.NET Core/.NET 5 - Współdzielenie nieglobalnego runtime

Przymierzamy się do przesiadki całej rodziny aplikacji na .NET 5. Chciałbym uzyskać taki efekt, że aplikacja nawet pod Windowsem nie bazuje na zainstalowanym frameworku, ale też żeby nie trzeba było dystrybuować z każdą aplikacją całego runtime. Chciałbym wskazać miejsce dla tych plików. Czyli nie musieć instalować runtime, ale też nie musieć targać po sieci za każdym razem tych samych plików z każdą aplikacją. Aplikacje te działają jako usługi

Na tą chwilę mam tylko taki pomysł, że będę ustawiać zmienną środowiskową dla aplikacji (pewnie nie da się bezpośrednio, to za pośrednictwem powershell pewnie)

Czy może ktoś tak już kombinował? W internetach jak dotąd nic podobnego nie znalazłem.

A nie możesz zainstalować frameworka po prostu na kompie klienta? Wtedy nie będziesz musiał niczego wrzucać, apka zobaczy zainstalowanego frameworka. Minus - klient może mieć inną wersję niż zakładasz. Np. załozysz sobie 5.0, a on za jakiś czas będzie miał 5.1 albo 5.0.15. Zasadniczo nie powinno być to utrudnieniem.

To że mogę to ja wiem, ale kombinuję czy da się zrobić tak jak opisałem.

Przymierzamy się do przesiadki całej rodziny aplikacji na .NET 5. Chciałbym uzyskać taki efekt, że aplikacja nawet pod Windowsem nie bazuje na zainstalowanym frameworku, ale też żeby nie trzeba było dystrybuować z każdą aplikacją całego runtime. Chciałbym wskazać miejsce dla tych plików. Czyli nie musieć instalować runtime, ale też nie musieć targać po sieci za każdym razem tych samych plików z każdą aplikacją. Aplikacje te działają jako usługi

Napisz aplikacje webowe. Serio.

W przeciwnym razie to takie trochę utrudnianie sobie życia na siłę. Czemu po prostu nie publikować tych aplikacji jako samowystarczalne i właśnie załączać runtime?

Olej to i zajmij się czymś pożytecznym.
Zaraz będziesz miał problem z aktualizacją wszystkich serwisów bo jeden będzie w innej wersji.

Aventus napisał(a):

Napisz aplikacje webowe. Serio.

Ale że co? Nie rozumiem tego zdania.

W przeciwnym razie to takie trochę utrudnianie sobie życia na siłę. Czemu po prostu nie publikować tych aplikacji jako samowystarczalne i właśnie załączać runtime?

Aplikacja bez runtime zajmuje 5MB, a z runtime 190MB. Po co przepychać przez TemaViewera 1GB jak można 25MB? To jest różnica

jacek.placek napisał(a):

Olej to i zajmij się czymś pożytecznym.

To jest bardzo pożyteczne. Można obyć się bez instalacji runtime i nie mieć nadal małych rozmiarów aplikacje. Swoją drogą z .NET Frameworkiem było ciągle tak, że trzeba było działać na wersjach sprzed kilku lat, bo były serwery ze starym bez opcji aktualizacji. Nigdy nie wiadomo było na co się trafi.

Zaraz będziesz miał problem z aktualizacją wszystkich serwisów bo jeden będzie w innej wersji.

Ależ dokładnie przeciwnie. Jak będzie jeden w innej wersji, to wrzucam drugi runtime i nie muszę reszty aktualizować.

Jeśli chodzi o aplikację okienkowe (webforms, wpf) to robisz instalator (np. InnoSetup), w którym zawierasz instalacje odpowiedniego runtime (websetup) i nie musisz niczego "przepychać przez TeamViewera", a twój plik zamiast 25MB ma 26MB.

PS.
Do usług też zadziała.

Widzę, że teoretycznie .NET Core da się zainstalować na serwerze (w przeciwieństwie do .NET Framework). Ale to nieistotne. Nie to jest tematem wątku.

w którym zawierasz instalacje odpowiedniego runtime (websetup)

Nie w chodzi w grę. Często serwery nie mają bezpośredniego dostępu do Internetu.

Nie wiem czy o to chodzi, ale spróbuj:

dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true /p:PublishTrimmed=true /p:IncludeNativeLibrariesForSelfExtract=true

Ja wypróbowałem przed chwilą dwie opcje. Za pierwszym razem z:

/p:PublishTrimmed=true

i za drugim razem bez. Różnica wynikowego exe to 23MB vs 61MB. Test robiłem na .NET 5.

To co nam to da to jednoplikową aplikację z zawartymi natywnymi bibliotekami. Co do PublishTrimmed to jest ciekawa opcja, ale może to powodować problemy.

However, there is a risk that the build time analysis of the application can cause failures at runtime, due to not being able to reliably analyze various problematic code patterns (largely centered on reflection use). Because reliability can't be guaranteed, this deployment model is offered as a preview feature.

Źródło: https://docs.microsoft.com/en-us/dotnet/core/deploying/trim-self-contained

Tak czy inaczej nie o to chodziło.

jacek.placek napisał(a):

Olej to i zajmij się czymś pożytecznym.

To jest bardzo pożyteczne. Można obyć się bez instalacji runtime i nie mieć nadal małych rozmiarów aplikacje. Swoją drogą z .NET Frameworkiem było ciągle tak, że trzeba było działać na wersjach sprzed kilku lat, bo były serwery ze starym bez opcji aktualizacji. Nigdy nie wiadomo było na co się trafi.

Raczej nie jest. Jeśli główną przyczyną jest rozmiar instalatora to możesz zrobić instalator z pełnym framerowkriem a potem instalator tylko ze swoimi dll-kami do updatów. Robisz sobie instalatory z aktualizacjami i jeśli jakaś wersja wymaga innego frameworka to dodajesz go do instalatora.

Zaraz będziesz miał problem z aktualizacją wszystkich serwisów bo jeden będzie w innej wersji.

Ależ dokładnie przeciwnie. Jak będzie jeden w innej wersji, to wrzucam drugi runtime i nie muszę reszty aktualizować.

A potem trzeci runtime, czwarty... A potem zarządzanie który serwis korzysta z którego. Nie wiem czy tak może być w Twoim przypadku ale IMO to strata czasu.

@Sarrus:

Aplikacja bez runtime zajmuje 5MB, a z runtime 190MB. Po co przepychać przez TemaViewera 1GB jak można 25MB? To jest różnica

To zainstaluj albo każ użytkownikowi zainstalować aplikację osobno, a runtime osobno niech sobie z Internetu ściągnie.

Z upływem czasu prawdopodobieństwo że .NET 5 już na komputerze będzie zainstalowany będzie rosło.
Zresztą przy kolejnych wersjach aplikacji zostanie ci tylko 5 MB do zainstalowania.

jacek.placek napisał(a):

Zaraz będziesz miał problem z aktualizacją wszystkich serwisów bo jeden będzie w innej wersji.

Ależ dokładnie przeciwnie. Jak będzie jeden w innej wersji, to wrzucam drugi runtime i nie muszę reszty aktualizować.

A potem trzeci runtime, czwarty... A potem zarządzanie który serwis korzysta z którego. Nie wiem czy tak może być w Twoim przypadku ale IMO to strata czasu.

Z ogarnięciem co z czego korzysta to nie problem.

Azarien napisał(a):

To zainstaluj albo każ użytkownikowi zainstalować aplikację osobno, a runtime osobno niech sobie z Internetu ściągnie.

Gdyby to było takie proste. Nie raz uruchamiamy system jeszcze w trakcie budowy, a wtedy sobie tego użytkownika to możesz szukać. Jasne, że dojdziesz zawsze do odpowiedniej osoby, ale testować trzeba już. I co? Stoisz i rozkładasz ręce.

Strata czasu? Być może, ale mam zrobić rozpoznanie czy się tak da i ew. w jaki sposób. Decyzja jak robimy będzie potem. Nie wiem coście się uczepili, żeby mi pisać rzeczy oczywiste. Ja to wiem, ale mam zrobić research to robię.

Sarrus napisał(a):

ale testować trzeba już. I co?

I chcesz testować jakąś zupełnie nie supportowaną konfigurację, która może się zachowywać inaczej niż „legitna”.

Jeżeli nikt nie ma pomysłu jak to zrobić to proszę o ograniczenie wypowiedzi pt. "a po co ci to?". Wiem, że zainstalowanego środowiska, albo self-contained to ja mogę użyć zawsze i bezproblemowo. Cała ta dyskusja stała się bezprzedmiotowa. Znudziło mnie już udowadnianie, że nie jestem wielbłądem. Ja zdaję sobie sprawę z wad takiego rozwiązania, ale mimo tego zamierzam sprawdzić czy i jak coś takiego osiągnąć.

Jeżeli uda mi się to zrobić, to napiszę tu jak.

EDIT:
Odnoszę wrażenie, że jakieś negatywne fluidy zaczęły się unosić, więc chciałbym zaznaczyć, nie mam tutaj do nikogo żalu. Dziękuję za zainteresowanie tematem i poświęcony czas.

Mozesz sobie wrzucić runtime w danej wersji na klienta wyłącznie raz, zapisać jego miejsce w jakiś zmiennej środowiskowej i przy instalacji pobierać do docelowej lokalizacji albo robić to w inny sposób.

Tak czy inaczej musisz to zrobić przynajmniej raz, przy każdej innej instalacji możesz odpalić skrypt który zrobi to automatycznie.

Można załadować Assembly bez blokowania plików przy użyciu metody

Assembly Load(byte[] rawAssembly) 

ale nie jestem pewien czy to zadziała a jeśli to czy w sposób jakiego oczekujesz.

W rzeczy typu współdzielenie bym się nie pchał bo w bliskiej perspektywie wygląda to wygodnie, ale życie często pokazuje że takie optymalizacje mogą mieć daleko idące konsekwencje i wymagać coraz to więcej czasu na obchodzenie wynikłych z nich problemów.

ale nie jestem pewien czy to zadziała a jeśli to czy w sposób jakiego oczekujesz.

Nie ma takiej możliwości, gdyż bez runtime aplikacja w ogóle nie wystartuje.

W rzeczy typu współdzielenie bym się nie pchał (...)

Dziękuję za opinię.

@Sarrus: Każdy Windows ma domyślnie frameworka , więc nie widzę problemu

Czyli twierdzisz, że dajmy na to Windows Server 2012 ma domyślnie .NET 5? Śmiem wątpić :P

Nie, .NET Core nie jest w żadnym windowsie i nie będzie by design. Możesz poszukać wpisu na blogu microsoftu gdzie opisują że brali to pod uwagę, tak jak w przypadku .NET Framework ale że wróciłyby te same problemy które były z frameworkiem i zaprzeczały idei core'a https://devblogs.microsoft.com/dotnet/introducing-net-core/
https://github.com/dotnet/core/issues/4600#issuecomment-725613982

A ten sam problem istniał od wieków w javie i rozwiązanie jest bardzo proste - udostępnić dwie paczki - większą offline z runtimem i mniejszą online / bez runtime'a i pozwolić użytkownikowi zdecydować
https://docs.microsoft.com/en-us/dotnet/core/deploying/

Obiecałem że napiszę, to piszę. A dopiero teraz, bo projekt został zawieszony aż do zeszłego miesiąca.
Po rozpoznaniu tematu w styczniu potwierdziłem to co pisaliście, że takie podejście nawet jeżeli jest możliwe, to nie warto dalej tego drążyć. Nawet jeżeli dałoby się to jakoś zrobić, to w sposób, którego nie przewidzieli twórcy. Daje to sporo miejsca na problemy w przyszłości. Tak więc framework będziemy instalować, a w razie kłopotów będziemy konfigurować build z self-contained.