Zagadnienia dotyczące wersji i aktualizacji dla deweloperów języka C#

Zgodność jest ważnym celem, ponieważ nowe funkcje są dodawane do języka C#. W prawie wszystkich przypadkach istniejący kod można ponownie skompilować przy użyciu nowej wersji kompilatora bez żadnego problemu. Zespół środowiska uruchomieniowego platformy .NET ma również na celu zapewnienie zgodności zaktualizowanych bibliotek. W prawie wszystkich przypadkach, gdy aplikacja jest uruchamiana ze zaktualizowanego środowiska uruchomieniowego ze zaktualizowanymi bibliotekami, zachowanie jest dokładnie takie samo jak w przypadku poprzednich wersji.

Wersja językowa używana do kompilowania aplikacji zwykle pasuje do nazwy docelowej platformy środowiska uruchomieniowego (TFM) przywoływała się w projekcie. Aby uzyskać więcej informacji na temat zmiany domyślnej wersji językowej, zobacz artykuł zatytułowany Konfigurowanie wersji językowej. To domyślne zachowanie zapewnia maksymalną zgodność.

Po wprowadzeniu zmian powodujących niezgodność są one klasyfikowane jako:

• Zmiana powodująca niezgodność binarną: zmiana powodująca niezgodność binarną powoduje różne zachowanie, w tym awarię, w aplikacji lub bibliotece podczas uruchamiania przy użyciu nowego środowiska uruchomieniowego. Aby uwzględnić te zmiany, należy ponownie skompilować aplikację. Istniejący plik binarny nie będzie działać poprawnie.
• Zmiana powodująca niezgodność źródła: zmiana powodująca niezgodność źródła zmienia znaczenie kodu źródłowego. Przed skompilowaniem aplikacji przy użyciu najnowszej wersji językowej należy dokonać edycji kodu źródłowego. Istniejący plik binarny zostanie uruchomiony poprawnie z nowszym hostem i środowiskiem uruchomieniowym. Należy pamiętać, że w przypadku składni języka zmiana powodująca niezgodność źródła jest również zmianą behawioralną, jak zdefiniowano w zmianach powodujących niezgodność w czasie wykonywania.

Gdy zmiana powodująca niezgodność binarna wpływa na aplikację, musisz ponownie skompilować aplikację, ale nie musisz edytować żadnego kodu źródłowego. Gdy zmiana powodująca niezgodność źródła ma wpływ na aplikację, istniejący plik binarny nadal działa poprawnie w środowiskach ze zaktualizowanym środowiskiem uruchomieniowym i bibliotekami. Należy jednak wprowadzić zmiany źródłowe, aby ponownie skompilować nową wersję języka i środowisko uruchomieniowe. Jeśli zmiana jest zarówno powodująca niezgodność źródłową, jak i niezgodność binarną, należy ponownie skompilować aplikację przy użyciu najnowszej wersji i wprowadzić aktualizacje źródłowe.

Ze względu na cel uniknięcia zmian powodujących niezgodność przez zespół ds. języka C# i zespół środowiska uruchomieniowego aktualizowanie aplikacji jest zwykle kwestią aktualizowania serwera TFM i odbudowywania aplikacji. Jednak w przypadku bibliotek, które są dystrybuowane publicznie, należy dokładnie ocenić zasady dla obsługiwanych programów TFM i obsługiwanych wersji językowych. Być może tworzysz nową bibliotekę z funkcjami znajdującymi się w najnowszej wersji i musisz upewnić się, że aplikacje utworzone przy użyciu poprzednich wersji kompilatora mogą jej używać. Możesz też uaktualnić istniejącą bibliotekę, a wielu użytkowników mogło jeszcze nie uaktualnić wersji.

Wprowadzenie zmian powodujących niezgodność w bibliotekach

Podczas wdrażania nowych funkcji językowych w publicznym interfejsie API biblioteki należy ocenić, czy wdrożenie tej funkcji wprowadza zmianę powodującą niezgodność danych binarnych lub źródłowych dla użytkowników biblioteki. Wszelkie zmiany w implementacji wewnętrznej, które nie są wyświetlane w public interfejsach lub protected są zgodne.

Uwaga

Jeśli używasz elementu System.Runtime.CompilerServices.InternalsVisibleToAttribute , aby umożliwić typom wyświetlanie członków wewnętrznych, członkowie wewnętrzni mogą wprowadzać zmiany powodujące niezgodność.

Zmiana powodująca niezgodność binarna wymaga od użytkowników ponownego skompilowania kodu w celu użycia nowej wersji. Rozważmy na przykład tę publiczną metodę:

public double CalculateSquare(double value) => value * value;

W przypadku dodania in modyfikatora do metody jest to zmiana powodująca niezgodność binarną:

public double CalculateSquare(in double value) => value * value;

Użytkownicy muszą ponownie skompilować dowolną aplikację, która używa CalculateSquare metody do poprawnego działania nowej biblioteki.

Zmiana powodująca niezgodność źródła wymaga od użytkowników zmiany kodu przed ponownym skompilem. Rozważmy na przykład ten typ:

public class Person
{
    public string FirstName { get; }
    public string LastName { get; }

    public Person(string firstName, string lastName) => (FirstName, LastName) = (firstName, lastName);

    // other details omitted
}

W nowszej wersji chcesz skorzystać z syntetyzowanych elementów członkowskich wygenerowanych dla record typów. Wprowadź następującą zmianę:

public record class Person(string FirstName, string LastName);

Poprzednia zmiana wymaga zmian dla dowolnego typu pochodzącego z Personklasy . Wszystkie te deklaracje muszą dodać record modyfikator do swoich deklaracji.

Wpływ zmian powodujących niezgodność

Po dodaniu zmiany powodującej niezgodność binarną do biblioteki wymusisz ponowne kompilowania wszystkich projektów, które używają biblioteki. Jednak żaden kod źródłowy w tych projektach nie musi ulec zmianie. W rezultacie wpływ zmiany powodującej niezgodność jest dość mały dla każdego projektu.

Po wprowadzeniu zmiany powodującej niezgodność źródła w bibliotece wymagane jest wprowadzenie zmian w źródle w celu użycia nowej biblioteki. Jeśli konieczna zmiana wymaga nowych funkcji językowych, należy wymusić uaktualnienie tych projektów do tej samej wersji językowej i programu TFM, którego teraz używasz. Potrzebujesz więcej pracy dla użytkowników i prawdopodobnie zmusiłeś ich również do uaktualnienia.

Wpływ wszelkich zmian powodujących niezgodność zależy od liczby projektów, które mają zależność od biblioteki. Jeśli biblioteka jest używana wewnętrznie przez kilka aplikacji, możesz reagować na wszelkie zmiany powodujące niezgodność we wszystkich projektach, których to dotyczy. Jeśli jednak biblioteka jest publicznie pobierana, należy ocenić potencjalny wpływ i rozważyć alternatywy:

• Możesz dodać nowe interfejsy API, które równolegle z istniejącymi interfejsami API.
• Możesz rozważyć równoległe kompilacje dla różnych serwerów TFM.
• Możesz rozważyć użycie wielu elementów docelowych.