Don Box Commented about the fact that when he double clicks VS.NET associated files in his explorer, Those files are opened using a new instance of VS.NET, even though there is an existing instance of the editor. He also pointed out a way in which to make those files load within the active instance of the VS.NET. It is done by adding a simple suffix to the value of registry keys associated with those files in the registry.
However, This process is very cumbersome. So I decided to make a program solely for this purpose. This program can be customized to change a user defined registry key, and an xml list of files that will be changed. The user can also revert this process.
The configuration of which file types are to be changes in the registry is done using the FileTypes.xml file located in the program directory. Configuration of where to look within the registry for those files is done via the appSettings section of the app.config file. You are also able to see the current values of the keys mentioned before and after you change their value.
How it's done:
I'll quote Don here:
Tarek from the VS team just gave me the magic incantation to tweak the shell integration of VS.NET.
My problem has been that when you ShellExecute a source file (that is, double-clicking or using Start->Run), a new devenv.exe instance gets launched. Yes, VS.NET 2003 starts faster than 2002 did, but no where near fast enough to edit or view a simple file.
Here's the tweak to get ShellExecute to use an existing instance of devenv.exe (if one exists):
Change the following registry key:
@="\" C:\\...\\devenv.exe \ " /dde
@="\" C:\\...\\devenv.exe \ " /dde \"%L\"
If you are using the RegEdit.exe UI, this means finding the registry key and adding a "%L" after the /dde switch.
Also note that you need to do this for each file type you want to work this way. The specific key shown here is for .CS files. Fortunately, all of the file types are near one another in RegEdit.exe.
I found that on my computer, however, these locations appear at different keys:
and so on...
I show a simple use of the Registry Classes and not really much more. Really simple. This was made solely for the purpose of allowing you to configure your registry fast with the out-of-the-box mentions file types (such as cs or vb)
I must say that the problem does not occur on my computer, And also my registry keys do not hold the solution mentioned by don box, so I don't really know how it works without them, but it does (Perhaps it's because he is using VS.NET 2003 and i'm using 2002). That's why the changes to the registry are fully customizable and allow you to change where and what the actual values are.