Обнаружен цикл в графе зависимостей microsoft visual studio component group uwp vc
Опишите архитектуру приложения на высоком уровне, создав схемы зависимостей в Visual Studio. Убедитесь, что код остается согласованным с этим дизайном, проверив код с помощью схемы зависимостей. В процесс сборки также можно включить проверку слоев.
Чтобы узнать, какие выпуски Visual Studio поддерживают эту функцию, см. раздел Поддержка инструментов моделирования и архитектуры в различных выпусках.
Что такое схема зависимостей?
Как и в традиционной схеме архитектуры, схема зависимостей определяет основные компоненты и функциональные единицы проектирования и их взаимозависимости. Каждый узел на схеме, называемый слоем, представляет логическую группу пространств имен, проектов или других артефактов. Можно нарисовать зависимости для своей разработки. В отличие от традиционной схемы архитектуры, можно проверить, соответствуют ли действительные зависимости заданным вами предполагаемым зависимостям. Делая проверку частью стандартного построения в Team Foundation Server, можно добиться того, чтобы программный код продолжал придерживаться архитектуры системы при дальнейших изменениях. См. раздел схемы зависимостей: Справочник.
Разработка и обновление приложений с помощью схем зависимостей
Следующие шаги позволяют получить общие сведения об использовании схем зависимостей в процессе разработки. Каждый шаг более подробно описан в последующих подразделах данного раздела. Если ведется разработка нового проекта, можно пропустить шаги, которые относятся к существующему коду.
Эти шаги приведены в примерном порядке. Возможно, понадобится перекрыть задачи, заново упорядочить их, чтобы они подходили по ситуации, а также возвратиться к ним в начале каждой итерации в проекте.
Создайте схему зависимостей для всего приложения или для слоя внутри него.
Определите слои, представляющие основные функциональные области или компоненты приложения. Дайте этим слоям имена согласно их функциям, например "Презентация" или "Службы". если у вас есть Visual Studio решение, каждый слой можно связать с коллекцией артефактов, такими как проекты, пространства имен, файлы и т. д.
Измените слои и зависимости , чтобы показать обновленный проект, который должен отражаться в коде.
Разрабатывать новые области приложения можно путем создания слоев, представляющих основные архитектурные блоки или компоненты и определяющие зависимости, чтобы продемонстрировать, как каждый из уровней использует другие.
Измените макет и внешний вид диаграммы , чтобы помочь вам обсудить ее с коллегами.
Проверьте код на соответствие схеме зависимостей , чтобы выделить конфликты между кодом и необходимой архитектурой.
Обновите код, чтобы он соответствовал новой архитектуре. Итерационно разрабатывайте и оптимизируйте код до тех пор, пока проверка не укажет, что конфликты отсутствуют.
Включите проверку слоев в процессе сборки , чтобы код продолжал соответствовать вашей структуре.
Создание схемы зависимостей
Схема зависимостей должна быть создана внутри проекта моделирования. Новую диаграмму зависимостей можно добавить в существующий проект моделирования, создать проект моделирования для схемы зависимостей или скопировать существующую диаграмму зависимостей в тот же проект моделирования.
Не добавляйте, не перетаскивайте и не копируйте существующую схему зависимостей из проекта моделирования в другой проект моделирования или в другое расположение в решении. Схема зависимостей, скопированная таким образом, будет иметь те же ссылки, что и исходная диаграмма, даже при изменении схемы. Это может привести к тому, что проверка схемы будет работать неправильно, а также к другим потенциальным проблемам, таким как отсутствующие элементы или другие ошибки при попытке открыть схему.
Определение слоев для представления функциональных областей или компонентов
Рекомендуется называть слои согласно их функциям, например "Презентация" или "Службы". Если артефакты тесно взаимосвязаны, поместите их в один слой. Если артефакты могут быть обновлены отдельно или использованы в разных приложениях, поместите их на разные слои.
Существуют определенные типы артефактов, которые можно связать с слоями, но не поддерживают проверку схемы зависимостей. Чтобы проверить, поддерживает ли артефакт проверку, откройте Обозреватель слоев , чтобы просмотреть свойство Поддержка проверки в ссылке артефакт. См. раздел Обнаружение существующих зависимостей между слоями.
При обновлении незнакомого приложения можно также создать карты кода. Они помогают обнаружить закономерности и зависимости при анализе кода. Воспользуйтесь обозревателем решений, чтобы изучить пространства имен и классы, которые часто находятся в точном соответствии с существующими слоями. Назначьте эти артефакты кода слоям, перетащив их из обозреватель решений в схемы зависимостей. Затем можно использовать схемы зависимостей, которые помогут обновить код и обеспечить его соответствие дизайну.
Обнаружение существующих зависимостей между слоями
Зависимости существуют там, где артефакт, связанный с одним слоем, ссылается на артефакт, связанный с другим слоем. Например, класс в одном слое объявляет переменную, которая имеет класс в другом слое. Существующие зависимости можно обнаружить путем их реконструирования.
Для определенных видов артефактов реконструировать зависимости невозможно. Например, зависимости не могут быть реконструированы из или в слой, связанный с текстовым файлом. Чтобы узнать, какие артефакты имеют зависимости, которые можно реконструировать, щелкните правой кнопкой мыши один или несколько слоев и выберите команду Просмотреть ссылки. В обозревателе слоев изучите столбец поддерживает проверку . Зависимости не будут реконструированы для артефактов, для которых в этом столбце указано значение false.
Чтобы выполнить реконструирование существующих зависимостей между слоями
Выберите один или несколько слоев, щелкните правой кнопкой мыши выбранный слой и выберите команду создать зависимости.
Как правило, на этом этапе можно увидеть некоторые зависимости, которых быть не должно. Эти зависимости можно изменить для соответствия предполагаемой структуре.
Изменение слоев и зависимостей для отображения предполагаемого дизайна
Чтобы описать изменения, которые вы планируете внести в систему или предполагаемую архитектуру, выполните следующие действия, чтобы изменить схему зависимостей. Можно также сделать некоторые оптимизационные изменения для улучшения структуры кода перед его расширением. См. раздел улучшение структуры кода.
Улучшение структуры кода
Оптимизация изменений — это улучшения, которые не влияют на поведение приложения, но помогают сделать код более легким для изменения или расширения в будущем. Хорошо структурированный код имеет конструкцию, легко абстрактную на схеме зависимостей.
Например, если создается слой для каждого пространства имен в коде и затем разбираются зависимости, то необходимо, чтобы был минимальный набор односторонних зависимостей между слоями. Если создается более детальная схема с использованием классов или методов в качестве слоев, то результат должен иметь такие же характеристики.
Если это не так, код будет труднее изменять на протяжении его жизненного цикла и будет менее пригоден для проверки с использованием схем зависимостей.
Разработка новых областей приложения
При начале разработки нового проекта или новой области в новом проекте, можно нарисовать слои и зависимости, чтобы облегчить определение основных компонентов перед началом разработки кода.
По возможности Продемонстрируйте идентифицируемые архитектурные шаблоны на схемах зависимостей. Например, схема зависимостей, описывающая классическое приложение, может включать такие слои, как презентация, логика домена и хранилище данных. Схема зависимостей, охватывающая одну функцию в приложении, может иметь такие слои, как модель, представление и контроллер.
Создайте артефакт кода для каждого слоя , такого как пространство имен, класс или компонент. Это облегчит отслеживание кода и поможет связывать артефакты кода со слоями. Сразу после создания артефакта свяжите его с соответствующим слоем.
Нет необходимости связывать большинство классов и других артефактов с слоями , так как они попадают в более крупные артефакты, такие как пространства имен, которые уже связаны с слоями.
Создайте новую диаграмму для новой функции. Как правило, существует одна или несколько схем зависимости, описывающих все приложение. Если вы разрабатываете новую возможность в приложении, то не добавляйте и не изменяйте существующие схемы. Вместо этого создайте свою схему, которая отражает новые части кода. Слои в новой схеме могут включать в себя презентацию, доменную логику и слои базы данных для новой возможности.
При построении приложения код будет проверяться как в отношении всей схемы , так и в отношении более детальной схемы возможности.
Изменение макета для представления и обсуждения
Чтобы облегчить определение слоев и зависимостей или обсудить их с членами команды, измените вид и разметку схемы следующим образом.
Измените размеры, формы и положение слоев.
Измените цвета слоев и зависимостей.
- Выберите один или несколько слоев или зависимостей, щелкните правой кнопкой мыши и выберите пункт Свойства. В окне Свойства измените свойство Color .
Проверка кода на соответствие схеме
После изменения схемы ее можно проверить на соответствие коду вручную в любое время или автоматически при каждой сборке.
Обновление кода для соответствия новой архитектуре
Как правило, ошибки появляются при первой проверке кода на соответствие обновленной схеме зависимостей. Ошибки могут возникать вследствие нескольких причин.
Артефакт назначен неправильному слою. В этом случае следует переместить артефакт.
Способ использования артефактом (например, классом) другого класса конфликтует с имеющейся архитектурой. В этом случае необходимо выполнить рефакторинг кода, чтобы устранить зависимость.
Для устранения этих ошибок следует обновлять код до тех пор, пока в процессе проверки не перестанут происходить ошибки. Обычно это итерационный процесс. Дополнительные сведения об этих ошибках см. в разделе Проверка кода с помощью схем зависимостей.
При разработке или реструктуризации кода у вас могут быть новые артефакты для связи с диаграммой зависимостей. Однако это может не потребоваться, например, когда слои представляют собой существующие пространства имен, а новый код только добавляет больше материала для них.
В процессе разработки может понадобиться подавить некоторые конфликты, выявленные в ходе проверки. Например, можно подавлять ошибки, над которыми уже ведется работа, а также ошибки, не имеющие отношения к конкретному сценарию. При подавлении ошибки рекомендуется вести журнал рабочего элемента в Team Foundation. Сведения о выполнении этой задачи см. в разделе Проверка кода с помощью схем зависимостей.
Включить проверку слоев в процессе сборки
Чтобы обеспечить соответствие будущих изменений в коде схемам зависимостей, включите проверку слоев в стандартный процесс сборки решения. Каждый раз, когда другие члены команды создают решение, любые различия между зависимостями в коде и схемой зависимостей будут отображаться как ошибки сборки. Дополнительные сведения о включении проверки слоев в процесс сборки см. в разделе Проверка кода с помощью схем зависимостей.
Чтобы убедиться в том, что код не конфликтует с его конструкцией, выполните проверку кода с помощью схем зависимостей в Visual Studio. Это может помочь:
Поиск конфликтов между зависимостями в коде и зависимостями на схеме зависимостей.
Найти зависимости, на которые могут повлиять предложенные изменения.
Например, можно изменить схему зависимостей, чтобы показать потенциальные изменения архитектуры, а затем проверить код, чтобы увидеть затронутые зависимости.
Выполнить рефакторинг или миграцию кода в другую структуру.
Найти код или зависимости, с которыми потребуется выполнить определенные действия даже после перемещения кода в другую архитектуру.
Требования
Чтобы узнать, какие выпуски Visual Studio поддерживают эту функцию, см. раздел Поддержка инструментов моделирования и архитектуры в различных выпусках.
код можно проверить вручную из открытой схемы зависимостей в Visual Studio или из командной строки. вы также можете проверить код автоматически при выполнении локальных сборок или сборок Azure Pipelines.
если вы хотите выполнить проверку слоев с помощью Team Foundation Server (TFS), необходимо также установить на сервере сборки ту же версию Visual Studio.
Динамическая проверка зависимостей
Проверка зависимостей происходит в режиме реального времени, и ошибки отображаются сразу в Список ошибок.
Чтобы включить полный анализ решения при использовании динамической проверки зависимостей, откройте параметры в строке Gold, которая отображается в Список ошибок.
- Вы можете навсегда отклонить строку Gold, если вы не хотите видеть все проблемы архитектуры в решении.
- Если не включить полный анализ решений, анализ выполняется только для редактируемых файлов.
При обновлении проектов для включения динамической проверки в диалоговом окне отображается ход выполнения преобразования.
при обновлении проекта для динамической проверки зависимостей версия пакета NuGet обновляется так же, как и для всех проектов, и является самой высокой используемой версией.
Добавление нового проекта проверки зависимостей активирует обновление проекта.
Определение, поддерживает ли элемент проверку
слои можно связывать с веб-сайтами, Office документами, обычными текстовыми файлами и файлами в проектах, которые являются общими для нескольких приложений, но в процессе проверки их не включаются. Ошибки проверки для ссылок на проекты или сборки, связанные с отдельными слоями, отображаются только в том случае, если между этими слоями отображаются зависимости. Эти ссылки считаются зависимостями, только если используются в коде.
На схеме зависимостей выберите один или несколько слоев, щелкните правой кнопкой мыши выделенный фрагмент и выберите пункт Просмотреть ссылки.
В обозревателе слоев просмотрите столбец поддерживает проверку . Если значение равно false, элемент не поддерживает проверку.
В Обозреватель решений щелкните правой кнопкой мыши проект моделирования или папку ссылки на слой , а затем выберите команду Добавить ссылку.
В диалоговом окне Добавление ссылки выберите сборки или проекты, а затем нажмите кнопку ОК.
Проверка кода вручную
При наличии открытой схемы зависимостей, связанной с элементами решения, можно выполнить команду проверить ярлык на схеме. Можно также использовать командную строку для выполнения команды MSBuild с настраиваемым свойством /p: validatearchitectureonbuild , установленным в значение true. Например, при внесении изменений в код регулярно выполняйте проверку слоев, чтобы заранее обнаруживать конфликты зависимостей.
Проверка кода на основе открытой схемы зависимостей
Щелкните правой кнопкой мыши поверхность схемы и выберите пункт Проверить архитектуру.
По умолчанию свойству действие сборки в файле схемы зависимостей (. LAYERDIAGRAM) присваивается значение Проверка , чтобы схема включалась в процесс проверки.
Окно Список ошибок сообщает о любых произошедших ошибках. Дополнительные сведения об ошибках проверки см. в разделе Устранение неполадок при проверке слоев.
Чтобы просмотреть источник каждой ошибки, дважды щелкните ошибку в окне Список ошибок .
Visual Studio может показывать карту кода вместо источника ошибки. Это происходит, когда либо код имеет зависимость от сборки, которая не указана схемой зависимостей, либо в коде отсутствует зависимость, указанная схемой зависимостей. Просмотрите карту кода или код, чтобы определить, должна ли существовать зависимость. Дополнительные сведения о картах кода см. в статье сопоставление зависимостей в решениях.
Сведения об управлении ошибками см. в разделе разрешение ошибок проверки слоев.
Проверка кода в командной строке
откройте командную строку Visual Studio.
Выберите один из следующих вариантов.
чтобы проверить код для конкретного проекта моделирования в решении, выполните MSBuild со следующим пользовательским свойством.
перейдите в папку, содержащую файл проекта моделирования (modelproj) и схему зависимостей, а затем запустите MSBuild со следующим пользовательским свойством:
чтобы проверить код для всех проектов моделирования в решении, запустите MSBuild со следующим пользовательским свойством:
перейдите к папке решения, которая должна содержать проект моделирования, содержащий схему зависимостей, а затем запустите MSBuild со следующим пользовательским свойством:
Отобразятся любые возникающие ошибки. дополнительные сведения о MSBuild см. в разделе задача MSBuild и MSBuild.
Дополнительные сведения об ошибках проверки см. в разделе Устранение неполадок при проверке слоев.
Управление ошибками проверки
В процессе разработки может понадобиться подавить некоторые конфликты, выявленные в ходе проверки. Например, можно подавлять ошибки, над которыми уже ведется работа, а также ошибки, не имеющие отношения к конкретному сценарию. При подавлении ошибки рекомендуется вести журнал рабочего элемента в Team Foundation.
Вы должны быть уже подключены к управлению исходным кодом (SCC) TFS для создания рабочего элемента или связи с ним. При попытке открыть соединение с другим SCC TFS Visual Studio автоматически закрывает текущее решение. Убедитесь, что вы уже подключены соответствующему SCC, перед попыткой создания рабочего элемента или связи с ним. В последних выпусках Visual Studio команды меню недоступны, если вы не подключены к SCC.
Создание рабочего элемента для ошибки проверки
- В окне Список ошибок щелкните ошибку правой кнопкой мыши, наведите указатель на пункт создать рабочий элемент, а затем выберите тип рабочего элемента, который требуется создать.
Используйте эти задачи для управления ошибками проверки в окне Список ошибок :
Отобразятся подавленные ошибки с форматированием в виде зачеркивания. При выполнении проверки в следующий раз эти ошибки отображаться не будут.
Автоматическая проверка кода
Проверку слоев можно выполнять при каждом выполнении локальной сборки. если ваша команда использует Azure DevOps, можно выполнить проверку слоев с помощью условных возвратов, которые можно указать, создав пользовательскую задачу MSBuild, и использовать отчеты построения для получения ошибок проверки. Сведения о создании сборок с условным возвратом см. в разделе TFVC с проверкой изменений.
Автоматическая проверка кода во время локальной сборки
Откройте файл проекта моделирования (.modelproj) в текстовом редакторе и включите следующее свойство.
В Обозреватель решений щелкните правой кнопкой мыши проект моделирования, содержащий диаграмму зависимостей или диаграммы, и выберите пункт свойства.
В окне Свойства задайте для свойства Проверить архитектуру проекта моделирования значение true.
Это позволяет включить проект моделирования в процесс проверки.
В Обозреватель решений щелкните файл схемы зависимостей (. LAYERDIAGRAM), который вы хотите использовать для проверки.
В окне Свойства убедитесь, что для свойства действие построения схемы задано значение Проверка.
Сюда входит схема зависимостей в процессе проверки.
Сведения об управлении ошибками в окне список ошибок см. в разделе разрешение ошибок проверки слоев.
Устранение неполадок проверки слоев
Следующая таблица описывает проблемы проверки слоев и способы их устранения. Эти проблемы отличаются от ошибок, возникающих из-за несоответствия между кодом и структурой. Дополнительные сведения об этих ошибках см. в разделе Устранение неполадок при проверке слоев.
Разрешение ошибок проверки слоев
При проверке кода на соответствие схеме зависимостей ошибки проверки возникают, когда код конфликтует с конструкцией. Например, ошибки проверки могут происходить по следующим причинам:
Артефакт назначен неправильному слою. В этом случае следует переместить артефакт.
Способ использования артефактом (например, классом) другого класса конфликтует с имеющейся архитектурой. В этом случае необходимо выполнить рефакторинг кода, чтобы устранить зависимость.
Для устранения этих ошибок следует обновлять код до тех пор, пока в процессе проверки не перестанут происходить ошибки. Эту процедуру можно выполнить методом итераций.
В следующем разделе описывается синтаксис, используемый в этих ошибках, объясняется значение этих ошибок и предлагаются пути решения или управления ими.
Артифакттипен — это тип Артифактн, например класс или метод, например:
С помощью VSTS можно автоматизировать развертывание и тестирование программного обеспечения в различных средах. Суть Continuous Integration заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В частности CI позволяет автоматизировать регрессионное тестирование приложений.
В качестве ознакомления с возможностями VSTS предлагаю опубликовать и настроить Continuous Integration c Unit тестами простого UWP приложения.
Создадим простой проект UWP приложения, в котором у нас будет один метод:
В решение добавим проект с unit тестами (Unit Test App). Рекомендуется именовать тестовый проект по конвенции, добавляя в конец Tests. Таким образом проще будет сконфигурировать запуск тестов в VSTS и TFS. Добавим ссылку на основной проект:
Переименуем UnitTest.cs в MainPageTests.cs. Если файл будет так назван, то станет проще понять, что именно тестирует этот класс.
Код метода запускается из UI потока. Не забываем добавить пространство имен
Если при создании проекта мы не добавляли систему контроля версий, то необходимо это сделать сейчас.
Необходимо удалить сертификаты обоих проектов из списка gitignore (иначе сборка VSTS будет неудачной).
Публикуем на VSTS. Переходим в окошко Team Explorer и нажимаем Sync
После публикации мы можем создать Build Definition. Но перед этим нам необходимо сконфигурировать build агента. Дело в том, что для того, чтобы запустить Unit тесты необходимо, чтобы был создан кастомный агент.
По умолчанию существует 3 пула агентов:
Default pool используется для агентов, которые установлены на удаленных серверах.
Hosted pool используется для агентов, которые по умолчанию установлены на серверах VSTS и TFS
Hosted Linux pool позволяет работать с Linux машинами без какой-либо настройки своего агента. Работает в Ubuntu Linux host внутри докер контейнера vsts-agent-docker.
Нажимаем Add. Выбираем только Agent pools (read, manage)
Нажимаем Create token (внизу) и копируем значение, сохраняя его на своем компьютере
Именно в этом окне появится наш агент после того, как мы его создадим, но сейчас пока что в нем пусто.
Нажимаем Download agent.
Вы скачаете архив vsts-agent-win7-x64-2.110.0.zip. Распакуйте его в папку C:\agent (имя и расположение не обязательно должны быть именно такими)
Не обязательно устанавливать агента на ту же самую машину, на которой вы ведете разработку. Его можно установить на любую машину. Теоретически его можно установить и на виртуалку Azure. Обязательное условие — у вас должна быть установлена 64-ех разрядная версия Windows. Для большинства сценариев требуется чтобы на машине была установлена еще и Visual Studio вместе с NuGet.
Запускаем PowerShell и переходим в директорию C:\agent. Конфигурируем. Выполняем командный файл .\config.cmd и отвечаем на запросы. Вводим URL сервера и выбираем тип аутентификации. Для VSTS единственный доступный вариант это PAT (Personal Access Token). Это именно тот самый токен, который мы создали чуть ранее. Далее идет выбор пула и имени агента. Эти значения в моем случае были оставлены по умолчанию.
Последним шагом конфигурации является вопрос о том нужно ли запустить агента как сервис. В случае необходимости тестирования агент запускается вручную, т.е. в качестве сервиса него устанавливать не нужно.
Ремарка: Удалить агента можно с помощью .\config remove При этом необходимо будет ввести токен PAT.
Подробнее о конфигурировании здесь: Deploy an agent on Windows
Теперь давайте создадим Build
Выбираем шаблон именно для универсальной платформы
И настраиваем Continous integration (ставим галочку напротив). Пулом агента выбираем Default
В результате получим такое окно:
Для ускорения билда (если необходимо только удостовериться в том, что тесты проходят) на шаге Build solution можно указать одну платформу – x64. Это рекомендуется делать для CI.
В таком случае меняем строку MSBuild Arguments в настройках билда. Значением AppxBundle устанавливаем Never:
/p:AppxBundlePlatforms="$(BuildPlatform)" /p:AppxPackageDir="$(Build.ArtifactStagingDirectory)\AppxPackages\\" /p:AppxBundle=Never /p:UapAppxPackageBuildMode=StoreUpload
В этой строке $(Build.ArtifactStagingDirectory) – это переменная, которая обозначает путь к папке с артефактами. Если на моей машине агент установлен на диске C в папке agent и если при его конфигурировании я выбрал рабочей папкой директорию с названием _work, то путь к этой папке такой:
C:\agent\_work\1\a
Здесь 1 – это порядковый номер проекта
Список всех переменных можно найти на следующей странице: Use build variables
Если же вы хотите сгенерировать bundle (файл, содержащий пакеты приложения для различных архитектур процессора), то необходимо совершить изменения в настройках проекта. А точнее открыть файлы проектов .csproj и совершить следующие изменения.
В файле проекта юнит теста в конец первого элемента
А в файл проекта приложения добавить:
После этих изменений из строки MSBuild Arguments параметр AppxBundle можно смело удалить вместе с его значением (или поставить значением Auto — /p:AppxBundle=Auto)
Этот вариант подходит для CD.
Так как есть желание тестировать (а в нашем случае оно есть), то необходимо добавить шаг
В окне выбора задачи добавить Visual Studio Test. Указать путь к Test Assembly
В моем случае это:
Другие возможные настройки теста описаны по следующей ссылке: Visual Studio Test
Для unit тестов необходимо чтобы агент был запущен в интерактивном режиме (т.е. с помощью скрипта .\run.cmd).
Кроме того, необходимо чтобы сертификаты приложений (и основного приложения и приложения unit теста) были установлены в хранилище Local Machine — Trusted People (установка возможна простым двойным кликом на *.pfx файл). Устанавливать сертификаты необходимо на той же машине, на которой установлен агент.
Иной раз, при запуске тестов может возникнуть ошибка:
… (0x5B4) Operation timed out. Unable to install Windows app package in 30 sec..
Здесь мы выбираем пакет для какой архитектуры мы будем тестировать и устанавливаем ограничение по времени на установку приложения равным 240 секундам.
Файл создается, как правило, в корневой директории приложения и указывается в настройках билда VSTS:
Результат успешного построения и выполнения теста отображен далее:
Окно подробной информации о тесте:
Из этого окна можно создать новый баг или ассоциацию теста с задачей разработки.
Цена вопроса: большинство функций для небольших команд разработчиков бесплатны (и даже нет необходимости привязывать кредитную карту к аккаунту). Безлимит на приватные репозитории, создание задач. Кроме того предоставляется частный конвейер (concurrent pipeline), который позволяет запускать одновременно один билд и один релиз. Запустить несколько билдов одновременно можно, но они будут выполнены последовательно один за другим. Кроме того вы можете использовать hosted agent в течении 240 минут в месяц бесплатно (каждый билд или релиз не должен продолжаться дольше чем 30 минут).
Цены для больших команд разработчиков смотрите здесь: Цены за использование Visual Studio Team Services.
вы пробовали NDepend? Он покажет вам зависимости, и вы также можете проанализировать удобство использования ваших классов и методов.
Мне нужно было что-то подобное, но я не хотел платить за (или устанавливать) инструмент для этого. Я!--2-->создан быстрый сценарий PowerShell, который проходит через ссылки на проект и выплевывает их в юмл.мне дружелюбный формат:
обновление: ReSharper с версии 8 имеет встроенный 'Просмотр Зависимостей Проекта' характеристика.
методические указания
- установить инструмент yEd из здесь.
- запустить VS с / resharper.внутренняя командная строка аргумент.
- перейдите к ReSharper / Internal / показать зависимости.
- укажите проекты, которые вы хотите включить в "общую картину".
- снимите флажок "исключить терминальные узлы". - если только тебе это не нужно. Нажмите''.
- используйте иерархический макет в yEd (Alt+Shift+H)
- обеспечить обратную связь =)
В Visual Studio 2010 Ultimate: Архитектура / Создание Графика Зависимостей / По Сборке.
Я написал инструмент, который может помочь вам. VS визуализатор зависимостей решения анализирует зависимости проекта в решении и создает диаграмму зависимостей из этой информации, а также текстовый отчет.
вы можете создать график зависимостей ваших проектов в VS 2010 Ultimate. Обозреватель архитектуры позволяет просматривать решение, выбирать проекты и отношения, которые требуется визуализировать, а затем создавать график зависимостей из выбранного элемента.
дополнительные сведения см. В следующих разделах:
У меня была аналогичная проблема, но она была еще сложнее, потому что несколько проектов ссылались на разные версии одной и той же сборки.
чтобы получить вывод, который включает информацию о версии и проверяет возможные проблемы загрузки сборки во время выполнения, я сделал этот инструмент:
чтобы завершить ответ eriawan на графиках, созданных NDepend см. скриншоты ниже. Ты можешь!--1-->скачать и использовать бесплатную пробную версию из NDepend на некоторое время.
подробнее о графике зависимостей NDepend
подробнее о Матрице зависимостей NDepend:
отказ от ответственности: я являюсь частью команды инструмент
Если вы просто хотите график зависимостей, я нашел, что это один из самых чистых способов получить его:
на решение Powershell - Это лучшее. Я адаптировал его в скрипт bash, который работает на моей машине (TM):
Как вы не знаю, но я себя на этой картинке узнал. Ведь, согласитесь, когда проектируется архитектура приложения, все красиво, логично и соответствует лучшим мировым практикам. Но в процессе работы, сталкиваясь с ограничениями предъявляемыми архитектурой, мы зачастую думаем: «Вот здесь немножко нарушу, это ведь сэкономит мне час времени разработки. Ну а потом, как будет время, поправлю». Но, почему-то, это время так никогда и не наступает. На мой взгляд, единственным способом заставить себя, как программиста, следовать разработанной архитектуре, это научить среду разработки все отклонения и костыли показывать как ошибки компиляции. В этом случае, если код плох, он сразу будет исправлен, ну а если архитектура устарела, то будет исправлена она. Т.е. в хранилище кода всегда будет код соответствующей запланированной архитектуре.
Пара слов, о том, что будет подкатом:
1. Небольшая преамбула.
2. Восстановление архитектуры по имеющемуся проекту.
3. Настройка Visual Studio и TFS для автоматического контроля архитектуры.
Под катом много картинок и желание все описанное попробовать.
Итак, обещанная преамбула. Почти год назад, Дмитрий Андреев (dmandreev) уже публиковал статью на эту тему. Я эту статью с огромным удовольствием прочитал, и, собственно, именно она меня подвигла заняться вопросом применения Layer Diagram в процессе разработки приложений. Кстати, дочитав до этого места, вы уже сходили по приведенной ссылке и прочитали то, что написал Дмитрий? Нет, ну тогда давайте, я вас подожду, а потом пойдем дальше. Жду.
Ок, теперь когда у нас с вами есть общее понимание Layer Diagram можно заканчивать с преамбулой и переходить к практической работе.
Подготовка демонстрационного проекта
Для демонстрации работы с Layer Diagram, я возьму проект, чуть более близкий к реальности, чем рассмотрел Дмитрий. Пусть у нас будет слой доступа к данным (я буду использовать Entity Framework) и, собственно, слой клиентских приложений в котором также будет слоистая структура (MVVM). В клиентском уровне модель будет браться из первого слоя, а вот слои View и ViewModel будут размазаны по нескольким сборкам.
Вот так, эти четыре проекта выглядят после создания:
Я думаю все, изменяют Namespace по умолчанию для создаваемых сборок? Ну вот, и в этом примере, для 3-х клиентских сборок я заменю Default Namespace:
Добавляем в проект DAL базу данных и Entity Model. В клиентских проектах создаем папки View и ViewModel. Добавляем в них тестовые компоненты и классы:
Добавив ссылки между проектами, обращения между созданными компонентами и классами, можно получить граф зависимостей примерно такого вида:
Если разбиение на слои, идет на уровне сборок, то в связи с запретом на циклические ссылки между сборками (иначе нельзя определить порядок построения), возможна только проблема «обращения через слой» (которая как раз и рассматривается в статье Дмитрия). Если же в проекте, как в данном случае, слои размазаны по нескольким сборкам, причем в рамках одной сборки есть представители разных слоев, перетаскивание проектов/файлов из Solution Explorer-а в Layer Diagram оказывается не эффективным. И тут на помощь приходит Architecture Explorer, который вызывается из главного меню: Architecture -> Windows -> Architecture Explorer. Сразу после открытия он будет иметь вид:
Скажу честно, когда я прочитал про этот инструмент первый раз, я сразу же в него влюбился. Такие возможности для анализа зависимостей, что просто дух захватывает. И хотя про него можно писать очень много и восторженно, так как автоматически контролировать архитектуру он не позволяет, о нем подробнее в другой раз.
Восстановление диаграммы слоев из артефактов решения
Раз сцена готова, выпускаем актеров. Добавляем в решение модельный проект, уже в него добавляем Layer Diagram:
Да, здесь мы можем перетяуть из Toolbox-а слои, нарисовать зависимости, потом долго и упорно в эти слои переносить классы из клиентских проектов. И все это только для того, чтобы уже на следующий день, когда разработчик добавит новый класс, про который мы не знаем, и к слоям он не привязан, а следовательно проверка перестанет работать. Чтобы этого избежать, нам и пригодится Architecture Explorer.
Обратите внимание, что все классы ViewModel оказались в одном пространстве имен (ну пусть в реальном проекте они будут в 3-5), и нам теперь можно в диаграмму слоев добавлять не классы, а целиком пространства имен. Выделяем их и, не создавая никаких слоев, перетягиваем на нашу Layer Diagram:
Кстати, можем воспользоваться и функционалом перетаскивания проектов из Solution Explorer-а. С Shift-ом выделяем в нем ClientApp1, ClientApp2 и Base.Library, хватаем левой кнопкой мыши и перетягиваем на свободное место в Layer Diagram:
Переименовываем новый слой в Presentation, выделяем два слоя (View и View Model) и перетаскиваем их в слой Presentation:
Практически все готово, не хватает только связей. Для того, чтобы их сгенерировать, достаточно вызвать контекстное меню на Layer Diagram-е и выбрать пункт Generate Dependencies:
Теперь, наша диаграмма слоев приняла законченный вид:
Если у вас возникает вопрос, по поводу стрелки от ViewModel к View, то посмотреть мнения на эту тему, а может и принять участие в обсуждении, можно на форуме MSDN.
Автоматический контроль архитектуры
Ну и последний момент, как заставить диаграмму слоев автоматически, при каждом построении проверять, что код соответствует архитектуре? На самом деле достаточно просто. Для демонстрации, я в ClientApp1, в папку View добавлю компонент, который будет напрямую обращаться к слою доступа к данным:
Запускам построение и видим: Build succeeded. Для того, чтобы билды при ошибках архитектуры падали, необходимо открыть свойства модели из Solution Explorer-а (через контестное меню или выбрать и нажать F4) и включить проверку архитектуры:
Еще раз запускам построение и видим, что у нас появились ошибки архитектуры:
Двойной клик на ошибке, сразу привод к месту, в которое забит костыль.
Конечно, проверка зависимостей приводит к увеличению времени компиляции, поэтому можно собрать два решения, одно с которым работают разработчики (в него не включать Modeling Project), а второе, с тем же набором проектов и Modeling Project, для автоматических построений в Team Foundation Server. В этом случае на рабочих местах построение идет быстрее, а контроль архитектуры выполняется на сервере, причем по ошибкам построения, могут сразу генерироваться баги.
Перед тем, как перейти к выводам, небольшая ремарка. Все описанное в данной статье работает и в Visual Studio 2010 и в Visual Studio 2012. Единственно, требуется версия Ultimate или Premium. Если у вас нет лицензии на соответствующие версии Visual Studio 2010, то Release Candidate версию Visual Studio 2012 Ultimate можно скачать здесь.
Выводы
1. Layer Diagram это инструментарий, про который надо как минимум знать, и в новых проектах начинать применять
2. Автоматическая проверка архитектуры позволит снизить количество «костылей» забиваемых в спешке или по не знанию
3. Правильное именование пространств имен и применение Architecture Explorer-а позволяет существенно сократить время на восстановление архитектуры
P.s. Если в данной статье, про что-то и забыл рассказать, то прошу на меня сильно не ругаться, и читать первоисточники: Визуализация существующего кода.
Читайте также: