Zależności

Podstawowym sposobem dodawania zależności do biblioteki platformy .NET jest odwołanie się do pakietów NuGet. Odwołania do pakietów NuGet umożliwiają szybkie ponowne użycie i wykorzystanie już napisanych funkcji, ale są one typowym źródłem problemów dla deweloperów platformy .NET. Prawidłowe zarządzanie zależnościami jest ważne, aby zapobiec zmianom w innych bibliotekach .NET przed ich wpływem na Twoją bibliotekę .NET i odwrotnie.

Zależności rombu

Często projekt .NET ma wiele wersji pakietu w drzewie zależności. Na przykład aplikacja zależy od dwóch pakietów NuGet, z których każda zależy od innej wersji tego samego pakietu. Zależność diamentowa istnieje teraz w grafie zależności aplikacji.

W czasie kompilacji narzędzie NuGet analizuje wszystkie pakiety, od których zależy projekt, w tym zależności. W przypadku wykrycia wielu wersji pakietu reguły są oceniane w celu wybrania jednego. Ujednolicanie pakietów jest konieczne, ponieważ uruchamianie równoległych wersji zestawu w tej samej aplikacji jest problematyczne na platformie .NET.

Większość zależności diamentowych jest łatwo rozwiązywana; mogą jednak tworzyć problemy w pewnych okolicznościach.

• Konflikt odwołań do pakietów NuGet uniemożliwia znalezienie wersji podczas przywracania pakietu.
• Zmiany niezgodne między wersjami prowadzą do błędów i wyjątków w czasie wykonywania.
• Zestaw pakietu jest opatrzony silną nazwą, wersja zestawu została zmieniona, a aplikacja działa na platformie .NET Framework. Wymagane są przekierowania powiązań zestawów.

Nie można wiedzieć, jakie pakiety będą używane razem z własnymi. Dobrym sposobem na zmniejszenie prawdopodobieństwa wystąpienia problemu związanego z zależnościami diamentowymi, które mogą uszkodzić bibliotekę, jest zminimalizowanie liczby pakietów, od których twoja biblioteka zależy.

✔️ Dokładnie przejrzyj bibliotekę platformy .NET pod kątem zbędnych zależności.

Zakresy wersji zależności narzędzia NuGet

Odwołanie do pakietu określa zakres dozwolonych prawidłowych pakietów. Zazwyczaj wersja referencyjna pakietu w pliku projektu jest minimalną wersją i nie ma maksymalnej wartości.

<!-- Accepts any version 1.0 and above. -->
<PackageReference Include="ExamplePackage" Version="1.0" />

Reguły używane przez program NuGet podczas rozpoznawania zależności są złożone, ale pakiet NuGet domyślnie wyszukuje najniższą odpowiednią wersję. Pakiet NuGet preferuje najniższą odpowiednią wersję zamiast najwyższej dostępnej, ponieważ najniższa będzie miała najmniejsze problemy ze zgodnością.

Ze względu na zasadę wyboru najniższej wersji przez NuGet, nie ma potrzeby wstawiania górnej wersji lub dokładnego zakresu dla odwołań do pakietów, aby uniknąć pobierania najnowszej wersji. NuGet próbuje już znaleźć najniższą, najbardziej zgodną wersję dla Ciebie.

<!-- Accepts 1.0 up to 1.x, but not 2.0 and higher. -->
<PackageReference Include="ExamplePackage" Version="[1.0,2.0)" />

<!-- Accepts exactly 1.0. -->
<PackageReference Include="ExamplePackage" Version="[1.0]" />

Górne limity wersji spowodują niepowodzenie narzędzia NuGet, jeśli wystąpi konflikt. Na przykład jedna biblioteka akceptuje dokładnie 1.0, podczas gdy inna biblioteka wymaga wersji 2.0 lub nowszej. Chociaż w wersji 2.0 mogły zostać wprowadzone zmiany powodujące niezgodność, zależność od ścisłego lub górnego ograniczenia wersji gwarantuje wystąpienie błędu.

❌ Nie należy zawierać odwołań do pakietu NuGet bez minimalnej wersji.

❌ Unikaj odniesień do pakietów NuGet, które wymagają dokładnej wersji.

❌ UNIKAJ odwołań pakietów NuGet z górnym limitem wersji.

Aby uzyskać więcej informacji, zobacz Wersjonowanie pakietów.

Pakiety źródłowe udostępnione nuGet

Jednym ze sposobów zmniejszenia zewnętrznych zależności pakietów NuGet jest odwołanie do udostępnionych pakietów źródłowych. Pakiet współdzielony zawiera pliki kodu źródłowego, które są dołączane do projektu przy odniesieniu. Ponieważ po prostu dołączasz pliki kodu źródłowego, które są kompilowane z resztą projektu, nie ma zależności zewnętrznej i prawdopodobieństwa konfliktu.

Udostępnione pakiety źródłowe doskonale nadają się do dołączania małych elementów funkcjonalności. Możesz na przykład odwołać się do udostępnionego pakietu źródłowego metod pomocnika do wykonywania wywołań HTTP.

<PackageReference Include="Microsoft.Extensions.Buffers.Testing.Sources" PrivateAssets="All" Version="1.0" />

Udostępnione pakiety źródłowe mają pewne ograniczenia. Można się do nich odwoływać tylko przez PackageReference, więc starsze projekty packages.config są wykluczone. Ponadto udostępnione pakiety źródłowe mogą być używane tylko przez projekty z tym samym językiem. Ze względu na te ograniczenia współdzielone pakiety źródłowe najlepiej służą do dzielenia się funkcjonalnością w projekcie typu open source.

✔️ ROZWAŻ odwołanie do udostępnionych pakietów źródłowych dla małych, wewnętrznych elementów funkcjonalności.

✔️ ROZWAŻ utworzenie udostępnionego pakietu źródłowego, jeśli udostępnia on małe, wewnętrzne elementy funkcjonalności.

✔️ Odwołuj się do udostępnionych pakietów źródłowych przy użyciu PrivateAssets="All".

To ustawienie informuje nuGet, że pakiet ma być używany tylko w czasie programowania i nie powinien być uwidaczniony jako zależność publiczna.

❌ Nie udostępniaj udostępnionych typów pakietów źródłowych w publicznym interfejsie API.

Współużytkowane typy źródłowe są kompilowane w zestawie odwołującym się i nie mogą być wymieniane przez granice zestawów. Na przykład typ udostępnionego źródła IRepository w jednym projekcie jest oddzielnym typem od tego samego źródła IRepository udostępnionego w innym projekcie. W udostępnionych pakietach źródłowych typy powinny mieć widoczność internal.

❌ NIE publikuj udostępnionych pakietów źródłowych na NuGet.org.

Udostępnione pakiety źródłowe zawierają kod źródłowy i mogą być używane tylko przez projekty z tym samym typem języka. Na przykład udostępniony pakiet źródłowy języka C# nie może być używany przez aplikację języka F#.

Opublikuj udostępnione pakiety źródłowe w lokalnym kanale informacyjnym lub w usłudze MyGet , aby korzystać z nich wewnętrznie w projekcie.

PoprzedniNastępny