One of the most appreciated blogs I have written has a very simple topic. It's called, "Where did the solution in Solution Explorer go?" The .NET 3.0 update to Microsoft Visual Studio included a minor change that hid the "solution" in Solution Explorer by default. It confused me for a few moments so I thought others might have the same question. The blog got several times the usual number of comments, most thanking me for pointing this out.
The whole topic of projects, solutions, and the files and tools that control them is something that is seldom explained. That's what this Quick Tip is about. Let's cover the background information first.
In .NET, a solution consists of "one or more projects that work together to create an application" (from Microsoft). The primary difference between different templates in in the "New > Project" menu in VB.NET is the types of files and folders that are automatically created in a solution. When you start a new "project" in VB.NET, you are actually creating a solution. (Microsoft has evidently decided that it's better to continue to use the familiar name "project" in Visual Studio even though it's not quite accurate.)
One of the big advantages of the way Microsoft has designed solutions and projects is that a project or solution is self contained. A solution directory and its contents can be moved, copied, or deleted in Windows Explorer. A whole team of programmers can share one solution (.sln) file; a whole set of projects can be part of the same solution; and the settings and options in that .sln file can apply to all of the projects in it. Only one solution can be open at one time in Visual Studio, but a lot of projects can be in that solution. The projects can even be in different languages.
You can get a better understanding of just what a solution is by creating a few and looking at the result. A "Blank solution" results in a single folder with just two files: the solution container and the solution user options. (This template isn't available in VB.NET Express.) If you use the default name, you'll see:
Solution1 -- a folder containing these files: Solution1.sln Solution1.suo
Click Here to display the illustration
The main reason you can create a blank solution is to allow project files to be created independently and included in the solution. In large, complex systems, in addition to being part of several solutions, projects can even be nested in hierarchies.
The solution container file, interestingly, is one of the few text configuration files that isn't in XML. A blank solution contains these statements:
Microsoft Visual Studio Solution File, Format Version 11.00 # Visual Studio 2010 Global GlobalSection(SolutionProperties) = preSolution HideSolutionNode = FALSE EndGlobalSection EndGlobal
It might as well be XML ... it's organized just like XML but without the XML syntax. Since this is just a text file, it's possible to edit it in text editor like Notepad. For example, you can change HideSolutionNode = FALSE to TRUE and solution won't be shown in Solution Explorer anymore. (The name in Visual Studio changes to "Project Explorer" too.) It's fine to experiment with things like this as long as you're working on a strictly experimental project. You should never change configuration files manually for a real system unless you know exactly what you're doing, but it's fairly common in advanced environments to update the .sln file directly rather than through Visual Studio.
The .suo file is hidden and it's a binary file so it can't be edited like the .sln file. You will normally only change this file using the menu options in Visual Studio.
Moving up in complexity, check out a Windows Forms Application. Even though this might be the most elementary application, there are a lot more files.
Click Here to display the illustration
In addition to a .sln file, the Windows Forms Application template also automatically creates a .vbproj file. Although the .sln and .vbproj files often useful, you might notice that they're not shown in the Visual Studio Solution Explorer window, even with the "Show All Files" button clicked. If you need to work with these files directly, you have to do it outside of Visual Studio.
Not all applications need a .vbproj file. For example, if you select "New Web Site" in Visual Studio, no .vbproj file will be created.
Open the top level folder in Windows for the Windows Forms Application and you'll see the four files that Visual Studio doesn't show. (Two are hidden, so your Windows options must be set to make them visible.) Assuming the default name again, they are:
WindowsApplication1.sln WindowsApplication1.suo WindowsApplication1.vbproj WindowsApplication1.vbproj.user
The .sln and the .vbproj files can be useful for debugging difficult problems. There's no harm in looking at them and these files tell you what is really going on in your code.
As we have seen, you can also edit .sln and .vbproj files directly although it's usually a bad idea unless there is no other way to do what you need. But sometimes, there is no other way. For example, if your computer is running in 64 bit mode, there isn't a way to target a 32 bit CPU in VB.NET Express, for example, to be compatible with the 32 bit Access Jet database engine. (Visual Studio provides a way in the other versions.) But you can add ...
... to the <PropertyGroup ... "> elements in the .vbproj files to get the job done. (With enough tricks, you might never have to pay Microsoft for a copy of Visual Studio!)
Both the .sln and .vbproj file types are normally associated with Visual Studio in Windows. That means that if you double-click either of them, Visual Studio opens. If you double-click a solution, the projects in the .sln file are opened. If you double-click a .vbproj file and there is no .sln file (this happens if you add a new project to an existing solution) then one is created for that project.