What are projects and solutions - Visual Studio Tutorial

- [Instructor] You can't work in Visual Studio without encountering the solution and project concept. They are fundamental to the way a visual studio loads and compiles projects. I'll explain the core concepts of these essential items in this video. The Visual Studio solution is essentially a file on your computer with an .sln extension. This file serves as an entry point for your workspace. When you begin coding, you open the solution file. Inside the solution file, you'll find two key pieces of information, the minimum version of Visual Studio required to open the solution, and the preferred version. This is especially useful if you have multiple versions of Visual Studio installed. For example, if you're working with a Visual Studio 2022 solution, it will open in Visual Studio 2022, while other solution files will open in their corresponding IDE versions. Also included in the solution file is a list of projects. When you open a solution file in Visual Studio, it loads all the included projects into the IDE, and displays them in the Solution Explorer. The solution also manages dependencies between the projects, ensuring that they are built in the correct order. To repeat, when you open a solution in Visual Studio, it automatically loads all the included projects. You can also open individual projects instead of the entire solution file. For example, .csproj files are for C# projects, .vbproj files are for Visual Basic projects, .fsproj files are for F# projects, and .vcsproj files are for Visual C++ projects. When you open an individual project file, Visual Studio also loads the associated solution file, which means it'll open all the related projects. If there's no existing solution file linked to the project, Visual Studio will automatically create one. Essentially, whether you open a project, or a solution file, Visual Studio always works with a solution context. Here's a sample of the text content of an SLN file, which I've cleaned up to make it more readable. The VisualStudioVersion entry indicates that this solution was created in version 17.10, which means it's in Visual Studio 2022. When you open the file from the File Explorer, it will automatically launch in Visual Studio 2022 if it is installed on your system. The solution is compatible with older versions of Visual Studio, going back to Visual Studio 2010, that's indicated with the MinimumVisualStudioVersion entry. So, if a team member doesn't have Visual Studio 2022, they can still open it in an older edition. Next, in the file, you'll find two project entries, one for the MainApp project, and the other for the ToolsLib project. Each entry includes the relative path to its project files, enabling Visual Studio to locate and access these files easily. Naturally, the defaults are overridable. If you have Visual Studio 2019 and Visual Studio 2022 on the same computer, you can choose to open the solution with either one. Now that we've examined the solution, let's talk about the projects. What exactly is a project anyway? It is a container for everything needed to compile a separate code executable or library. Naturally, that includes code files, for example, C#, Visual Basic, C++, or JavaScript files. It also includes binary files, like icons, images, and music files. There might be data files in the project, for example, a JSON file containing configuration information for your application. Plus, you'll find lots of content files, for example, text files, HTML pages, CSS documents, and XAML files. And each project will contain a unique list of items. Let's explore how Visual Studio uses the contents of the project file. Understanding this helps clarify what happens behind the scenes when you edit and compile code. The project file guides two main actions. There's the load action and the build action. The load action occurs when you open the project in Visual Studio. It loads the project structure, references, and settings into the IDE. The build action happens when you prepare the application for debugging or release. It includes compiling the code, packaging, testing, and other necessary steps to produce a runnable application. When Visual Studio opens a project file which is encoded in XML format, it parses the contents and displays them in various tool windows. In the Solution Explorer, it shows all the files and folders defined in the project file. In the reference section, you find information about the reference libraries and packages. This is also shown in the Solution Explorer. Class view displays the structure of classes, and their members, as defined in the project. The key point is that everything visible in these tool windows is derived from the project file. When you add a new file to the project, the project file is automatically updated to include this change. Equally important, the contents of the project file is used by the build engine, which, in the case of Visual Studio, is MSBuild. The build engine is responsible for transforming our source files into a final product, such as executables or libraries. The project file contains compiler instructions and all the build settings for the project. When you build your project, the MSBuild engine uses this file to generate the executable. You can also define additional tasks to run before or after the compilation step. For example, you might run a batch command, or PowerShell script, before compiling, or execute automated tests and deploy to a pipeline after the build is complete. While Visual Studio relies on MSBuild, you can also run MSBuild independently by invoking MSBuild.exe, or using the .NET CLI commands. But the key concept is that the build instructions are contained within the project file itself. DevOps is rapidly replacing the old desktop build system. Azure DevOps can use the contents of the proj files directly, it leverages the MSBuild system, which means it can interpret the build instructions, dependencies, and settings defined in your project file. You can also configure additional build steps or tasks in the Azure DevOps pipeline, but the core compilation and build process will rely on the information in the project file, ensuring consistency between your local build on your developer computer, and the CICD pipelines. Here's an example from a WPF .NET project file. Typically, you won't need to manually check this content, because it's automatically generated by Visual Studio Tools. This section of the XML lists some of the .NET assemblies that the project references. On the right, you see a screenshot of the Visual Studio Solution Explorer. Focus on the References section. It shows all the references required by the project for a compilation. Notice the one-to-one match between the references shown in the Solution Explorer and the list in the project file. Let's finish and review what we've seen. A solution is a container for zero or more projects. Open a solution, and Visual Studio opens all the related projects. Build the solution, and Visual Studio ensures they are built in the proper order. All projects are part of a solution. If you open a standalone project, Visual Studio will create a temporary solution for that project. If you tried it and open a project that is already part of a solution, Visual Studio will open the solution instead. Real-world applications are built from a large set of business, libraries, services, and front-end applications, each of these application components can be a project in Visual Studio. As you can see, solution and project files are important, now it's time to see how they look in the Visual Studio Solution Explorer.