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 platformy .NET, a na odwrót!

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ść rombu istnieje teraz na wykresie 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 rombu jest łatwo rozpoznawana; mogą jednak w pewnych okolicznościach tworzyć problemy:

• Konflikt odwołań pakietów NuGet uniemożliwia rozwiązywanie problemów z wersją podczas przywracania pakietu.
• Zmiany powodujące niezgodność między wersjami powodują błędy i wyjątki w czasie wykonywania.
• Zestaw pakietu ma silną nazwę, zmieniono wersję zestawu, a aplikacja jest uruchomiona 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 zmniejszenia prawdopodobieństwa zerwania zależności rombu biblioteki jest zminimalizowanie liczby pakietów, od których zależy.

✔️ Przejrzyj bibliotekę platformy .NET, aby uzyskać niepotrzebne 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ę w przypadku korzystania z najwyższej dostępnej wersji, ponieważ najniższe będą miały najmniejsze problemy ze zgodnością.

Ze względu na najniższą odpowiednią regułę wersji pakietu NuGet nie jest konieczne umieszczenie górnej wersji ani dokładnego zakresu odwołań do pakietu, aby uniknąć pobierania najnowszej wersji. NuGet próbuje już znaleźć najniższą, najbardziej zgodną wersję.

<!-- 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ż zmiany powodujące niezgodność mogły zostać wprowadzone w wersji 2.0, zależność ścisłej lub górnej limitu gwarantuje błąd.

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

❌ UNIKAJ odwołań 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 Przechowywanie wersji 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. Udostępniony pakiet źródłowy zawiera pliki kodu źródłowego zawarte w projekcie podczas odwołwania się. 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 do nich odwoływać się tylko przez PackageReferenceprogram , więc starsze packages.config projekty 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 pakiety źródłowe współużytkowanych najlepiej współużytkować funkcje 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 pakietu udostępnionego pakietu źródłowego, jeśli udostępnia on małe, wewnętrzne elementy funkcjonalności.

✔️ Dokumentacja udostępnionych pakietów źródłowych do polecenia 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 mają 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. Typy w udostępnionych pakietach źródłowych powinny mieć internal widoczność.

❌ NIE publikuj udostępnionych pakietów źródłowych w celu 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