The original concept for the Visual Studio IDE was that the IDE would be a brand less, empty, extensible shell that hosted multiple products simultaneously. When the shell was empty, the title bar would display the generic name "Microsoft Development Environment." However, when the user was focused on editing assets that belonged to a project, the title bar would change to show the name of that product (for example, "Microsoft Visual Basic .NET," "Microsoft Visual C# .NET," or "<name of VSIP product>." Not only would the title bar name change but the Help.About command name would change to reflect the currently active product (for example, Help.About Microsoft Visual Basic .NET).

The Visual Studio IDE has a strong notion of tracking context and displaying only the appropriate commands for the current context. Thus, when the IDE is focused on a form or class file from a Visual Basic project, all the commands of the product are tailored to be appropriate for a Visual Basic project. The commands for the C++ project disappear. The changing title bar was part of the feedback the IDE provided to help the user understand what context is active. The name of the empty IDE was "Microsoft Development Environment" because the application was focused on being a great tool for developer activities. The application’s executable file became a derivative of the generic IDE name "Microsoft Development Environment" or "Development Environment," or "devenv" for short.

The concept for the generic environment even precedes the Visual Studio IDE time frame. The Visual C++ IDE was named msdev.exe for a similar reason as devenv.exe. It was conceived as a general IDE platform that could host multiple plug-in products, based on Microsoft Foundation Class (MFC) extension dynamic-link libraries (DLLs). Visual InterDev also shipped using this generic environment.

The next-generation IDE shell, known today as the Visual Studio IDE or devenv.exe, was based on a COM plug-in architecture, which enables independently versioning components to communicate with one another. This new IDE was created by using the Visual Basic shell and stripping out all the product-specific functionality. Then Visual Basic .NET had to be re-created in this new IDE as a package, even though it was their original IDE to begin with.

Starting in Visual Studio 2005, a stronger branding identity was given to the Visual Studio product. The title bar was updated to display "Microsoft Visual Studio" all the time. The Help. About command was changed to the static text Help.About Microsoft Visual Studio. Despite these branding changes, the executable’s file name remained the same.

It is an infinity symbol. I had great hopes it would turn out to be a Möbius strip.

The colors in the logo are the Microsoft corporate colors.

This was one of the big debates of the day.

In Microsoft Visual Basic, the Solution Explorer was on the right side of the IDE. In Microsoft Visual C++, it appeared on the left side. Both groups of developers were very used to their layouts after so many versions and wanted to retain their legacy layouts.

While the Visual Studio team was merging all the shells into the one IDE during the Visual Studio .NET 2002 product cycle, the decision was made to have the Solution Explorer appear on the right side of the IDE. I started my career at Microsoft toward the end of the Visual Studio .NET 2002 product cycle, so I wasn’t able to witness any of these debates firsthand.

This was the big debate.

Visual Basic had project groups, and Visual C++ had .dsw files or workspaces. In Visual C++, a workspace always existed, even if it consisted of just one project. Additionally, you could also open any random file in Visual C++, unlike in Visual Basic.

The big debate when the single IDE was being formed was which behavior to use. It was agreed to go with the Visual C++ approach on the condition that a new name would be used to describe this concept. And hence, a "Solution" was created.

A little-known fact that surprised me while chatting with Pat is that we actually put support into the UI for using a string other than the word "Solution," such as Workspace or Master Project. It was originally inserted for testing purposes, and we shipped the product with it at least once. I’ve been unable to figure out which version included that or to create a screen shot of the UI, as it has since been removed.

Recall in Chapter 4 how you can put a tool window into a tabbed document state, so that it appears among the open files in the file tab channel. But, you can’t move or dock an open file outside the file tab channel like you can with a tool window.

When the notion of tabbed documents was introduced in Visual Studio 6, it was intended to be a way to easily manage many open files. The original design actually provided a way for tool windows and document windows to dock to each other in a free-form way. In other words, you could dock tool windows to specific documents and create all kinds of configurations.

The problem with this design was that tool windows are not multi-instance, meaning you cannot have the same tool window open multiple times. Users would close documents and lose any docked tool windows. It was difficult to find these tool windows again to reopen them.

The user-experience designers created a rule that only files and tool windows in the tabbed document state could appear in the file tab channel. Tool windows could dock anywhere as long as they were in the dockable state, but files could not be docked. To help reinforce the difference, tool window tabs are displayed at the bottom of a tool window group, and file tabs are displayed at the top of the file tab channel.

This is a known issue. Only the root folder should contain a version number.