Even though Visual Studio 2008 has been released for over a year and 2010 is already in CTP, there is still quite a bit of development that happens on Visual Studio 2005.  Most developers know that Visual Studio 2005 (devenv.exe) needs to run with Administrator privileges in Windows Vista.  Modifying the shortcut for Visual Studio 2005 once can take care of that. 

If you are a “launch Visual Studio and then select the solution to load” type of person, this configuration will do just fine.  However, if you are a “double-click the solution file in windows explorer” type person you might have noticed something lacking for VS2005 solutions.  In Vista, by default, double-clicking on a Visual Studio 2005 solution file does – well – absolutely nothing.  Unless you count the brief swirl of the hour-glass replacement.

The reason for this is the program that is executed when double-clicking on a solution file is the Visual Studio Launcher.  The sole purpose of the Visual Studio Launcher, as far I can tell, is to launch the correct version of Visual Studio based upon the metadata found in the solution file.  Since Visual Studio 2005 needs to run as Administrator, the Visual Studio Launcher will need to run with the same privileges in order to launch it.

You will find the launcher at<Program Files>\Common Files\microsoft shared\MSEnv\VSLauncher.exe.  Right-click on the that file and set the file to run as Administrator.

Afterwards, double-clicking on a VS2005 solution file will launch the IDE as expected.

Visual Studio, by default, displays a splash screen at startup.  The splash screen displays branding information for Visual Studio and also includes information (if supplied) for all packages installed.

This information can take time to display and many developers do not wish to see this each time Visual Studio is started, preferring instead to get right to the job at hand.

The display of the splash screen can be turned off by passing the /nosplash parameter to devenv.exe.  The shortcut for Visual Studio can be modified so this happens automatically.

Some developers have told me they see up to a 10 second difference.  The difference on my machine seems like a second or two at most but your mileage will vary based on the speed of your machine.  At a minimum you can skip it if you are not interested in seeing it any longer.

For those of you that have downloaded the Visual Studio 2010 CTP, you might have noticed that it will expire within a few days.  The fix for this is simple and Jeff Beehler has a good post that is easy to follow.  In case you missed it from the link blog, here it is:

http://blogs.msdn.com/jeffbe/archive/2008/12/09/dealing-with-the-team-system-2010-ctp-expiration.aspx

You need to de-couple the system clock on your machine from the system clock in the VPC image. 

This is a quick tip that I only noticed recently.  Visual Studio has the ability to save the contents in the Find Results tool window to a file.  When the Find Results tool window has focus, select File – Save Find Results from the Visual Studio main menu.

Unfortunately, this is not available for the Find Symbols tool window.  My guess as to why this would be is that the Find Symbols tool window contains images as well as text but this is just a guess.

By the way, the Output tool window has the same functionality which also comes in handy from time to time.

On the MSDN forums, I see many questions on how to reset either the menus or the visible commands in Visual Studio.  A related issue I see quite a bit is how to correct problems that occur when a Visual Studio package has not installed/uninstalled properly.  The following 2 tips fix these issues for most people.

Resetting your environment back to the beginning

From the main menu, select “Tools – Import and Export Settings…”.  The last radio button gives you the option to reset to the default settings.

After selecting this option and pressing Next, you are given the option of saving your existing settings to a file (which can later be importing using the second option on the Import and Export Settings dialog above.

Finally, you are given the option to select the new environment settings.  Afterwards, any commands that have gone missing from your original environment or any strange window docking settings should be back to normal.

devenv.exe /setup

Running the command “devenv.exe /setup” causes Visual Studio to re-merge all windows and command settings for packages that have been installed.  If a Visual Studio package has not installed/uninstalled properly, I have had good luck correcting problems with my environment by running this command.  At the very least, it is a good option to try before reinstalling Visual Studio.

Running the command is easy.  Open the Visual Studio command window (Start Menu – Visual Studio 2008 – Visual Studio Tools – Visual Studio 2008 Command Prompt) and run devenv.exe /setup.  The command could run for a few minutes (or even several minutes).  The length will be determined by how many and which packages you have installed. 

Hopefully these two options might help you solve weird Visual Studio environment problems that you come across and prevent you from having to reinstall the IDE (saving time is a good thing).

When developing Visual Studio Add-Ins, one of the first handy tips you will need is /ResetAddin.  The syntax goes like this:

devenv.exe /ResetAddin <namespace.addinclass>

This command will remove all registered commands for a VS add-in and will remove any tool window settings as well.  The problem is that occasionally this will not remove everything you need.  One example of this is when an exception is thrown from a command handler all the way back to Visual Studio.

This is very bad form for an add-in developer, but it usually happens early in your development process at least once or twice and Visual Studio will effectively quarantine your add-in.  I’ve run across a few instances where /ResetAddin would not fix the situation and I had to take the following steps to get the add-in to run again:

1. Remove your .addin file and add-in assembly from the install location (This is usually “Documents and Settings\User\My Documents\Visual Studio 200x\AddIns” for most people during development on XP).
2. devenv.exe /ResetAddin <namespace.addinclass>
3. Start Visual Studio without replacing your add-in files and then shutdown Visual Studio.
4. Replace your .addin file and add-in assembly and startup Visual Studio as usual.

Additionally, you should add the appropriate exception handling code to your command handler before proceeding so you won’t have to repeat this again but following the above steps should get everything back to normal.

There are a few hidden gems in Visual Studio that are easy to overlook.  One of those is the Code Definition Window (ctrl+\,ctrl+d or View – Code Definition Window).

The Code Definition Window will work in two different ways.  The first is with your current code editing window.  As you navigate your code, the Code Definition Window will display the definition of the objects currently under your cursor.  For instance, if your cursor is currently over a class level variable, the Code  Definition Window will display the location in the source file where the variable is declared.  The same goes for methods and classes both within the current source file and in other source files within your current solution.

The second way the Code Definition Window can work is in conjunction with the Visual Studio Class View Window (ctrl+shift+c or View – Class View).  The Class View Window is a handy tool window in its own right, giving a quick overview of the object model of the current solution and allowing fast navigation through namespaces, classes, and methods.  If you double click on a method in the Class View Window, Visual Studio will open the appropriate source code file and scroll to that particular method.  This is quite useful for larger projects and for projects that might have multiple class definitions in each file.  However, if you single click on a method, the contents of that method will show in the Code Definition Window without opening the file in a text editing window. 

I hope this tip helps you out and adds another tool to your Visual Studio code editing arsenal.

If you are like me, the wizards provided by Visual Studio usually get ignored shortly after you learn the details of developing a given project type.  The downside of that is that I might be giving up some little tidbits that the templates take care of for me and are easy for forget.

It seems that when I start development of a new Visual Studio Add-In project (without using the conveniently supplied templates) I always forget one thing and get the following error the first time I deploy:

If you are using C#, the No such interface supported error might make you think immediately of a .Net interface type that Visual Studio is looking for and you have not implemented.  I have spent a good deal of time trying to find the problem in my code, when actually the solution is quite simple and is not even in my code at all.

Visual Studio is not a .Net application.  It is a native application and exposes its extensibility via COM.  The interface that Visual Studio is complaining about is not a .Net interface, but rather a COM interface.  Specifically, the IDTExtensibility2 COM interface. 

I never seem to have a problem remembering to implement IDTExtensibility2.  After all, this interface is the core interface for Add-In development.  The one thing I always forget is to make the assembly that implements this interface COM-Visible.  In case you have not had to deal with COM interop, this is easy to do and is accomplished via the Assembly Information dialog box (Application tab for the Project Properties).

If you do not mark your assembly as COM-Visible, Visual Studio will not be able to find the IDTExtensiblity2 interface.  Hence the dreaded “No such interface supported” error message.

A few months ago, I posted an article on my blog explaining Versioning Multiple Assemblies by changing one partial AssemblyInfo file.

Periodically, I get email asking how to add an existing file without having Visual Studio copy the file into the project directory, which is the default behavior.

If you want to add an existing file to a project and have the project point to the file where it resides, press the little arrow key on the right side of the add button on the add existing dialog.  The arrow will present a small context menu that allows the option of adding the file as a link, which will cause the Visual Studio project to point to that file where it is instead of copying it to the project directory.

-Darren

One thing that has constantly annoyed me with SQL Server Management Studio is the My Projects folder (which is often the default folder when opening or saving files) is set to \My Documents\SQL Server Management Studio\Projects and there appears to be no way to change it. If you go into Tools -> Options you won’t find anywhere that you can change this setting.

SQL Server Management Studio (SSMS) uses the Visual Studio Shell, so there has to be a way to change these settings, just not through the UI. The settings are stored in an .vssettings XML file in My Documents\SQL Server Management Studio\Settings folder. Make sure you close SSMS before making changes to this file, SSMS writes to it when you close the application and will overwrite any changes you make. To change the My Projects folder you are looking for this line:

<PropertyValue name="ProjectsLocation">%vsspv_user_documents%\My Projects</PropertyValue>

The value inside is the location of the "My Projects" folder. Simply change the value, and the next time you open SSMS the "My Projects" folder will be mapped.

If you peruse this file you will see many other settings you can change, I would just caution you to make a backup of the file before changing too much.

-James