Dlaczego zerowy bajtowy plik app.config powoduje bardzo dziwny błąd?
Objętość dla plików został zewnętrznie zmieniony w taki sposób, że otwarty plik nie jest już prawidłowy.
Jest to spowodowane, gdy masz app.config, który jest zero bajtów. Błąd wydaje się pochodzić z systemu Windows - nawet WinDBG nie uruchomi go.
Wiem, że całkowicie nieważne jest zero bajtowe app.config, ale co powoduje ten błąd, skąd się bierze i dlaczego tak się dzieje?
//
// MessageId: ERROR_FILE_INVALID
//
// MessageText:
//
// The volume for a file has been externally altered so that the opened file is no longer valid.
//
#define ERROR_FILE_INVALID 1006L
Skopiowano z pliku nagłówkowego Windows SDK WinError.h. Symboliczny kod błędu w tym przypadku jest oczywiście znacznie bardziej istotny niż tekst komunikatu o błędzie. To nie jest dość niezwykłe. Widzę, że jest on używany wewnątrz kodu źródłowego SSCLI20 (open source of the CLR) w kodzie, który sprawdza, czy plik wykonywalny ma właściwy nagłówek pliku PE32 i nagłówek .NET obecny w zespole zarządzanym. Oczywiście, że nie ma tu zastosowania.
Mimo to, CLR jest zainteresowany plikiem app.exe.config w bardzo wczesnym etapie etapu ładowania. Elementy takie jak <supportedRuntime> muszą zostać przeanalizowane przed uruchomieniem CLR. Oczywiście ten kod nie jest zadowolony z pustego pliku .config. Kod CLR jest taki świetny, nigdy nie robi się tak zwanego "let's potumble in anyway".
Dzięki za informacje! Będę pamiętać, aby spojrzeć na WinError.h na tego typu rzeczy w przyszłości. Zgaduję, że nie byłoby sposobu, aby poradzić sobie z taką sytuacją w zarządzanym kodzie? –
Oczywiście, że jest! Napraw plik. Cóż, nie, nie zarządzany kod. –
Pliki .config są zwykle plikami xml, więc nawet jeśli są puste, na początku potrzebują trochę struktury/podpisu XML. Plik konfiguracyjny, ponieważ jest pusty, nie może być analizowany jako plik XML, więc uważam, że jest to wewnętrzny mechanizm bezpieczeństwa, który uniemożliwia uruchomienie aplikacji, ponieważ żadne narzędzie ani program, który nie zmieniłby pliku .config, spowodowałoby, że ten stan, dlatego MUSI zostać ręcznie zmieniony, co spowoduje nieprawidłowe działanie programu. przynajmniej jest to kolejny krok środka bezpieczeństwa. –