Each solution has an index, which indexes the code for that solution. When you open a solution that Source Search hasn't seen before, it prompts you for what to do:
If you don't want to be prompted, you can switch that off using the "Next time..." options.
Using Create will prompt you for the root directory/ies of your solution, and all the files in and under those directories will be indexed. (Source Search doesn't parse your solution to find your files, because often there are interesting files that aren't a part of the solution - ChangeLogs, documentation, header files, etc.)
If you have multiple solutions that use the same source tree, you can use Open to open an existing index and associate that index with this solution. (See also Secondary Indexes below.)
Once a solution has an index, indexing happens automatically, first when you load your solution, and then when any of the files under your chosen root folders are changed (even if they are changed outside of Visual Studio). The indexer is non-invasive - it runs in a low priority background thread, pauses when you interact with the search box or the search results, and throttles itself while you're interacting with your PC.
Irrelevant files like binary files and output files are excluded from the index. Binary files are excluded automatically, and there's a configurable list in More / Options of text file extensions, and directories, to exclude.
Once indexing is under way, you can start searching as soon as you like. Even if not all of your files have been indexed yet, you can search those that have. While the index is incomplete, you'll get a warning.
At the right-hand end of the toolbar is a status pane, which tells you what the indexer is doing. It can say:
By hovering over the status text, you can get a bit more detail, in a tooltip:
The queued figure tells you how many files have been found that are either not in the index or out of date. As new or out of date files are found, this figure will increase, up to about 10,000, at which point the scanner will pause so as not to use too much memory for the queue, so you won't see this figure go much above 10,000.
The indexed figure tells you how many files have been indexed since this scan started. That figure steadily increases as files are taken out of the queue and added/updated in the index.
The index properties dialog lets you control the root directories, index-specific inclusion and exclusion patterns, and directory mapping for your index:
The global Source Search options (see Global options) specify the default inclusion
and exclusion patterns, but you can override them for a specifc index here - for example, if you have solution that has some data files
.map extension that you want indexed, but your global options exclude
Directory mappings let you share indexes between machines, where each machine sees the source files in a
different place - one machine might see it on its own disk as
C:\checkout whereas another might see it on a network
\\server1\share. This is most useful with secondary indexes - see below.
The final option is whether to open the index read-only. This is again most useful with secondary indexes - a secondary index might refer to code that never changes, like a third party library, so there's no need to spend cycles scanning it for changes. Or it might live on a network drive to which you don't have write permission (in which case, if you try to open the index for update, Source Search will ask you whether you'd like to open it read-only instead).
Some projects are made up of a core piece that you're working on, plus other pieces around that. Take Source Search itself for example - it uses Lucene.Net behind the scenes. As a developer working on Source Search, sometimes I want to include the Lucene.Net sources in my searches, and sometimes not.
Also, the Lucene.Net sources rarely change, so there's no need to scan them for changes. It would be good for that index to be read-only.
In a large organisation, you might even keep these shared sources and the corresponding index on a network drive, where the whole team can access them. They would have read-only access, and the server machine would keep the index up to date as necessary - Source Search is fine with one machine writing to an index while others are reading it.
You can use the "More / Open a secondary index..." command to open a secondary index. You can then choose from all the indexes on your PC, or use the "Browse for an index..." button to open one from elsewhere. Source Search remembers which secondary indexes you've opened for each of your solutions.
When you have multiple indexes open, the results from all of them are combined when you search.
Use the "More / Manage indexes..." command to show the Manage Indexes dialog:
From the Manage Indexes dialog, you can:
Under normal circumstances, your index will be kept up to date with your sources automatically, by two mechanims:
But sometimes you want to manually make sure that everything is up to date, and you can do that using the "More / Force index refresh" commands. There are two of these; "changed files only", which will skip any file that looks up to date (based on its timestamp) and "all files", which re-indexes all files whether they look like they've changed or not.
As well as indexing your code from within Visual Studio, you can create and update indexes from the command line - see the section on the Source Search command line tool, ess.exe.