Динамическая проверка зависимостей visual studio
Если в решении есть проекты, которые зависят друг от друга, т. е. один проект зависит от типов другого проекта и использует их, то Visual Studio должна знать порядок сборки проектов. Для примера рассмотрим проект приложения Windows, который использует типы, предоставляемые проектом библиотеки классов. Если в последовательности сборки сначала не будет собрана библиотека классов, то процесс сборки закончится неудачно.
В большинстве случаев Visual Studio способна сама определить правильную последовательность сборки. Однако иногда вам может понадобиться вручную указать, что некий проект зависит от других проектов. Для предоставления такой информации используйте страницу свойств Project Dependencies (рис. 4.7). Выберите проект в раскрывающемся списке, а затем укажите, от каких решений он зависит (для этого нужно отметить проекты в окне списка Depends on).
Местоположение файлов исходных кодов для отладки
В определенных ситуациях вам может понадобиться явно указать отладчику Visual Studio файлы исходных кодов для использования в процессе работы отладчика.
Одна из таких ситуаций — это когда вы пытаетесь отлаживать решение, которое ссылается на объект на удаленном компьютере. Если файл исходного кода для этого удаленного объекта на локальном компьютере отсутствует, то вы можете явно указать для Visual Studio файлы исходных кодов.
Для того чтобы добавить элемент в любое из полей, сначала поместите ваш курсор в поле, а затем щелкните кнопку New Line (вверху справа в диалоговом окне). Это позволит вам ввести полностью квалифицированный путь к нужному каталогу. Удаляется элемент путем его выделения и последующего щелчка по кнопке Cut Line. Кнопка Check Entries позволяет вам еще раз перепроверить, что все элементы указывают на правильные и доступные пути к каталогам.
Если вы загрузили решение с проектами на языке Visual C++, то, вероятно, сразу же увидите несколько элементов в списке Directories containing source code.
Чтобы убедиться в том, что код не конфликтует с его конструкцией, выполните проверку кода с помощью схем зависимостей в Visual Studio. Это может помочь:
Поиск конфликтов между зависимостями в коде и зависимостями на схеме зависимостей.
Найти зависимости, на которые могут повлиять предложенные изменения.
Например, можно изменить схему зависимостей, чтобы показать потенциальные изменения архитектуры, а затем проверить код, чтобы увидеть затронутые зависимости.
Выполнить рефакторинг или миграцию кода в другую структуру.
Найти код или зависимости, с которыми потребуется выполнить определенные действия даже после перемещения кода в другую архитектуру.
Требования
Чтобы узнать, какие выпуски Visual Studio поддерживают эту функцию, см. раздел Поддержка инструментов моделирования и архитектуры в различных выпусках.
код можно проверить вручную из открытой схемы зависимостей в Visual Studio или из командной строки. вы также можете проверить код автоматически при выполнении локальных сборок или сборок Azure Pipelines. См. видео Channel 9: проектирование и проверка архитектуры с помощью схем зависимостей.
если вы хотите выполнить проверку слоев с помощью 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), который вы хотите использовать для проверки.
В окне Свойства убедитесь, что для свойства действие построения схемы задано значение Проверка.
Сюда входит схема зависимостей в процессе проверки.
Сведения об управлении ошибками в окне список ошибок см. в разделе разрешение ошибок проверки слоев.
Устранение неполадок проверки слоев
Следующая таблица описывает проблемы проверки слоев и способы их устранения. Эти проблемы отличаются от ошибок, возникающих из-за несоответствия между кодом и структурой. Дополнительные сведения об этих ошибках см. в разделе Устранение неполадок при проверке слоев.
Разрешение ошибок проверки слоев
При проверке кода на соответствие схеме зависимостей ошибки проверки возникают, когда код конфликтует с конструкцией. Например, ошибки проверки могут происходить по следующим причинам:
Артефакт назначен неправильному слою. В этом случае следует переместить артефакт.
Способ использования артефактом (например, классом) другого класса конфликтует с имеющейся архитектурой. В этом случае необходимо выполнить рефакторинг кода, чтобы устранить зависимость.
Для устранения этих ошибок следует обновлять код до тех пор, пока в процессе проверки не перестанут происходить ошибки. Эту процедуру можно выполнить методом итераций.
В следующем разделе описывается синтаксис, используемый в этих ошибках, объясняется значение этих ошибок и предлагаются пути решения или управления ими.
Артифакттипен — это тип Артифактн, например класс или метод, например:
Проверка кода по схемам зависимостей
Зачем использовать схемы зависимостей?
Чтобы убедиться в том, что код не конфликтует с его конструкцией, выполните проверку кода с помощью схем зависимостей в Visual Studio. Это может помочь:
Поиск конфликтов между зависимостями в коде и зависимостями на схеме зависимостей.
Найти зависимости, на которые могут повлиять предложенные изменения.
Например, можно изменить схему зависимостей, чтобы показать потенциальные изменения архитектуры, а затем проверить код, чтобы увидеть затронутые зависимости.
Выполнить рефакторинг или миграцию кода в другую структуру.
Найти код или зависимости, с которыми потребуется выполнить определенные действия даже после перемещения кода в другую архитектуру.
Требования
Чтобы узнать, какие выпуски Visual Studio поддерживают эту функцию, см. раздел Поддержка инструментов моделирования и архитектуры в различных выпусках.
код можно проверить вручную из открытой схемы зависимостей в Visual Studio или из командной строки. вы также можете проверить код автоматически при выполнении локальных сборок или сборок Azure Pipelines. См. видео Channel 9: проектирование и проверка архитектуры с помощью схем зависимостей.
[!IMPORTANT] если вы хотите выполнить проверку слоев с помощью Team Foundation Server (TFS), необходимо также установить на сервере сборки ту же версию Visual Studio.
Динамическая проверка зависимостей
Проверка зависимостей происходит в режиме реального времени, и ошибки отображаются сразу в Список ошибок.
Чтобы включить полный анализ решения при использовании динамической проверки зависимостей, откройте параметры в строке Gold, которая отображается в Список ошибок.
- Вы можете навсегда отклонить строку Gold, если вы не хотите видеть все проблемы архитектуры в решении.
- Если не включить полный анализ решений, анализ выполняется только для редактируемых файлов.
При обновлении проектов для включения динамической проверки в диалоговом окне отображается ход выполнения преобразования.
при обновлении проекта для динамической проверки зависимостей версия пакета NuGet обновляется так же, как и для всех проектов, и является самой высокой используемой версией.
Добавление нового проекта проверки зависимостей активирует обновление проекта.
Определение, поддерживает ли элемент проверку
слои можно связывать с веб-сайтами, Office документами, обычными текстовыми файлами и файлами в проектах, которые являются общими для нескольких приложений, но в процессе проверки их не включаются. Ошибки проверки для ссылок на проекты или сборки, связанные с отдельными слоями, отображаются только в том случае, если между этими слоями отображаются зависимости. Эти ссылки считаются зависимостями, только если используются в коде.
На схеме зависимостей выберите один или несколько слоев, щелкните правой кнопкой мыши выделенный фрагмент и выберите пункт Просмотреть ссылки.
В обозревателе слоев просмотрите столбец поддерживает проверку . Если значение равно false, элемент не поддерживает проверку.
В Обозреватель решений щелкните правой кнопкой мыши проект моделирования или папку ссылки на слой , а затем выберите команду Добавить ссылку.
В диалоговом окне Добавление ссылки выберите сборки или проекты, а затем нажмите кнопку ОК.
Проверка кода вручную
При наличии открытой схемы зависимостей, связанной с элементами решения, можно выполнить команду проверить ярлык на схеме. Можно также использовать командную строку для выполнения команды MSBuild с настраиваемым свойством /p: validatearchitectureonbuild , установленным в значение true. Например, при внесении изменений в код регулярно выполняйте проверку слоев, чтобы заранее обнаруживать конфликты зависимостей.
Проверка кода на основе открытой схемы зависимостей
Щелкните правой кнопкой мыши поверхность схемы и выберите пункт Проверить архитектуру.
[!NOTE] По умолчанию свойству действие сборки в файле схемы зависимостей (. LAYERDIAGRAM) присваивается значение Проверка , чтобы схема включалась в процесс проверки.
Окно Список ошибок сообщает о любых произошедших ошибках. Дополнительные сведения об ошибках проверки см. в разделе Устранение неполадок при проверке слоев.
Чтобы просмотреть источник каждой ошибки, дважды щелкните ошибку в окне Список ошибок .
[!NOTE] Visual Studio может показывать карту кода вместо источника ошибки. Это происходит, когда либо код имеет зависимость от сборки, которая не указана схемой зависимостей, либо в коде отсутствует зависимость, указанная схемой зависимостей. Просмотрите карту кода или код, чтобы определить, должна ли существовать зависимость. Дополнительные сведения о картах кода см. в статье сопоставление зависимостей в решениях.
Сведения об управлении ошибками см. в разделе разрешение ошибок проверки слоев.
Проверка кода в командной строке
откройте командную строку Visual Studio.
Выберите один из следующих вариантов.
чтобы проверить код для конкретного проекта моделирования в решении, выполните MSBuild со следующим пользовательским свойством.
перейдите в папку, содержащую файл проекта моделирования (modelproj) и схему зависимостей, а затем запустите MSBuild со следующим пользовательским свойством:
чтобы проверить код для всех проектов моделирования в решении, запустите MSBuild со следующим пользовательским свойством:
перейдите к папке решения, которая должна содержать проект моделирования, содержащий схему зависимостей, а затем запустите MSBuild со следующим пользовательским свойством:
Отобразятся любые возникающие ошибки. дополнительные сведения о MSBuild см. в разделе задача MSBuild и MSBuild.
Дополнительные сведения об ошибках проверки см. в разделе Устранение неполадок при проверке слоев.
Управление ошибками проверки
В процессе разработки может понадобиться подавить некоторые конфликты, выявленные в ходе проверки. Например, можно подавлять ошибки, над которыми уже ведется работа, а также ошибки, не имеющие отношения к конкретному сценарию. При подавлении ошибки рекомендуется вести журнал рабочего элемента в Team Foundation.
[!WARNING] Вы должны быть уже подключены к управлению исходным кодом (SCC) TFS для создания рабочего элемента или связи с ним. При попытке открыть соединение с другим SCC TFS Visual Studio автоматически закрывает текущее решение. Убедитесь, что вы уже подключены соответствующему SCC, перед попыткой создания рабочего элемента или связи с ним. В последних выпусках Visual Studio команды меню недоступны, если вы не подключены к SCC.
Создание рабочего элемента для ошибки проверки
- В окне Список ошибок щелкните ошибку правой кнопкой мыши, наведите указатель на пункт создать рабочий элемент, а затем выберите тип рабочего элемента, который требуется создать.
Используйте эти задачи для управления ошибками проверки в окне Список ошибок :
Отобразятся подавленные ошибки с форматированием в виде зачеркивания. При выполнении проверки в следующий раз эти ошибки отображаться не будут.
Автоматическая проверка кода
Проверку слоев можно выполнять при каждом выполнении локальной сборки. если ваша команда использует Azure DevOps, можно выполнить проверку слоев с помощью условных возвратов, которые можно указать, создав пользовательскую задачу MSBuild, и использовать отчеты построения для получения ошибок проверки. Сведения о создании сборок с условным возвратом см. в разделе TFVC с проверкой изменений.
Автоматическая проверка кода во время локальной сборки
Откройте файл проекта моделирования (.modelproj) в текстовом редакторе и включите следующее свойство.
В Обозреватель решений щелкните правой кнопкой мыши проект моделирования, содержащий диаграмму зависимостей или диаграммы, и выберите пункт свойства.
В окне Свойства задайте для свойства Проверить архитектуру проекта моделирования значение true.
Это позволяет включить проект моделирования в процесс проверки.
В Обозреватель решений щелкните файл схемы зависимостей (. LAYERDIAGRAM), который вы хотите использовать для проверки.
В окне Свойства убедитесь, что для свойства действие построения схемы задано значение Проверка.
Сюда входит схема зависимостей в процессе проверки.
Сведения об управлении ошибками в окне список ошибок см. в разделе разрешение ошибок проверки слоев.
Устранение неполадок проверки слоев
Следующая таблица описывает проблемы проверки слоев и способы их устранения. Эти проблемы отличаются от ошибок, возникающих из-за несоответствия между кодом и структурой. Дополнительные сведения об этих ошибках см. в разделе Устранение неполадок при проверке слоев.
Разрешение ошибок проверки слоев
При проверке кода на соответствие схеме зависимостей ошибки проверки возникают, когда код конфликтует с конструкцией. Например, ошибки проверки могут происходить по следующим причинам:
Артефакт назначен неправильному слою. В этом случае следует переместить артефакт.
Способ использования артефактом (например, классом) другого класса конфликтует с имеющейся архитектурой. В этом случае необходимо выполнить рефакторинг кода, чтобы устранить зависимость.
Для устранения этих ошибок следует обновлять код до тех пор, пока в процессе проверки не перестанут происходить ошибки. Эту процедуру можно выполнить методом итераций.
В следующем разделе описывается синтаксис, используемый в этих ошибках, объясняется значение этих ошибок и предлагаются пути решения или управления ими.
Артифакттипен — это тип Артифактн, например класс или метод, например:
Как вы не знаю, но я себя на этой картинке узнал. Ведь, согласитесь, когда проектируется архитектура приложения, все красиво, логично и соответствует лучшим мировым практикам. Но в процессе работы, сталкиваясь с ограничениями предъявляемыми архитектурой, мы зачастую думаем: «Вот здесь немножко нарушу, это ведь сэкономит мне час времени разработки. Ну а потом, как будет время, поправлю». Но, почему-то, это время так никогда и не наступает. На мой взгляд, единственным способом заставить себя, как программиста, следовать разработанной архитектуре, это научить среду разработки все отклонения и костыли показывать как ошибки компиляции. В этом случае, если код плох, он сразу будет исправлен, ну а если архитектура устарела, то будет исправлена она. Т.е. в хранилище кода всегда будет код соответствующей запланированной архитектуре.
Пара слов, о том, что будет подкатом:
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 можно скачать здесь.
Не только на C++. Новые технологии, процессы и Agile.
среда, 20 мая 2015 г.
Анализ зависимостей в проекте своими руками
Ранее я уже писал про скрипт, который позволяет построить граф зависимостей между проектами Visual Studio.
Microsoft в момент перехода на Vistual Studio 2010 поменяла формат проектных файлов. Но хорошо то, что файлы солюшенов и в VS2008 и в VS2010 имеют XML формат. Это позволяет использовать язык запросов XPath, чтобы легко получить нужное поле. В PowerShell это делается командой Select-Xml. С ее помощью из файла проекта несложно вытащить зависимости. Также, хочется, чтобы разные типы проектов в конечном графе отображались разными цветами. Для этого надо выяснить какие типы бывают. Это можно сделать, натравив следующую команду на каталог с кучей проектов:
Можно заметить, что в PowerShell поток с результатами выполнения команд удобно перенаправлять в следующую команду с помощью символа «|». Команда Get-ChildItem помогает найти все файлы типа vcxproj, а Select-Xml выбирает из них тип конфигурации. Для каждого файла выводим тип проекта на экран. При большом количестве файлов вывод получается не очень информативен, но в PowerShell есть команда Group-Object, которая спасает положение группируя результаты. Итого получаем что-то вроде этого:
Аналогично можно сделать для файлов типов vcproj, csproj и других. В vcproj файлов типы конфигураций кодируются числами, но, что за ними стоит, выяснить не сложно открыв проект в Visual Studio.
На данном этапе у нас есть проекты, их типы и связи между ними. Можно формировать GraphViz файл. Делается это очень просто — сразу записываем заголовок следующего вида:
А далее все проекты и связи между ними:
Цвет связи привязан к проекту, чтобы было легче читать граф. Т.е. у каждого проекта все исходящие связи одного цвета. Сделать это можно использовав HSL (от англ. Hue, Saturation, Lightness) представление цвета. Фиксируем S и L компоненты, а H меняем при обработке очередного файла проекта. Потом HSL преобразуем в RGB и записываем в выходной файл.
Исходный код функции выбора цвета, а также всего остального скрипта можно найти на GitHub.
Читайте также: