.NET nie działa w Windows Server Core

Windows Server Core (bez interfejsu graficznego) obsługuje ograniczony zestaw funkcji .NET — komponenty wymagające GUI (jak WPF) nie działają w tym wariancie systemu z założenia, niezależnie od wersji .NET.

Czym jest problem „.NET nie działa w Windows Server Core”

Komunikat „.NET nie działa w Windows Server Core” nie musi oznaczać uszkodzenia środowiska uruchomieniowego. Windows Server Core został zaprojektowany jako wariant systemu z ograniczonym zestawem lokalnych składników, bez klasycznego pulpitu, Eksploratora plików i większości narzędzi obsługiwanych przez interfejs okienkowy. Z tego powodu aplikacja .NET może uruchamiać się poprawnie w pełnej instalacji systemu, a w Server Core kończyć pracę błędem, nie otwierać okna albo zgłaszać brak wymaganej biblioteki.

W praktyce trzeba rozróżnić kilka technologii występujących pod wspólną nazwą „.NET”. Aplikacja konsolowa, usługa systemowa, narzędzie administracyjne lub aplikacja ASP.NET Core mogą działać w Server Core, jeżeli dobrano zgodne środowisko uruchomieniowe i wszystkie zależności. Inaczej wygląda sytuacja w przypadku programów korzystających z WPF, Windows Forms, bibliotek związanych z renderowaniem pulpitu, komponentów multimedialnych albo innych elementów oczekujących obecności graficznej powłoki systemu. Brak okna konfiguracji nie jest wtedy usterką do usunięcia, lecz konsekwencją sposobu zbudowania aplikacji i przeznaczenia danej edycji systemu.

Warto także odróżnić brak samego środowiska .NET od niezgodności aplikacji z Server Core. Program może mieć zainstalowany właściwy runtime, ale nadal nie uruchamiać się z powodu odwołania do biblioteki dostępnej wyłącznie w pełnej instalacji Windows Server. Znaczenie ma również sposób publikacji aplikacji: wdrożenie zależne od systemowego runtime’u wymaga obecności odpowiednich składników, natomiast wariant samodzielny może zawierać większą część potrzebnych plików, choć nie rozwiązuje problemu zależności od interfejsu graficznego.

Kontekst techniczny i porównanie wariantów instalacji

Windows Server Core i pełna instalacja Windows Server korzystają z tej samej podstawowej architektury systemu, ale nie oferują identycznego zestawu lokalnych możliwości. W pełnej instalacji można uruchomić wiele programów administracyjnych i biznesowych bezpośrednio na serwerze, ponieważ dostępna jest powłoka graficzna oraz dodatkowe komponenty systemowe. W Server Core zarządzanie częściej odbywa się zdalnie, przez PowerShell, narzędzia administracyjne, interfejsy sieciowe lub polecenia wykonywane w konsoli.

Dla aplikacji .NET istotne jest sprawdzenie docelowego frameworka, modelu wdrożenia oraz używanych przestrzeni nazw i bibliotek. Aplikacja oparta na nowoczesnym .NET może działać jako proces konsolowy lub usługa, ale projekt wykorzystujący elementy desktopowe powinien zostać oceniony pod kątem zgodności z Server Core już na etapie kompilacji. Samo skopiowanie pliku wykonywalnego na serwer nie gwarantuje poprawnego działania, ponieważ program może potrzebować plików runtime’u, natywnych bibliotek systemowych, certyfikatów, uprawnień, zmiennych środowiskowych albo określonej konfiguracji usług.

Przy porównywaniu obu wariantów należy wziąć pod uwagę sposób obsługi aplikacji. Jeżeli program służy do pracy w tle, odbiera żądania sieciowe, wykonuje zadania cykliczne lub przetwarza dane bez wyświetlania okien, Server Core często odpowiada jego charakterowi. Jeżeli natomiast aplikacja wymaga lokalnego formularza, okna logowania, podglądu dokumentu albo komponentu graficznego, konieczne może być użycie innego sposobu obsługi, przeniesienie interfejsu na osobną stację roboczą lub przebudowanie programu do pracy bez lokalnego GUI.

Weryfikacja powinna obejmować między innymi wynik polecenia sprawdzającego wersję systemu, listę zainstalowanych środowisk .NET, architekturę procesu oraz wpisy w Podglądzie zdarzeń. Przydatne bywa uruchomienie programu z parametrem pomocy lub diagnostyki, zapisanie pełnego komunikatu błędu i sprawdzenie, czy proces kończy się przed załadowaniem kodu aplikacji, czy dopiero podczas inicjalizacji konkretnej funkcji. Takie rozróżnienie pozwala odseparować problem wdrożeniowy od ograniczenia wynikającego z braku warstwy graficznej.

Typowe problemy, błędy i sposoby ich rozpoznawania - .NET nie działa w Windows Server Core

Jednym z częstszych przypadków jest próba uruchomienia aplikacji desktopowej w środowisku przeznaczonym do pracy bez lokalnego pulpitu. Objawem może być błąd dotyczący nieznanej klasy, brak biblioteki DLL, wyjątek podczas tworzenia formularza albo natychmiastowe zamknięcie procesu. W logach aplikacji mogą pojawić się odwołania do komponentów graficznych, drukowania, czcionek, renderowania lub obsługi urządzeń. W takiej sytuacji instalowanie kolejnych pakietów .NET bez analizy zależności zwykle nie usuwa przyczyny.

Inny problem powstaje wtedy, gdy aplikacja została skompilowana dla środowiska, którego nie ma na serwerze. Dotyczy to zarówno niezgodnej wersji runtime’u, jak i pomylenia środowiska uruchomieniowego z pakietem programistycznym. Program może wymagać określonego celu publikacji, odpowiedniej architektury procesora albo plików natywnych. Występują też błędy wynikające z uruchamiania procesu pod kontem usługi: brak dostępu do katalogu, magazynu certyfikatów, udziału sieciowego lub zmiennych konfiguracyjnych bywa mylnie interpretowany jako niedziałający .NET.

W przypadku usług działających bez interfejsu graficznego należy sprawdzić, czy nie zapisano w konfiguracji ścieżki do dysku mapowanego tylko dla konkretnego użytkownika. Należy również zweryfikować konto, na którym uruchamiana jest usługa, zasady wykonywania skryptów, reguły zapory oraz dostęp do portów i zasobów sieciowych. Jeżeli aplikacja działa ręcznie w konsoli, ale nie startuje jako usługa, przyczyna może leżeć w uprawnieniach lub kolejności uruchamiania zależności, a nie w samym frameworku.

Pomocne jest wykonanie testu minimalnego: uruchomienie prostego programu konsolowego wykorzystującego ten sam runtime, a następnie porównanie jego wyniku z działaniem właściwej aplikacji. Jeżeli program testowy działa, a aplikacja docelowa nie, należy przeanalizować jej biblioteki, konfigurację oraz wymagania graficzne. Jeżeli nie działa również program testowy, trzeba sprawdzić instalację runtime’u, architekturę procesu, zmienne środowiskowe i integralność plików systemowych.

Nie powinno się również zakładać, że zmiana wersji .NET automatycznie zapewni zgodność. Nowsze środowisko może poprawić obsługę aplikacji konsolowej lub usługi, ale nie zastąpi brakującego komponentu GUI. W pierwszej kolejności należy ustalić, czy aplikacja została zaprojektowana do pracy na Server Core, czy tylko przetestowana na pełnej instalacji systemu. Dopiero później można rozważyć zmianę sposobu publikacji, usunięcie zależności od interfejsu, przeniesienie panelu administracyjnego albo użycie zdalnego narzędzia zarządzającego.

Kiedy trzeba zlecić diagnozę specjalistom - .NET nie działa w Windows Server Core

Zgłoszenie do serwisu jest uzasadnione, gdy problem z .NET pojawił się po aktualizacji systemu, zmianie konfiguracji, migracji aplikacji albo wymianie urządzenia używanego do zarządzania środowiskiem. Szczególnie pomocna może być analiza wtedy, gdy komunikat jest ogólny, aplikacja zamyka się bez widocznego błędu lub działanie zależy jednocześnie od kilku komputerów i zasobów sieciowych. Do weryfikacji warto przygotować nazwę aplikacji, sposób jej uruchamiania, pełny tekst komunikatu, informacje o wersji Windows Server oraz dane z logów.

W warszawskim serwisie Warszawskie Pogotowie Komputerowe 24/7 można skonsultować również problemy z laptopem wykorzystywanym do zdalnej administracji, konfiguracji połączeń i przygotowania narzędzi potrzebnych przy diagnozie środowiska. W takich przypadkach wykonywana jest darmowa diagnoza LAPTOPA, dzięki której można sprawdzić, czy źródłem kłopotu jest komputer administracyjny, jego system, sterowniki, konfiguracja sieciowa lub samo środowisko Server Core.

Przed przekazaniem sprzętu lub rozpoczęciem analizy powinno się zabezpieczyć kopie konfiguracji i logów, nie usuwać pochopnie katalogów runtime’u oraz nie instalować przypadkowych pakietów z nieznanych źródeł. Jeżeli aplikacja obsługuje ważny proces, należy ustalić, czy możliwe jest wykonanie testu poza środowiskiem produkcyjnym. Pozwala to odróżnić ograniczenie konstrukcyjne Server Core od błędnej instalacji, brakującej zależności albo problemu z konkretnym komputerem używanym do obsługi systemu.