Обнаружение зависимостей между пространствами имен в .NET

Question

Существуют ли какие-либо утилиты, которые могут проверять набор управляемых сборок и сообщать вам, зависит ли какой-либо из типов в одном пространстве имен от другого в другом? Например, скажем, у меня есть пространство имен MyApp.BusinessRules, и я не хочу, чтобы он напрямую обращался к чему-либо в MyApp.GUI, но оба пространства имен находятся в одной сборке. Моя цель - написать собственную задачу MSBuild, которая проверяет, не были ли нарушены различные правила связывания.

Пока что единственный инструмент, с которым мне довелось столкнуться, который выглядит так, как будто он может это делать, это NDepend , но мне интересно, есть ли более простое решение.

Answer 1

Я подозреваю, что NDepend будет самым простым путем, если честно.

Однако, если вы действительно не хотите, чтобы биты одной сборки ссылались друг на друга, вам почти наверняка следует разбить сборку на более логические единицы.

Answer 2

Вы можете анализировать зависимости пространства имен с помощью плагина DSM для .NET Reflector (я его разработчик)

После анализа сборок вы можете сохранить проект в файл. Этот файл представляет собой простой XML-файл с простой структурой, поэтому его можно передать в сценарий для пользовательского анализа

[Обновление] : этот плагин теперь доступен в виде надстройки Visual Studio

Answer 3

Пока что единственный инструмент, с которым мне довелось столкнуться, который выглядит так, как будто он может это делать, - это NDepend, но мне интересно, есть ли более простое решение.

Я один из разработчиков инструмента NDepend . Не могли бы вы сообщить нам, что вы считаете сложным в NDepend и как вы представляете себе более простое решение для вас?

NDepend поставляется с 3 различными способами сделать то, что вы хотите: Матрица зависимостей , График зависимостей , а также вы можете написать некоторое Правило кода над LINQ Query (CQLinq) и правила для обнаружения цикла между пространствами имен или для обеспечения некоторых конкретных зависимостей.

Например, допустим, у меня есть пространство имен MyApp.BusinessRules, и я не хочу, чтобы он напрямую обращался к чему-либо в MyApp.GUI, но оба пространства имен находятся в одной сборке.

Для этого можно написать следующее правило CQLinq, может ли оно быть проще?

warnif count > 0
let businessRules = Application.Namespaces.WithNameLike("^MyApp.BusinessRules")
let gui = Application.Namespaces.WithNameLike("^MyApp.GUI")

from n in businessRules.UsingAny(gui)
let guidNamespacesUsed = n.NamespacesUsed.Intersect(gui)
select new { n, guidNamespacesUsed }

Answer 4

Вы можете попробовать RC-выпуск Visual Studio 2010 Ultimate для создания графиков зависимостей для кода .NET. Вы можете создать график всех ваших сборок, пространств имен, классов или какой-либо их комбинации, или вы можете использовать Architecture Explorer, чтобы выбрать конкретные артефакты и отношения, которые вы хотите визуализировать.

Вы также можете создавать диаграммы слоев из графиков зависимостей или из существующих артефактов, рисовать разрешенные зависимости, а затем включать проверку уровня как часть процесса MSBuild, чтобы убедиться, что недопустимые зависимости не представлены:

Как: генерировать документы графиков из кода : http://msdn.microsoft.com/en-us/library/dd409453%28VS.100%29.aspx#SeeSpecificSource

Вы можете использовать Visual Studio Ultimate для изучения взаимосвязей и организации в существующем коде с помощью генерация ориентированных графовых документов. Эти графики представляют элементы кода и их отношения как набор узлов, которые связаны ссылками или ребрами. Вы можете использовать эти графики, чтобы помочь вам визуализировать, исследовать и анализировать код.

Как найти код с помощью обозревателя архитектуры : http://msdn.microsoft.com/en-us/library/dd409431%28VS.100%29.aspx

Вы можете выбрать вертикальные участки или «кусочки» кода, которые вы хотите визуализировать, используя Архитектурный обозреватель. Вы можете изучить исходный код в решении Visual Studio или скомпилированный управляемый код в файлах .dll или .exe. Вы можете использовать Architecture Explorer для просмотра другие домены путем установки дополнительных провайдеров. Когда вы найдете код, который вы хотите визуализируйте, вы можете создавать графики для изучения отношений в этом коде.

Как: создавать диаграммы слоев из артефактов : http://msdn.microsoft.com/en-us/library/dd465141%28VS.100%29.aspx

... используйте диаграммы слоев, чтобы визуализировать архитектуру вашей системы высокого уровня и убедиться, что код соответствует этому дизайну. Для выполнения этой задачи организуйте и свяжите артефакты из решения Visual Studio в логические, абстрактные группы или слои. Эти слои опишите основные задачи, которые выполняют эти артефакты, или основные компоненты вашей системы. Стрелы между слоями представляют взаимозависимости, которые существуют или должны существовать между этими артефакты. Чтобы обеспечить архитектурные ограничения в коде, опишите предполагаемые зависимости от диаграмму, а затем проверить код по диаграмме. Используя диаграммы слоев в этом таким образом, вы можете помочь сделать код более легким для понимания, повторного использования и обслуживания.

Диаграмма слоя http://i.msdn.microsoft.com/Dd465141.UML_LayerRefReading(en-us,VS.100).png

Как проверить код на диаграммах слоев : http://msdn.microsoft.com/en-us/library/dd409395%28VS.100%29.aspx

Проверка кода по диаграмме слоев помогает применять архитектурные ограничения к коду как это развивается. При выполнении этой задачи зависимости в коде сравниваются с зависимостями на диаграмме.

RC скачать : http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=457bab91-5eb2-4b36-b0f4-d6f34683c62a.

Visual Studio 2010 Архитектурные инструменты для обнаружения и моделирования

Answer 5

Отражатель делает это.

Щелкните правой кнопкой мыши пространство имен, выберите Анализ, альт! :)