Jeff Abraham's WebLog

VS 2005/2008 have a dialog that shows up on first launch (the first launch dialog if you will) that asks you to choose a collection of settings (which we refer to as a profile) that describe the way you typically use the IDE. Depending on which profile you choose, you will get a different profile applied. The most visible signs are the different menu items (which are commands), window configuration, and keybindings.

If there are commands that you would like to add to a menu, but you are happy with the general configuration of the IDE, you can use Tools | Customize and simply drag the missing options onto the menu of your choice.

If you would like to reconfigure major portions of the IDE, you can use Tools | Import and Export Settings | Reset Settings to reset to an entirely new profile. You have the option of saving your current settings in the wizard before the reset occurs, so it's relatively safe to reset and figure out which profile suits you best. Keep in mind that you can also change your keybindings after reset (Tools | Options | Environment | Keyboard), so if you want the VC keybindings but the general window configuration you can reset to the general profile, and then set the keybinding option after the wizard runs.

The other option you have is to selectively import parts of a profile by running the wizard and instead of choosing Reset, choosing Import. Working your way through the wizard will eventually show you a treeview control that you can use to select hierarchies of settings to import.

Visual Studio 2008 Beta 2 is available. Go wild. http://msdn2.microsoft.com/en-us/vstudio/aa700831.aspx, linked from http://msdn2.microsoft.com/en-us/vstudio/default.aspx

Working on the Visual Studio Tool Platform team, we do a lot of work on making VS extensible and providing infrastructure for other teams to build on top of (some of our work is end user feature work as well, it's an interesting mix of things). We have to balance the exposure of the APIs and tying ourselves to one implementation. The key takeaway from the article for me was:

Why does such a confusing function exist at all? Well, the shell team thought they were doing you a favor by providing this function back in the 16-bit days. This was originally an internal function used by (I think it was) File Manager, but since it solved a more general problem, the function was exported and documented. In the intervening years, the problem it addressed has been solved in other ways, and the introduction of 64-bit Windows rendered the original solution unworkable anyway, but the function and the code behind it must still linger in the system for backwards compatibility purposes.

The shell team learned its lesson. It no longer exports every little helper function and custom control for third parties to use. If a future version of Windows no longer needs the helper function, or if a redesign of Windows Explorer removes the need for that custom control (or worse, changes the behavior of that custom control), the shell would still have to carry all the code around for the unused function or control because a function, once documented, becomes a continuing support burden.

Read the entire article here: http://blogs.msdn.com/oldnewthing/archive/2007/07/10/3799014.aspx

This is another one of those things that I forget all the time, so I'm posting here as a way of remembering (and because it's incredibly useful if, like me, you find windbg somewhat opaque).

http://msdn2.microsoft.com/en-us/library/a329t4ed.aspx

It's very convenient to be able to set this registry key and break into your application on startup, regardless of how it is launched, and even more convenient that you can use VS. Cheers!

Thanks to Phil Ottowell (I think I relearn this trick every two or three years, posting here so I have a chance to remember it):

 In VS add a breakpoint and specify the location as, for example
 
{,,compluslm.dll}DllMain
 
if you wanted to break when the compluslm.dll was loaded. For a specific function use the same syntax but specify the function name instead of DllMain.

Learn more about this syntax here:

http://msdn2.microsoft.com/en-us/library/wztycb7f.aspx

For those of you building applications with significant plugin architectures, this is definitely a blog to keep your eye on. http://blogs.msdn.com/clraddins/.

Yes folks, it's ready. Get it while it's still hot from the oven. http://msdn.microsoft.com/vstudio/support/vs2005sp1/default.aspx

http://blogs.msdn.com/ricom/archive/2006/12/11/avoiding-coding-pitfalls-with-performance-signatures.aspx

 This is a very interesting article, is it possible that something as simple* as IntelliSense can help you write faster code? Tag method signatures with 'light, medium or heavy' and then simply don't ever call a heavierweight method than the one you are implementing. It's a start. The really interesting part is that Rico hopes to be able to publish the signatures.

*Conceptually simple, IS is a pretty hard problem.

If you are experiencing slowness with saving files in VS2005, it may be related to opening files/projects stored an network locations. 

In any ASP.Net project, saving (or auto-recover) stalls Visual Studio for around 1 minute.  I’ve had to disable Auto-Recover to prevent being stalled for a minute in the middle of a thought, and fixing simple “ forgot a ; “ errors is incredibly tedious because the change must take a minute (though I did find that even though VS is frozen, I can load the page and the changes were made.)

 

This is not specific to the project, as I can open these sites on other systems and saving is fast and immediate.   I have already tried repairing VS2005, but to no effect.

 

Does anyone have any ideas on how I can fix this?  I’m frustrated enough to nuke the OS, but I have a feeling this will happen again, the problem has already spread to another system (possibly due to Roam Profiles).

The temporary workaround (I believe this is fixed in the upcoming service pack) is to use regedit to delete the network share locations from

HKCU\Software\Microsoft\VisualStudio\8.0\ProjectMRUList 

and

HKCU\Software\Microsoft\VisualStudio\8.0\FileMRUList

If you are using the Express Editions of Visual Studio  (e.g. Visual Basic Express, Visual C# Express) and having this issue you can follow almost the same steps, but you will need to change the VisualStudio part of the registry path to e.g. VBExpress, or VCSExpress.

As always, these locations are implementation details, and subject to the delightfully playful whims of the owner of the code. Don't depend on for anything.

Hope this helps, cheers!

I just found this link in email, and thought it would prove handy to you lucky MSDN subscribers who already have Vista: http://msdn2.microsoft.com/en-us/vstudio/aa948853.aspx

Lately I've been spending a lot of time on the upcoming service pack and Vista patch, and I think that you'll be happy with what we've fixed.

[Fixed link, Live Writer abbreviated it somehow]

There are a very large number of commands in Visual Studio 2005, and some of them operate in ways that are subtle, and quick to anger.

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=224080

If Build.BuildOnlyProject doesn't seem to do what you want, then you might want to look at rebinding to Build.BuildSelection.