The answer is related to the underlying ReSharper architecture. When processing files, ReSharper will create an abstract syntax tree, and each node in the tree can have one or more references to the element in the semantic model. In other words, Foo in the expression new Foo(42) will have a reference to a semantic element describing a class called Foo . Each file will have many links, since any use of an element (variable, parameter, method, property, CSS class, HTML color, path to the file system, etc.) contains one or more links to the declaration of this element.
These links are very effective. They allow Ctrl + click navigation just by navigating to the target (s) of the link. They can ensure code completion by displaying candidate targets that would satisfy the link at the current location in the code.
And, of course, they can also use the search, using all the links intended for a specific element. But this requires working backward, from goal to link. The brute force approach will require checking the purpose of each link in each file, trying to find the target. This is clearly not scalable, and the dataset is too large to cache.
To perform a standby search, ReSharper also maintains an index of words, all words used in all files (this also helps with normal Go To navigation). When you call Find Usages on a character (for example, EnterDate in the screenshot in the question), ReSharper uses the word index to narrow down the files that it needs to search for - it will search for EnterDate and use these files that only include the word. After he has a reduced subset of files to search for, he needs to find links that target the source element. To do this, it processes the syntax tree of each file in a subset. Each node is checked for links that match the name of the character we are looking for, for example. EnterDate If it matches, the link will be resolved, and the target will be checked to make sure that it matches the same element - the EnterDate class or property or what it really was. If it indicates an expected goal, it is added to the custom collection and displayed to the user.
(Things are a little more complicated than this, because the link may have several names, for example, if you try to find ways to use [Pure] , ReSharper should find any use for both Pure and PureAttribute . These alternative names are also stored in the word index and used to reduce the files that need to be searched. When checking links, all alternative names are checked)
So, if you have a .resx file containing EnterDate text, it will look for a link to the EnterDate element you are looking for - ReSharper will go through the syntax tree of the .resx file, and check each link to see if it EnterDate .
We check all files, even if it seems obvious to the user that the target element cannot be used in this file, because we allow the links to be cross-linked. That is, a VB file may refer to a C # element, or an HTML file may refer to a CSS element or a link to a XAML file to a C # method element, etc. Thus, there is no “reasonable” use filtering. For example, if EnterDate is a class, you, as a user, can say that it is unlikely to be in the .resx file, but ReSharper does not know this. After all, it’s great to use the class name in the type attribute of the web.config file or as the typeof parameter in the VB file. Or the plugin can add a link provider that allows the use of name types in .resx files. Thus, we keep everything simple and look through all the links to the candidate, although the progress may seem strange in the dialog box.