Jak zmiany kodu mogą mieć wpływ na zgodność

  • Artykuł

Zgodność odnosi się do możliwości kompilowania lub wykonywania kodu w wersji implementacji platformy .NET innej niż ta, z którą kod został pierwotnie opracowany. Określona zmiana może mieć wpływ na zgodność na sześć różnych sposobów:

Zmiana zachowania

Zmiana zachowania reprezentuje zmianę zachowania członka. Zmiana może być widoczna zewnętrznie (na przykład metoda może zgłosić inny wyjątek) lub może reprezentować zmienioną implementację (na przykład zmianę sposobu obliczania wartości zwracanej, dodawania lub usuwania wywołań metod wewnętrznych, a nawet znacznej poprawy wydajności).

Gdy zmiany zachowania są widoczne zewnętrznie i modyfikują kontrakt publiczny typu, można je łatwo ocenić, ponieważ wpływają one na zgodność binarną. Zmiany implementacji są znacznie trudniejsze do oceny; w zależności od charakteru zmiany oraz częstotliwości i wzorców użycia interfejsu API wpływ zmiany może wahać się od poważnych do nieszkodliwych.

Zgodność binarna

Zgodność binarna odnosi się do możliwości użytkownika interfejsu API do korzystania z interfejsu API w nowszej wersji bez ponownej kompilacji. Zmiany, takie jak dodawanie metod lub dodawanie nowej implementacji interfejsu do typu, nie mają wpływu na zgodność binarną. Jednak usunięcie lub zmodyfikowanie podpisów publicznych zestawu, aby użytkownicy nie mogli już uzyskać dostępu do tego samego interfejsu uwidocznionego przez zestaw, ma wpływ na zgodność binarną. Zmiana tego rodzaju jest określana jako niezgodna zmiana binarna.

Zgodność źródła

Zgodność źródła odnosi się do możliwości ponownego kompilowania istniejących użytkowników interfejsu API względem nowszej wersji bez żadnych zmian w źródle. Niezgodna zmiana źródła występuje, gdy użytkownik musi zmodyfikować kod źródłowy, aby pomyślnie skompilować go pod kątem nowszej wersji interfejsu API.

Zgodność czasu projektowania

Zgodność w czasie projektowania odnosi się do zachowania środowiska czasu projektowania w wersjach programu Visual Studio i innych środowisk czasu projektowania. Chociaż może to obejmować zachowanie lub interfejs użytkownika projektantów, najważniejszym aspektem zgodności w czasie projektowania jest zgodność projektu. Projekt lub rozwiązanie musi być otwierane i używane w nowszej wersji środowiska projektowego.

Zgodność z poprzednimi wersjami

Zgodność z poprzednimi wersjami odnosi się do możliwości działania istniejącego konsumenta interfejsu API względem nowej wersji, zachowując się w ten sam sposób. Zmiany zachowania i zmiany zgodności binarnej mają wpływ na zgodność z poprzednimi wersjami. Jeśli użytkownik nie może uruchomić lub zachowuje się inaczej podczas uruchamiania względem nowszej wersji interfejsu API, interfejs API jest niezgodny z poprzednimi wersjami.

Zmiany wpływające na zgodność z poprzednimi wersjami są odradzane, ponieważ deweloperzy oczekują zgodności z poprzednimi wersjami interfejsu API.

Zgodność z przekazywaniem

Zgodność z usługą Forward odnosi się do możliwości działania istniejącego konsumenta interfejsu API względem starszej wersji przy zachowaniu tego samego zachowania. Jeśli użytkownik nie może uruchomić lub zachowuje się inaczej podczas uruchamiania względem starszej wersji interfejsu API, interfejs API jest niezgodny.

Utrzymywanie zgodności do przodu praktycznie uniemożliwia wszelkie zmiany lub dodatki z wersji na wersję, ponieważ zmiany te uniemożliwiają konsumentowi, który jest przeznaczony dla nowszej wersji uruchomionej w starszej wersji. Deweloperzy oczekują, że użytkownik korzystający z nowszego interfejsu API może nie działać poprawnie względem starszego interfejsu API.

Utrzymywanie zgodności z przekazywaniem nie jest celem platformy .NET Core.