|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Announcements
Chapters
Services
Feature Zones
|
IntroductionThis tool is a simple search utility I developed to search all my source code, regardless of language. The tool integrates with Visual Studio 2008, so you can kickoff a search while writing code. The utility will search any directory for files that match the extensions specified, and it will match search strings (supports Regular Expressions) inside the matched files. Results are presented in a clean treeview format, and allows you to take various actions with the results. BackgroundI spend around 80% of my day in front of a computer screen writing code for customers, and a lot of that time is spent digging through old code that I've written in the past, trying to remember how I solved a problem previously so I can implement the solution in a current project. I wish I could put a precise time value on this exercise, but the closest value I can come up with is a lot. I determined early on that I needed a GREP type application that I could use to search a large directory hierarchy containing thousands of source files. There are a lot of Windows Grep programs out there, and I tried a few of them (the ones that were free). Ultimately, it proved too tedious and cumbersome to use many of them for my needs, and there were some features I really wanted specific to Visual Studio IDE programmers, such as the ability to open a *.sln solution file for a matched code file, that just isn't possible in a switchblade (one size fits all) type Grep-ping application. Visual Studio's Find In Files OptionOf course, Visual Studio already provides a robust search feature (CTRL+SHIFT+F) which allows you to search for patterns in files based on extensions and user defined search strings. The functionality of this tool mimics the functionality of the Visual Studio feature, but adds some additional options like the ability to (try to locate and) open the .sln file associated to the matched code file, and the ability to open the folder containing the matched file. This tool can search and match patterns against file names as well as match patterns in files. Thanks Drew Stainton for this tip: You can further customize the behavior of the Find in Files Visual Studio function by editing Visual Studio's Registry settings: Customize your Find in Files Results experience!. Usage Outside of Visual StudioThis solution plugs into Visual Studio as an added feature, so you can launch it while working within Visual Studio, but it's not dependent on Visual Studio in any way. It can be run on its own, and can be used for searching any code (or any file readable in Notepad, for that matter). I've used it quite a bit to search in VBScript, batch, and Perl scripts as well as for searching file server log files. Project GoalsThe ultimate goal of the project is to significantly reduce the effort required to look through code files. The solution needs to search the file system as fast as possible and present a simple output that the user can interact with. In summary:
Matches need to allow these behaviors:
To Index or Not To IndexThis is a question I have toiled over for quite some time. If I index all the files in a location, then the search results would be instant. This would make users very happy, but it would add a lot of overhead to the solution. Ultimately, I decided, for this utility, every search would be real time, and all actions would be conducted at the time of the search instead of indexing prior to execution. Search MethodologyThere are a lot of ways we can perform a search. In the past, benchmarks seemed to indicate that using: string[] myFiles = Directory.GetFiles(USER_PATH, FILEMASK, SearchOption.AllDirectories);
was considerably slower than using the command line function: c:\>dir /S /B USER_PATH\*.FILEMASK > ApplicationAppDataDirectory\cache.txt
However, I'm not so certain of this anymore. I have run a series of completely unscientific benchmarks on these two scenarios. Scenario A: Command.com dir Function
Scenario B : Directory.GetFiles
These benchmarks were run on a Vista machine with 3GB of RAM and a Q6600 Quad-Core Processor. As you can see from the statistics above, the results slightly favor running the DIR command over
However, in all fairness, it doesn't really make sense to have As it stands right now, I have depreciated the DIR search functionality while I'm testing all the ways to use The CommandLine engine is housed in a class called CommandLine.cs, and minus all the abstraction members (fields, properties, constructors, etc.), it looks like this: private void DoShellExecute()
{
ProcessStartInfo psi =
new ProcessStartInfo(m_ApplicationPath, m_ApplicationParameters);
psi.UseShellExecute = true;
psi.RedirectStandardOutput = false;
psi.CreateNoWindow = true;
psi.WindowStyle = ProcessWindowStyle.Normal;
if (ExecuteType == ExecutionType.SHELL_EXECUTE_HIDDEN)
psi.WindowStyle = ProcessWindowStyle.Hidden;
Process p_exec = new Process();
try
{
p_exec = Process.Start(psi);
if (m_TimeOutThreshold != null || m_TimeOutThreshold == 0)
{
p_exec.WaitForExit((int)m_TimeOutThreshold);
}
else
{
p_exec.WaitForExit();
}
}
catch (SystemException e)
{
m_Error = e;
}
finally
{
p_exec.Close();
}
}
On the other hand, the /// <summary />
/// Creates the index of the user defined root path
/// </summary />
public void CreateIdx()
{
foreach (string f in m_uso.filters)
{
try
{
m_idx.AddRange(Directory.GetFiles(
m_uso.path, "*" + f,
SearchOption.AllDirectories));
}
catch (UnauthorizedAccessException e)
{
System.Diagnostics.Debug.WriteLine(e);
}
}
//m_idx.Reverse();
m_SearchedCount = m_idx.Count;
SearchResults(m_uso.pattern);
}
Adding to Visual Studio 2008Included with this article is the source code as well as the binary application files. If you wish to add this application to the Tools menu in Visual Studio 2008, extract all the files in the VS2008 add-in zip file into the Addins folder in your Visual Studio user path (c:\Users\You\Visual Studio 2008\Addins).
As noted earlier, there is no dependency on Visual Studio, so you can just run the .exe to run the program on its own. ConclusionTo this point, I'm extremely pleased with the results of this project. I find myself using this search tool constantly throughout the day, and it makes my day to day tasks much easier. Having used it for several days now, I'm looking into indexing to a server, and the possibilities that may open up for finding code blocks. History
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
News 
Question 
Answer 
Joke 
Rant 
Admin