VS Project dependencies viewer. One that just works.

Как-то мне понадобилось изучить зависимости между проектами. Я попробовал различные инструменты для этого, но никто не справился нарисовать более или менее внятную картину для нашего случая. А случай довольно экзотический, сейчас в солюшене ReSharper более 300 проектов. Встроенная фича студии Ultimate показала мне следующее:

Пришлось придумывать что-то своё. В качестве программы для просмотра я выбрал yEd от yWorks, сгенерировал граф зависимостей между проектами в ее формате, но по-прежнему ничего понятно не было.
Пришлось применять некоторые улучшения:

1. Убрать все транзитивные зависимости. Если были проекты A, B и C и зависимости (A->B, B->C и A->C), то A->C можно не показывать так как она сама по себе не так важна.
2. Сделать в графе группировки (я использовал Solution Folders). Это что помогает yFiles лучше справиться со своей задачей. 
3. Дать возможность выбрать проекты для которых построить зависимости. При этом учитывать транзитивные зависимости проходящие через невыбранные проекты.
4. При наличии групп можно не показывать проекты от которых нет зависимостей вне группы. (Это опционало, конечно). 

Все это вместе позволило быстро соорудить поделку, позволяющую решать мои задачи по разруливанию зависимостей между проектами. И самое главное, если у Вас уже есть ReSharper 7, то можно попробовать то, что у меня получилось. Необходимо поставить yEd от yWorks, запустить студию с ключиком /resharper.internal и идти в меню ReSharper -> Internal -> Show Dependencies:

Затем, в окошке должны появиться проекты, сгруппированные по папкам. Эта группировка будет использована при построении графа. Выбираем проекты которые хочется показать. Внимание, есть галочка 'Exclude terminal nodes'.

Получается вполне читаемая картинка (чтобы ее получить необходимо нажать магический Alt+Shift+H - раскладка иерархическая):

Буду рад фидбэку =)

Manual:

1. Install yEd tool from here. 
2. Run VS with /resharper.internal command line argument.
3. Go to ReSharper/Internal/Show Dependencies. 
4. Specify projects that you want to include to the 'big picture'. 
5. Uncheck 'Exclude terminal nodes...' unless you need it. 
6. Press 'Show'. 
7. Use hierarchical layout in yEd (Alt+Shift+H) 
8. Provide feedback =)

I am often asked about basic entities of ReSharper code model and relations between them. Here is a table that would help to understand basic principles. Read the table below from left to right and then to top. For more infofrmation about the SDK see: this page

	ITreeNode	IReference	IDeclaredElement	IDeclaration
ITreeNode	id	.GetReferences()		node as IDeclaration
IReference	.GetTreeNode()	id	.Resolve().DeclaredElement
IDeclaredElement		IPsiService.Finder.FindReferences(...)	id	.GetDeclarations()
IDeclaration	id		.DeclaredElement	id

Screenshots I like...

 Кто-то использует такие штуки?

Они помогают студийному комплишену. R# их тоже понимает, но может жить и без них.

Вот такое полезно после перетаскивания файликов:

А это уже интеллект - аля import popup)

Вот такая мелочь, а приятно)

RAZOR & R#

Так получилось, что мы и микрософт занимаемся очень похожими вещами. Еще так получилось, что в истоках нашего проекта стояли люди мудрые и они сделали нашу модель кода PSI хорошо! Написание большинства фич стало возможно именно благодаря PSI. Наша модель кода - это наше преимущество и мы должны беречь ее и ухаживать за ней.

А теперь рассмотрим задачу. Есть такая технология - называется RAZOR. Это такая сместь C# и HTML, которая отличается от ASP тем, что синтексические конструкции двух языков более или менее вложены друг в друга.

И мы имеем два пути. Мы можем свести все к C# и довольствоваться тем, что фичи будут работать там, где нет HTML. А еще мы можем сделать язык C# немного более открытым для новых синтаксических конструкций, реализовать для этих конструкций парсер, резолв, СFA, und so weiter... и, таким образом, получить платформу для поддержки C#-подобных языков и фичи, (такие как extract method) работающие на самом высоком уровне! Конкуренты - бойтесь!

у меня javascript.

В последнее время я много занимался поддержкой javascript. В основном, дело касалось code completion. Расскажу немного о трудностях, которые возникают, когда в языке отсутствуют типовые аннотации. Как ни странно это звучит, с решарпером javascript становится языком с довольно внушительной системой типов. Еще более странно будет звучать то, что все эти типы не используются для резолва, но обо всем по порядку.
Первое, что надо делать при поддержке любого языка - это построить кэш деклараций. В javascript нелокальными являются только свойства объектов. Существует бесчисленное (в прямом смысле этого слова) множество способов определить свойство в объекте. Начать можно с функции конструктора, для разминки поддержать микрософтовский RegisterNamespace("Jetbrains.ReSharper"), после чего можно сделать jQuery.Extend(). Для любителей пособирать декларации самостоятельно в этом месте все расширяемо и можно писать свои провайдеры.
Декларации просто так собирать не интересно, для каждого свойства хорошо бы знать его объемлющий класс (для которого это свойство может быть статическим или свойством объекта). Тут же собираем информацию о наследовании классов. Инвертируем полученную информацию об объемлющих классах и имеем основной источник информации об объеках и их свойствах.
Второй источник - это выражение, которым было проинициализировано свойство. Опять же, здесь есть место для тех, кто знает про типы выражений какие-то свои тайны.
А теперь главное: как представляется тип. Он почти всегда является наборов из нескольких типов, свойства которых объединяются. Самих же свойств довольно много:
1. Собственно свойства объекта. Пример: x.
2. Сигнатура (в случае если объект можно вызывать). Пример: x(1,2,3).
3. Тип возвращаемого значентя. Пример тот же.
4. Тип создаваемого объекта. Это значит что функция была конструктором. Пример: new x().
5. Базовый тип. Пример: x.prototype.
Вычисление типов может залезать довольно далеко в код и кэши, поэтому в вычислялке есть механизм кэширования и защита от зацикливаний. На посчитанных типах работает только комплишен и информация о параметрах. Для резолва тип квалификатора не используется, что мне кажется правильным. В ближайшем будущем я сделаю киллер фичу: create property from usage, которая станет третьим клиентом моей типизации javascript, а провыйдеры свойств я обяжу уметь создавать свойства которые они распознают. И теперь представьте себе, что расширение для jQuery можно будет сделать нажав alt+enter!

Плюс десять процентов к карме

Код комплишен остался где-то позади. Нет, про него никто не забыл, просто теперь он может жить своей новой и прекрасной жизнью самостоятельно, а я могу лишь радоваться тому, что за пару недель количество правил выросло на 10% до 110. Значит есть жизнь после рефакторинга и есть смысл двигаться дальше. 

А дальше идет еще более чудесный JavaScript, в котором из комментариев мы пытаемся извлекать информацию о типах, которой так не хватает человеку, избалованному строгими языками, пытаемся воплотить тысячу и одну идею облегчения жизни пользователям jQuery, полируем код комплишен и активно работаем с чудо-листочком, пытаясь ужать безграничную фантазию в 3 месяца сроку... Не знаю, почему я пишу слово 'мы'.

И вот в этой суете я задумался над одной вещью. Допустим, мы удалим поддержку js. Да, прямо сегодня мы стираем всю поддержку js и начинаем писать все заново. Мы укладываемся в 3 месяца? Ах, черт, боюсь что нет. Хотя это я считаю на одного человека. Если их будет двое? Уже более реалистично. А было ли это так же реалистично полгода назад?

У меня утро!

Попробуйте сформулировать, что делает ваша фича или подсистема. Сделайте это письменно, на хорошем русском языке и Вы, возможно, увидите некоторые проблемы в архитектуре. Возможно, Вы увидите и некоторые достоинства Вашей реализации! Но то, что Вы увидите что-то, о чем раньше не думали - это факт.