Problem z app.config i bindingiem assembly

Problem z app.config i bindingiem assembly wskazuje na niezgodność wersji bibliotek .NET wymagającą wpisu redirectowania w pliku konfiguracyjnym aplikacji.

Czym jest problem z app.config i bindingiem assembly

Problem z plikiem app.config i wiązaniem assembly pojawia się wtedy, gdy aplikacja .NET podczas uruchamiania próbuje załadować bibliotekę w wersji innej niż ta, której oczekuje kod albo jeden z jego zależnych komponentów. Sam plik konfiguracyjny nie zawiera biblioteki, lecz może przekazać środowisku uruchomieniowemu informację, jak dopasować żądaną wersję do wersji faktycznie obecnej w katalogu aplikacji, pamięci podręcznej lub środowisku systemowym.

W praktyce stosuje się do tego przekierowanie wersji assembly, czyli binding redirect. Taki wpis może wskazywać zakres starszych wersji oraz jedną wersję docelową, z którą ma zostać powiązane odwołanie. Rozwiązanie działa tylko wtedy, gdy wskazana biblioteka rzeczywiście jest dostępna, ma zgodną tożsamość i nie wymaga innego zestawu zależności. Z tego powodu dopisanie przypadkowego wpisu do konfiguracji nie zawsze usuwa przyczynę problemu.

Znaczenie mają między innymi nazwa assembly, numer wersji, kultura, klucz publiczny oraz sposób, w jaki biblioteka została zbudowana i wdrożona. Istotna bywa również różnica między wersją pliku a wersją assembly zapisaną w jego metadanych. Komunikat o braku pliku nie musi więc oznaczać, że pliku fizycznie nie ma. Może sygnalizować znalezienie niewłaściwej wersji, brak zależnej biblioteki albo niemożność spełnienia warunków określonych przez manifest.

Kontekst techniczny i porównanie sposobów rozwiązywania - Problem z app.config i bindingiem assembly

Wiązanie assembly można porównać do dopasowywania konkretnego wydania modułu do wymagania zapisanego w programie. Bez przekierowania środowisko może oczekiwać dokładnie jednej wersji, natomiast po jego zastosowaniu otrzymuje regułę mówiącą, że określony przedział wersji ma być obsłużony przez wskazane wydanie. Jest to inne podejście niż zwykła podmiana pliku DLL, ponieważ zmiana pliku może wpłynąć na wiele komponentów i nie gwarantuje zgodności interfejsów.

Przy analizie należy odróżnić kilka sytuacji:

• aplikacja odwołuje się do starszej wersji, a wdrożono nowszą wersję zgodną wstecznie;
• w katalogu aplikacji znajduje się biblioteka o tej samej nazwie, lecz z inną tożsamością assembly;
• brakuje biblioteki zależnej, mimo że główny plik DLL jest obecny;
• konfiguracja wskazuje niewłaściwy zakres wersji lub błędny klucz publiczny;
• aplikacja korzysta z innego pliku konfiguracyjnego niż ten, który został zmodyfikowany;
• uruchamiany proces ma odmienne ustawienia środowiska, ścieżki wyszukiwania albo uprawnienia.

W starszych aplikacjach .NET wpisy przekierowujące często umieszcza się w sekcji runtime, wewnątrz assemblyBinding z odpowiednią przestrzenią nazw XML. W nowszych projektach część ustawień może być tworzona lub aktualizowana podczas kompilacji i publikowania. Należy więc sprawdzić nie tylko plik źródłowy projektu, ale również konfigurację znajdującą się obok uruchamianego pliku wykonywalnego. Szczególną uwagę zwraca się na to, czy nazwa pliku końcowego odpowiada nazwie procesu, ponieważ konfiguracja aplikacji bibliotecznej i konfiguracja programu startowego pełnią różne role.

Typowe problemy i błędy przy konfiguracji - Problem z app.config i bindingiem assembly

Jednym z częstszych błędów jest skopiowanie przekierowania dotyczącego innej biblioteki albo użycie wartości z przykładu bez sprawdzenia danych własnego assembly. Wpis może wyglądać poprawnie składniowo, lecz nie zadziałać z powodu różnicy w publicKeyToken, nazwie modułu lub wersji docelowej. Problemy pojawiają się także po aktualizacji pakietu, gdy jedna zależność wymaga nowego wydania, a inna nadal odwołuje się do wcześniejszego interfejsu.

Nieprawidłowości może powodować również zapis konfiguracji. Niewłaściwe zagnieżdżenie elementów XML, brak deklaracji przestrzeni nazw, uszkodzenie kodowania pliku albo pozostawienie kilku sprzecznych reguł może zatrzymać aplikację jeszcze przed wykonaniem właściwego kodu. W takim przypadku komunikat może dotyczyć całego pliku konfiguracyjnego, a nie samego assembly.

Warto sprawdzić log uruchomieniowy oraz pełny tekst wyjątku, ponieważ skrócona informacja wyświetlana użytkownikowi często pomija nazwę poszukiwanej biblioteki i wersję, która została zażądała. Pomocne bywa włączenie rejestrowania prób ładowania assembly, przejrzenie zależności projektu, porównanie zawartości katalogu wdrożeniowego z artefaktami kompilacji oraz ponowne opublikowanie aplikacji do czystej lokalizacji. Nie należy usuwać bibliotek metodą prób i błędów, ponieważ może to zamaskować brak kolejnej zależności.

Osobną przyczyną bywa konflikt między biblioteką umieszczoną w katalogu aplikacji a wersją dostępną w pamięci podręcznej środowiska. Znaczenie może mieć także kolejność wyszukiwania, platforma docelowa, tryb uruchomienia oraz różnica między środowiskiem deweloperskim i komputerem, na którym aplikacja jest używana. Dlatego prawidłowa diagnoza powinna obejmować odtworzenie błędu w konkretnym środowisku, a nie tylko ocenę pojedynczego wiersza w app.config.

Kiedy trzeba zgłosić sprzęt do serwisu - Problem z app.config i bindingiem assembly

Zgłoszenie do serwisu jest uzasadnione, gdy aplikacja przestała się uruchamiać po aktualizacji, instalacji dodatku, przeniesieniu programu na inny komputer albo przywróceniu kopii zapasowej. Pomocy wymaga również sytuacja, w której zmiana app.config daje chwilowy efekt, lecz błąd powraca po ponownym wdrożeniu, aktualizacji systemu lub uruchomieniu programu z innego konta użytkownika.

W ramach sprawdzenia można przeanalizować pełny komunikat wyjątku, zależności plików wykonywalnych, wersje bibliotek, zawartość konfiguracji oraz sposób publikowania aplikacji. Pozwala to rozróżnić brak właściwego przekierowania od uszkodzonej instalacji, niekompletnego wdrożenia albo niezgodności samej biblioteki z kodem programu. Przed rozpoczęciem prac warto przygotować nazwę aplikacji, moment pojawienia się błędu, informację o ostatniej aktualizacji oraz zrzut lub kopię pełnego komunikatu.

W Warszawie takie przypadki można przekazać do Warszawskiego Pogotowia Komputerowego 24/7, gdzie analizuje się konfigurację programu i stan komputera w odniesieniu do konkretnego objawu. Naprawy realizuje się z reguły w ciągu do 3 dni roboczych, zależnie od zakresu diagnostyki i dostępności wymaganych działań. Po usunięciu przyczyny zaleca się ponowne uruchomienie aplikacji, sprawdzenie podstawowych funkcji oraz zachowanie poprawnej konfiguracji jako punktu odniesienia na przyszłość.