Thoughts, Code, Other

Technical blog of Nik Smit

rainbow

Some quick tips to speed up Visual Studio and help you develop faster

If you work with Visual Studio all day long, at some point you've just wanted it to go just that little bit faster. Don't get me wrong, it's certainly not a slow tool by any means, but if you're working with the same tool all day long, even minor improvements can add up to a significant amount over time.

Adding as much RAM as you can afford, using 10000 RPM drives, and using a dual core processor are the best things you can do hardware wise (in that order). Turning off anti-virus software (if you dare), and physically separating your data and OS also goes a long way. These things are all very well documented elsewhere.

But there are others ways to get you out of the office earlier, that don't require pulling out your credit card.

Have a look at your habits and processes while developing - particularly the ones you repeat a million times a day. Investing a bit of time to improve these can yield some good ROI in terms of efficiency.

Keyboard shortcuts = Speed

Every function in visual studio is exposed as a command that you can bind to (right click any toolbar, customize, keyboard....). Take note of what you do most often, and ensure those commands are bound. Of course, obvious tasks like building your project should be mapped to something comfortable on your keyboard (I use Alt-1).

But you'll probably find that navigating your way around your mega-solution keeps requiring some mouse action. The more you keep your hands on the keyboard, the faster you go, so ensure you are aware of at least the following commands :

  • Edit.GoToDefinition (F12).
  • View.NavigateBackward ( cntrl -). Great for returning to where you were working before navigating to that definition
  • Drop Bookmark (cntrl-k, cntrl-k)
  • Go to next bookmark (cntrl-k, cntrl-n)
  • Open window list (alt-w, w). With many windows open, this dialogue is a lot quicker than cntrl-tabbing around, as you can jump to the correct file by using its first letter).
  • Go to code behind : F7
  • Go to visual designer from ode behind : Shift-F7 (Unless you actually use the visual html designer, dont use this - the rendering is too slow).
  • Go to html source view from visual designer (cntrl-pg dn)

Cntl-F can be sped up

Often you know exactly where you need to be in your file. There's a specific piece of text (probably a function name) that'll get you there quickly if you search for it with cntrl-F. I do this a million times a day. But with VS 2008 (and I think with 2005) bringing up that search dialogue takes about a second for no good reason. It really should be instant - if you do 300 searches in a day, that amounts to time for another cup of coffee. I would hope this is fixed in a service pack, but until it is, dock that dialogue somewhere. I dock it with my solution explorer (bring it back to the fore with cntrl-alt-l). With it docked, its never destroyed, and hitting cntrl-f just brings it to the foreground quickly.

Use aliases in the command window

I'd forgotten about this powerful feature until recently. All those commands above can be accessed from the command window. Call it up with cntrl-alt-a. If you've ever used the console in Quake, this is the same concept. All the commands are exposed for you to play with (use the intellisense!), so typing

File.OpenFile MyProject\Web.config

will unsurprisingly open web.config for you to edit (Intellisense is there for the filename too). While that may seem like a step backward in terms of speed, if you know the exact file you're trying to open, it can be a lot quicker to type that than navigating through a bunch of projects and folders. Plus, it gets better.

Any command can be aliased. So executing

alias o File.OpenFile

means we can now type

o MyProject\Web.config

to open that same file! We can go further though. Perhaps you have a bunch of files you need to access all the time. For me these include web.configs, the main css file, the main javascript file and so on.

Try something like this :

alias css File.OpenFile MyProject\content\style\main.css

(To delete that alias execute alias css /delete)

One could go wild here - I'm not trying to say alias everything. Just optimize those you're doing often (especially those that currently involve the mouse). Which brings me to....

Web developers! Bind a macro for attaching to the w3p process

Some web developers test their pages by hitting F5 and launching Visual Studio's built in Casini web server. I've never liked this approach:

a) I prefer to navigate around my site and then decide I need to do some debugging at that point (its taken a bunch of steps to get to this point)

b) I like the warm fuzzy feeling of knowing there are no surprises at deploy time, so would rather use IIS7 proper.

So the process is easy - just call up Visual Studio's "attach to process" dialog, find w3p.exe, attach, and you're in business. I think you can guess where I'm going with this - that just takes too long. Sometimes enumerating all those processes seems to take forever in the dialogue, which is kinda silly when you know the one you want.

The solution is to use a macro for this purpose, and bind it to a keyboard shortcut. You're attached in a second or two - lovely! Hit Alt-F11 to bring up your macro editor, and drop this into a new module.

 
Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports System.IO
Public Module Misc
 Public Sub AttachToFirstDevWebServer()
 Dim process As EnvDTE.Process
For Each process In DTE.Debugger.LocalProcesses
 System.Diagnostics.Debug.Print(process.Name)
 If (Path.GetFileName(process.Name).ToLower() = "w3wp.exe") Then
 process.Attach()
 Exit Sub
 End If
 Next
MsgBox("Could not find web server")
 End Sub
End Module
 

Note : if you are using the built-in server, you can still get the benefits of this, by swapping out "w3p.exe" for "WebDev.WebServer.exe" in the macro.

I'll be posting more on this topic in future. Until then, drop me a line if you have any cunning efficiency tips :)

4 Responses to “Some quick tips to speed up Visual Studio and help you develop faster”

  1. June 9th, 2008 at 1:32 pm

    Darksider says:

    Stop your Visual Studio from continuing a build if a project is broken i.e. Don’t compile the 40 other projects if the first one is broken.
    Darkside Article

  2. October 29th, 2008 at 6:59 pm

    Paul says:

    Hi, I took your attachment code and tweaked it for my needs. It will look for a w3wp process with a matching user name. I don’t know if it’s possible that more than one would exist. I’ve only seen one per user. Feel free to do whatever you like with it:

    Sub AttachToWebServer()
    System.Diagnostics.Process.Start(”tasklist”, “/FI “”Username eq bsi\Paul”" /FI “”imagename eq w3wp.exe”" /fo “”csv”" /nh”)
    Dim pid As Integer = Run(”tasklist”, “/FI “”Username eq bsi\Paul”" /FI “”imagename eq w3wp.exe”" /fo “”csv”" /nh”).Split(”,”)(1).Replace(”"”", “”)
    ”Dim process As EnvDTE.Process
    For Each DebugProcess As EnvDTE.Process In DTE.Debugger.LocalProcesses
    If DebugProcess.ProcessID = pid Then
    DebugProcess.Attach()
    Return
    End If
    Next
    MsgBox(”Could not find web server”)
    End Sub
    Private Function Run(ByVal path As String, ByVal args As String) As String
    Try
    Dim p As New System.Diagnostics.ProcessStartInfo(path, args)
    p.RedirectStandardOutput = True
    p.UseShellExecute = False
    p.CreateNoWindow = True
    p.RedirectStandardError = True
    p.RedirectStandardInput = True
    p.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden

    Return System.Diagnostics.Process.Start(p).StandardOutput.ReadToEnd()
    Catch ex As Exception
    Throw New Exception(”RunX: File: ” & path & ” - Exception: ” & ex.Message)
    End Try
    End Function

  3. October 29th, 2008 at 7:01 pm

    Paul says:

    Oops, the second line is unused. This one can be deleted:
    System.Diagnostics.Process.Start(�tasklist�, �/FI ��Username eq bsi\Paul�” /FI ��imagename eq w3wp.exe�” /fo ��csv�” /nh�)

  4. November 7th, 2008 at 5:12 pm

    admin says:

    Thanks Paul!