Ответ на этот вопрос связан с базовой архитектурой ReSharper. При обработке файлов ReSharper будет создавать абстрактное синтаксическое дерево, и каждый узел в дереве может иметь одну или несколько ссылок на элемент семантической модели. Другими словами, Foo в выражении new Foo(42) будет иметь ссылку на семантический элемент, описывающий класс, называемый Foo. Каждый файл будет иметь множество ссылок, так как любое использование элемента (переменная, параметр, метод, свойство, класс CSS, цвет HTML, путь к файловой системе и т. Д.) Содержит одну или несколько ссылок на объявление этого элемента.
Эти ссылки очень эффективны. Они активируют Ctrl + Нажмите навигацию, просто перейдя к цели (-ям) ссылки. Они могут обеспечить завершение кода, показывая целевые объекты-кандидаты, которые удовлетворяли бы ссылке в текущем местоположении в коде.
И, конечно же, они также могут использовать поиск, используя все ссылки, предназначенные для определенного элемента. Но для этого требуется работа назад, от цели до ссылки. Подход грубой силы потребует проверки цели каждой ссылки в каждом файле, пытаясь найти цель. Это явно не будет масштабироваться, и набор данных слишком большой для кэширования.
Для того, чтобы поиск выполнялся в разумной временной шкале, ReSharper также поддерживает индекс слов всех слов, используемых во всех файлах (это также помогает при нормальной навигации Go To). Когда вы вызываете Find Usages на символ (например, EnterDate на скриншоте в вопросе), ReSharper использует индекс слова для сужения файлов, которые ему нужны для поиска, - он будет искать EnterDate и использовать только те файлы, которые включают в себя слово , После того, как он имеет уменьшенное подмножество файлов для поиска, ему необходимо найти ссылки, которые нацелены на исходный элемент. Для этого он обрабатывает дерево синтаксиса каждого файла в подмножестве. Каждый узел проверяется для ссылок, которые соответствуют имени символа, который мы ищем, например. EnterDate. Если он совпадает, ссылка будет разрешена, и цель будет проверена, чтобы убедиться, что она соответствует одному элементу - классу EnterDate или свойству или тому, что на самом деле было. Если он указывает на ожидаемую цель, он добавляется в коллекцию обычаев и отображается пользователю.
(Вещи немного более сложные, чем это, в том, что ссылка может иметь несколько имен, например, если вы пытаетесь найти использования на [Pure], ReSharper нужно найти какие-либо обычаи как Pure или PureAttribute. К счастью, эти альтернативных названия также хранится в индексе слов и используется для уменьшения файлов, которые нужно искать. При проверке ссылок проверяются все альтернативные имена)
Итак, если у вас есть .resx-файл, содержащий текст EnterDate, он будет искать ссылку на нужный элемент EnterDate - ReSharper будет ходить по дереву синтаксиса файла .resx и проверять каждую ссылку, чтобы увидеть, соответствует ли она EnterDate.
Мы проверяем все файлы, даже если пользователю кажется очевидным, что целевой элемент не может быть использован в этом файле, потому что мы разрешаем ссылки на перекрестный язык. То есть, файл VB может ссылаться на элемент C#, или HTML-файл может ссылаться на элемент CSS или ссылку на файл XAML на элемент метода C# и т. Д. Таким образом, фильтрация «разумного» использования отсутствует. Например, если EnterDate является классом, вы, как пользователь, можете сказать, что он вряд ли находится в файле .resx, но ReSharper не знает этого. В конце концов, отлично использовать имя класса в атрибуте type файла web.config или в качестве параметра typeof в файле VB. Или плагин может добавить поставщика ссылок, который допускает использование типов имен в файлах .resx. Итак, мы все упрощаем и просматриваем все кандидаты, хотя в диалоговом окне прогресса это может показаться странным.
Спасибо за супер подробный ответ. Я понял, что «AST» и «word indexes» будут вовлечены в объяснение того, почему проверяются файлы resx. Имеет смысл. Я считаю, что реальное решение для моей ситуации - найти способы разбить нашу большую базу кода, которая заставит все наши инструменты работать лучше. –
О, я забыл о бите производительности :) Я не знаю, почему он должен быть медленнее с .resx-файлами, чем что-либо еще - поиск использования должен быть довольно быстрым, даже на больших кодовых базах. Единственный момент, когда он должен быть медленным, - это поиск того, что является общим для загрузок файлов, таких как «класс». Вы можете найти профиль в профиле в меню «Справка» и отправить его или попробовать 9.1 EAP, чтобы узнать, есть ли там лучше - «Поиск использования» имел обновления в 9.0. – citizenmatt
Этот ответ не объясняет, можно ли изменить это поведение (например, отключить построение деревьев АСТ для файлов .resx) ... и «мы проверяем все файлы» - это решение, которое, как мне кажется, должно быть сделано для пользователя. –