Click here to Skip to main content
15,887,267 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I am using VisualStudio2010, and the problem I have refers to the "Find in Files" feature and dialog.

I have a directory structure on my computer that looks roughly like this:

long_path...\
   Working_copy_1\
      External_library_1_includes\
      External library_2_includes\
      External_library_2_source\
      Solution_main_directory\
         source\
         some_other_files\
         ...
   Working_copy_2\
      External_library_1_includes\
      External library_2_includes\
      External_library_2_source\
      Solution_main_directory\
         source\
         some_other_files\
         ...
   Working_copy_3\
      (you get the picture...)

The actual solution file (*.sln) is located within the source subdirectory, but some of the files of that solution are in fact in other subdirectories of the directory Solution_main_directory. But that isn't really the problem...

The problem I have is that every time I use "Find in Files" for the purpose of finding a symbol that is not within the actual solution files, I need to add various external directories that are relative to the solution file. However, when I set up a filter to include specific directories, they are always entered as absolute paths! Unfortunately, the filter settings seem to be stored independendly of the solution file, so, when I switch to a solution in another working copy, and use "Find in Files" there, then that filter is defined there as well. As a result, I've repeatedly run into the trap of using that filter, finding a file, opening it via the search results, and changing something - in the wrong working copy!

I've since tried to change the directory entries in the filter to relative paths, but it doesn't appear to work: it seems like the base directory being used is the installation directory of VisualStudio, not the Solution directory! :doh: Macros don't appear to be working either. But I'm not giving up just yet: for one I've found various registry entries under "HKCU\Software\Microsoft\VisualStudio\10.0\Find" : some of these entries do contain search strings I've used in the paths as well as directories I've defined in the filters. I haven't yet managed to find a definition of the base search directory, and I'm not sure whether and how I may use the predefined macros for that purpose.

Or maybe what I intend would be possible with the definition of an additional registry key that doesn't exist by default?

Does anyone have an idea how to go about this?


Before you answer, please make sure you don't repeat what I already tried without success:

1. Define a filter (enters absolute paths), then change the path entries to relative paths.
--> doesn't work because apparently the relative path starts at the VisualStudio installation path

2. As in 1., but using macros like $(SolutionDir)
--> directories defined that way appear to be ignored

3. Changing various directory type entries in the "Find" registry settings
--> doesn't seem to have any effect

4. Checking other paths in the registry
--> No other path contains the relevant "Find" settings

5. Googling for solutions
--> Somehow no one seems to be experiencing my particular problem, or dared to ask about it

6. Creating an individually named filter for each and every working copy
--> this would indeed work, but is rather inpractical due to the many copies and external directories, and due to the fact that I like to create individually named working copy directories every time I create a new branch, so I can distinguish it properly from the others! Therefore I would prefer a relative-path-solution any time.
Posted
Comments
Sergey Alexandrovich Kryukov 25-Feb-14 9:08am    
It this because you use some Revision Control System? What is it? To me, it looks like using wrong method. Why not executing separate instance of Visual Studio per working copy? Just a note: I think I have good reasons to never use any integration of Revision Control System and Visual Studio. I always keep VS agnostic to it and use revision control only externally.
—SA
Stefan_Lang 25-Feb-14 9:50am    
I need several Working folders because the only alternative would be always switching to whatever branch I need to work or test on. Several times a day, somtimes several times an hour. Due to project size, this simply isn't feasible - I'd lose half my production time just switching around.

It doesn't matter what or how we use Revision Control, or whether I use multiple instances of VS (I do). Just that I need to use relative paths exactly because I do want to keep VS agnostic of what is going on around it.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900