Weryfikacja kodu przy użyciu diagramów zależności
Dlaczego warto używać diagramów zależności?
Aby upewnić się, że kod nie powoduje konfliktu z jego projektem, zweryfikuj kod za pomocą diagramów zależności w programie Visual Studio. Może to ułatwić:
Znajdź konflikty między zależnościami w kodzie i zależnościach na diagramie zależności.
Znajdowanie zależności, na które mogły mieć wpływ proponowane zmiany.
Możesz na przykład edytować diagram zależności, aby wyświetlić potencjalne zmiany architektury, a następnie zweryfikować kod, aby zobaczyć zależności, których dotyczy problem.
Refaktoryzację lub migrację kodu do innego projektu.
Znajdowanie kodu lub zależności, które wymagają pracy przy przenoszeniu kodu do innej architektury.
Wymagania
Visual Studio
Aby utworzyć diagram zależności dla projektu platformy .NET Core, musisz mieć program Visual Studio 2019 w wersji 16.2 lub nowszej.
Rozwiązanie, które ma projekt modelowania z diagramem zależności. Ten diagram zależności musi być połączony z artefaktami w projektach języka C# lub Visual Basic, które chcesz zweryfikować. Zobacz Tworzenie diagramów zależności na podstawie kodu.
Aby sprawdzić, które wersje programu Visual Studio obsługują tę funkcję, zobacz Obsługa wersji dla narzędzi do architektury i modelowania.
Kod można zweryfikować ręcznie z otwartego diagramu zależności w programie Visual Studio lub w wierszu polecenia. Kod można również zweryfikować automatycznie podczas uruchamiania kompilacji lokalnych lub kompilacji usługi Azure Pipelines.
Ważne
Jeśli chcesz uruchomić walidację warstwy przy użyciu serwera Team Foundation Server (TFS), musisz również zainstalować tę samą wersję programu Visual Studio na serwerze kompilacji.
Walidacja zależności na żywo
Walidacja zależności odbywa się w czasie rzeczywistym, a błędy są wyświetlane natychmiast na liście błędów.
Walidacja na żywo jest obsługiwana w językach C# i Visual Basic.
Aby włączyć pełną analizę rozwiązania podczas korzystania z walidacji zależności na żywo, otwórz ustawienia opcji na złotym pasku, który zostanie wyświetlony na liście błędów.
- Jeśli nie chcesz widzieć wszystkich problemów z architekturą w rozwiązaniu, możesz trwale odrzucić pasek złota.
- Jeśli nie włączysz pełnej analizy rozwiązania, analiza jest wykonywana tylko dla edytowanych plików.
Podczas uaktualniania projektów w celu włączenia walidacji na żywo okno dialogowe pokazuje postęp konwersji.
Podczas aktualizowania projektu do weryfikacji zależności na żywo wersja pakietu NuGet jest uaktualniana tak samo dla wszystkich projektów i jest najwyższą wersją w użyciu.
Dodanie nowego projektu weryfikacji zależności wyzwala aktualizację projektu.
Sprawdzenie, czy element obsługuje walidację
Warstwy można łączyć z witrynami internetowymi, dokumentami pakietu Office, plikami zwykłego tekstu i plikami w projektach udostępnianych w wielu aplikacjach, ale proces weryfikacji nie będzie ich uwzględniać. Błędy walidacji nie będą widoczne w przypadku odwołań do projektów lub zestawów połączonych z oddzielnymi warstwami, jeżeli między tymi warstwami nie ma żadnych zależności. Odwołania te nie są uważane za zależności, chyba że w kodzie wykorzystano te odwołania.
Na diagramie zależności wybierz co najmniej jedną warstwę, kliknij prawym przyciskiem myszy wybór, a następnie kliknij polecenie Wyświetl łącza.
W Eksploratorze warstw przyjrzyj się kolumnie Obsługuje walidację . Jeśli wartością jest false, element nie obsługuje walidacji.
Uwzględnienia innych projektów i zestawów .NET w walidacji
Podczas przeciągania elementów do diagramu zależności odwołania do odpowiednich zestawów lub projektów platformy .NET są automatycznie dodawane do folderu Odwołania do warstwy w projekcie modelowania. Folder ten zawiera odwołania do zestawów i projektów, które są analizowane podczas walidacji. Można dołączyć inne zestawy i projekty .NET do weryfikacji bez ręcznego przeciągania ich do diagramu zależności.
W Eksplorator rozwiązań kliknij prawym przyciskiem myszy projekt modelowania lub folder Odwołania do warstwy, a następnie kliknij polecenie Dodaj odwołanie.
W oknie dialogowym Dodawanie odwołania wybierz zestawy lub projekty, a następnie kliknij przycisk OK.
Ręczna walidacja kodu
Jeśli masz otwarty diagram zależności połączony z elementami rozwiązania, możesz uruchomić polecenie Weryfikuj skrót z diagramu. Możesz również użyć wiersza polecenia, aby uruchomić polecenie msbuild z właściwością niestandardową /p:ValidateArchitecture ustawioną na true. Na przykład, po wprowadzeniu dowolnych zmian w kodzie należy regularnie wykonywać walidację warstwy tak, aby można było wcześnie wychwycić konflikty zależności.
Weryfikowanie kodu z otwartego diagramu zależności
Kliknij prawym przyciskiem myszy powierzchnię diagramu, a następnie kliknij pozycję Weryfikuj architekturę.
Uwaga
Domyślnie właściwość Akcja kompilacji na pliku diagramu zależności (.layerdiagram) jest ustawiona na Wartość Weryfikuj , aby diagram został uwzględniony w procesie walidacji.
Okno Lista błędów zgłasza wszelkie błędy, które występują. Aby uzyskać więcej informacji na temat błędów walidacji, zobacz Rozwiązywanie problemów z walidacją warstwy.
Aby wyświetlić źródło każdego błędu, kliknij dwukrotnie błąd w oknie Lista błędów.
Uwaga
Program Visual Studio może wyświetlać mapę kodu zamiast źródła błędu. Dzieje się tak, gdy kod ma zależność od zestawu, który nie jest określony przez diagram zależności, lub kod nie ma zależności określonej przez diagram zależności. Przejrzyj mapę kodu lub kod, aby określić, czy zależność powinna istnieć. Aby uzyskać więcej informacji na temat map kodu, zobacz Mapowania zależności między rozwiązaniami.
Aby zarządzać błędami, zobacz Rozwiązywanie błędów walidacji warstwy.
Weryfikowanie kodu w wierszu polecenia
Otwórz wiersz polecenia programu Visual Studio.
Wybierz jedną z następujących pozycji:
Aby zweryfikować kod względem określonego projektu modelowania w rozwiązaniu, uruchom program MSBuild z następującą właściwością niestandardową.
msbuild <FilePath+ModelProjectFileName>.modelproj /p:ValidateArchitecture=true— lub —
Przejdź do folderu zawierającego plik projektu modelowania (.modelproj) i diagram zależności, a następnie uruchom program MSBuild z następującą właściwością niestandardową:
msbuild /p:ValidateArchitecture=trueAby zweryfikować kod we wszystkich projektach modelowania w rozwiązaniu, uruchom program MSBuild z następującą właściwością niestandardową:
msbuild <FilePath+SolutionName>.sln /p:ValidateArchitecture=true— lub —
Przejdź do folderu rozwiązania, który musi zawierać projekt modelowania zawierający diagram zależności, a następnie uruchom program MSBuild z następującą właściwością niestandardową:
msbuild /p:ValidateArchitecture=trueZostaną wyświetlone wszystkie błędy. Aby uzyskać więcej informacji na temat programu MSBuild, zobacz MSBuild i MSBuild Task.
Aby uzyskać więcej informacji na temat błędów walidacji, zobacz Rozwiązywanie problemów z walidacją warstwy.
Zarządzanie błędami walidacji
Podczas procesu projektowania możesz pominąć niektóre konflikty zgłoszone podczas walidacji. Na przykład możesz pominąć błędy, które są już poprawiane lub które nie są istotne w konkretnym scenariuszu. W przypadku pomijania błędu dobrym rozwiązaniem jest zarejestrowanie elementu roboczego w programie Team Foundation.
Ostrzeżenie
Aby utworzyć element roboczy lub utworzyć łącze do elementu roboczego, musisz już nawiązać połączenie z kontrolą kodu źródłowego (SCC) serwera TFS. Jeśli spróbujesz otworzyć połączenie z innym serwerem TFS SCC, program Visual Studio automatycznie zamknie bieżące rozwiązanie. Przed podjęciem próby utworzenia lub połączenia z elementem roboczym upewnij się, że masz już połączenie z odpowiednim SCC. W kolejnych wersjach programu Visual Studio polecenia menu nie są dostępne, jeśli nie masz połączenia z SCC.
Tworzenie elementu roboczego dla błędu weryfikacji
- W oknie Lista błędów kliknij prawym przyciskiem myszy błąd, wskaż polecenie Utwórz element roboczy, a następnie kliknij typ elementu roboczego, który chcesz utworzyć.
Te zadania umożliwiają zarządzanie błędami walidacji w oknie Lista błędów:
| Do | Wykonaj te kroki |
|---|---|
| Pomijanie wybranych błędów podczas walidacji | Kliknij prawym przyciskiem myszy jeden lub wiele wybranych błędów, wskaż polecenie Zarządzaj błędami walidacji, a następnie kliknij pozycję Pomiń błędy. Pominięte błędy są wyświetlane jako przekreślone. Przy następnym uruchomieniu walidacji te błędy nie pojawią się. Pominięte błędy są śledzone w pliku .suppressions dla odpowiedniego pliku diagramu zależności. |
| Zaprzestanie pomijania wybranych błędów | Kliknij prawym przyciskiem myszy wybrany pominięty błąd lub błędy, wskaż polecenie Zarządzaj błędami walidacji, a następnie kliknij polecenie Zatrzymaj pomijanie błędów. Wybrane pominięte błędy pojawią się przy następnym uruchomieniu walidacji. |
| Przywróć wszystkie pominięte błędy w oknie Lista błędów | Kliknij prawym przyciskiem myszy w dowolnym miejscu w oknie Lista błędów, wskaż polecenie Zarządzaj błędami walidacji, a następnie kliknij polecenie Pokaż wszystkie pominięte błędy. |
| Ukryj wszystkie pominięte błędy w oknie Lista błędów | Kliknij prawym przyciskiem myszy w dowolnym miejscu w oknie Lista błędów, wskaż polecenie Zarządzaj błędami walidacji, a następnie kliknij polecenie Ukryj wszystkie pominięte błędy. |
Automatyczna walidacja kodu
Walidację warstwy możesz wykonać przy każdym uruchomieniu lokalnej kompilacji. Jeśli twój zespół korzysta z usługi Azure DevOps, możesz przeprowadzić walidację warstwy przy użyciu zaewidencjonowanych bramek, które można określić, tworząc niestandardowe zadanie MSBuild, i użyć raportów kompilacji do zbierania błędów walidacji. Aby utworzyć kompilacje zaewidencjonowane za pomocą bramki, zobacz Ewidencjonowanie bramki TFVC.
Aby walidować kod automatycznie podczas lokalnej kompilacji
Użyj edytora tekstów, aby otworzyć plik projektu modelowania (.modelproj), a następnie dołącz następującą właściwość:
<ValidateArchitecture>true</ValidateArchitecture>
- lub -
W Eksplorator rozwiązań kliknij prawym przyciskiem myszy projekt modelowania zawierający diagram zależności lub diagramy, a następnie kliknij polecenie Właściwości.
W oknie Właściwości ustaw właściwość Validate Architecture projektu modelowania na true.
Dotyczy to projektów modelowania w trakcie procesu walidacji.
W Eksplorator rozwiązań kliknij plik diagramu zależności (.layerdiagram), którego chcesz użyć do weryfikacji.
W oknie Właściwości upewnij się, że właściwość Akcja kompilacji diagramu jest ustawiona na Wartość Weryfikuj.
Obejmuje to diagram zależności w procesie walidacji.
Aby zarządzać błędami w oknie Lista błędów, zobacz Rozwiązywanie błędów walidacji warstwy.
Rozwiązywanie problemów związanych z walidacją warstwy
W poniższej tabeli opisano problemy związane z walidacją warstwy i ich rozwiązania. Problemy te różnią się od błędów, które wynikają z konfliktów między kodem i projektem. Aby uzyskać więcej informacji na temat tych błędów, zobacz Rozwiązywanie problemów z walidacją warstwy.
| Problem | Możliwa przyczyna | Rozwiązanie |
|---|---|---|
| Błędy walidacji nie występują w oczekiwany sposób. | Walidacja nie działa na diagramach zależności, które są kopiowane z innych diagramów zależności w Eksplorator rozwiązań i które znajdują się w tym samym projekcie modelowania. diagramy zależności, które są kopiowane w ten sposób, zawierają te same odwołania co oryginalny diagram zależności. | Dodaj nowy diagram zależności do projektu modelowania. Skopiuj elementy z diagramu zależności źródłowej do nowego diagramu. |
Usuwanie błędów walidacji warstwy
Podczas sprawdzania poprawności kodu na diagramie zależności występują błędy walidacji, gdy kod powoduje konflikt z projektem. Na przykład następujące warunki mogą powodować występowanie błędów walidacji:
Artefakt jest przypisany do niewłaściwej warstwy. W takim przypadku przenieś artefakt.
Artefakt, taki jak klasa, używa innej klasy w sposób, który powoduje konflikt z architekturą. W tym przypadku zrefaktoryzuj kod, aby usunąć zależność.
Aby rozwiązać te błędy, aktualizuj kod, dopóki nie przestaną pojawiać się błędy podczas walidacji. Zadanie to możesz wykonać w sposób iteracyjny.
W poniższej sekcji opisano składnię, która jest używana w tych błędach, wyjaśniono znaczenie tych błędów i zasugerowano, co można zrobić, aby je rozwiązać lub zarządzać nimi.
| Składnia | Opis |
|---|---|
| ArtifactN(ArtifactTypeN) | ArtifactN to artefakt skojarzony z warstwą na diagramie zależności. ArtifactTypeN jest typem ArtifactN, takim jak klasa lub metoda, na przykład: MySolution.MyProject.MyClass.MyMethod(Metoda) |
| Nazwa przestrzeni nazwN | Nazwa przestrzeni nazw. |
| LayerNameN | Nazwa warstwy na diagramie zależności. |
| Dependencytype | Typ relacji zależności między artifact1 i Artifact2. Na przykład artifact1 ma relację Wywołania z Artifact2. |
| Składnia błędu | Opis błędu |
|---|---|
| DV0001: Nieprawidłowa zależność | Ten problem jest zgłaszany, gdy element kodu (przestrzeń nazw, typ, składowa) mapowany na warstwę odwołuje się do elementu kodu mapowanego na inną warstwę, ale nie ma strzałki zależności między tymi warstwami na diagramie weryfikacji zależności zawierającym te warstwy. Jest to naruszenie ograniczeń zależności. |
| DV1001: Nieprawidłowa nazwa przestrzeni nazw | Ten problem jest zgłaszany dla elementu kodu skojarzonego z warstwą, która właściwość "Dozwolone nazwy przestrzeni nazw" nie zawiera przestrzeni nazw, w której zdefiniowano ten element kodu. Jest to naruszenie ograniczeń nazewnictwa. Należy pamiętać, że składnią "Dozwolone nazwy przestrzeni nazw" jest lista średników przestrzeni nazw, w których można zdefiniować elementy kodu skojarzone z warstwą. |
| DV1002: Zależność od przestrzeni nazw niemożliwych do wnioskowania | Ten problem jest zgłaszany w elemencie kodu skojarzonym z warstwą i odwołuje się do innego elementu kodu zdefiniowanego w przestrzeni nazw zdefiniowanej we właściwości "Nieodwoływalna przestrzeń nazw" warstwy. Jest to naruszenie ograniczeń nazewnictwa. Należy pamiętać, że właściwość "Przestrzenie nazw niemożliwa do wnioskowania" jest zdefiniowana jako rozdzielona średnikami lista przestrzeni nazw, do których nie należy odwoływać się w elementach kodu skojarzonych z tą warstwą. |
| DV1003: Niedozwolona nazwa przestrzeni nazw | Ten problem jest zgłaszany w elemecie kodu skojarzonym z warstwą, która zawiera właściwość "Niedozwolone nazwy przestrzeni nazw" zawiera przestrzeń nazw, w której zdefiniowano ten element kodu. Jest to naruszenie ograniczeń nazewnictwa. Należy pamiętać, że właściwość "Niedozwolona nazwa przestrzeni nazw" jest zdefiniowana jako rozdzielona średnikami lista przestrzeni nazw, w których nie należy definiować elementów kodu skojarzonych z tą warstwą. |
| DV2001: Obecność diagramu warstwowego | Ten problem jest zgłaszany w projekcie, który nie zawiera pliku diagramu zależności, ale odwołuje się do analizatorów weryfikacji zależności. Jeśli weryfikacja zależności nie została użyta, możesz usunąć "Microsoft.DependencyValidation.Analyzers" bezpośrednio z Eksplorator rozwiązań lub pominąć to ostrzeżenie. Aby dodać diagram zależności, zobacz Tworzenie diagramów zależności na podstawie kodu. |
| DV2002: Niezmapowane typy bazowe | Ten problem jest zgłaszany, gdy element kodu nie jest mapowany na żadną warstwę. |
| DV3001: Brak łącza | Nie można odnaleźć linków warstwy "LayerName" do artefaktu. Czy nie brakuje odwołania do zestawu? |
| DV9001: Analiza architektury wykazała błędy wewnętrzne | Wyniki mogą być niepełne. Aby uzyskać więcej informacji, zobacz szczegółowy dziennik zdarzeń kompilacji lub okno danych wyjściowych. |