SLN File Documentation

Summary

An .sln file is a Visual Studio Solution File, a plain-text manifest that groups one or more code projects together and records how they build and relate. Its MIME type is text/plain. It contains no source code itself; it just points to the project files (.csproj, .vcxproj, and others) by path and GUID. Open it by double-clicking it in Microsoft Visual Studio, or use the free VS Code with the C# Dev Kit or JetBrains Rider, which load the whole project. On its own it is just text you can read in Notepad.

Technical details

FeatureValue
Full nameVisual Studio Solution File
File extension.sln
MIME typetext/plain
Format typePlain-text project-grouping manifest (custom syntax)
DeveloperMicrosoft
Introduced1997 (Visual Studio 97)
EncodingUTF-8 with BOM
Open standardNo — Microsoft-specific syntax
First lineMicrosoft Visual Studio Solution File, Format Version 12.00
Contains source codeNo — only references to project files
Key structuresProject(...) blocks, Global / GlobalSection blocks
Project referenceType GUID + name + relative path + project GUID
Build config sectionSolutionConfigurationPlatforms, ProjectConfigurationPlatforms
Newer replacement.slnx (XML-based, VS 2022 17.10+)
Open withVisual Studio, VS Code + C# Dev Kit, JetBrains Rider, dotnet CLI
Related extensions.csproj, .vbproj, .vcxproj, .slnx, .suo
Specificationlearn.microsoft.com (solution .sln file)
Syntax at a glance

An .sln is UTF-8 text (with a BOM) identified by its first non-blank line, Microsoft Visual Studio Solution File, Format Version 12.00, followed by a # Visual Studio Version comment. The body is a custom, non-XML syntax of Project("{type-GUID}") = "Name", "Path\Name.csproj", "{project-GUID}" blocks closed by EndProject, plus a Global block of GlobalSection(...) = preSolution|postSolution entries that hold build configurations. It carries no source code, only references and settings.

What is an SLN file?

An .sln file is a Visual Studio Solution File, Microsoft’s container for organising a set of related projects. It has been part of Visual Studio since Visual Studio 97, and it is the top-level workspace a developer opens. A “solution” groups projects, say a C# class library, a console application and a test project, so they build together, reference each other and are managed as one unit. When you double-click a .sln, Visual Studio loads every project the solution lists.

The defining fact about an SLN file is that it holds no source code. It is a plain-text manifest of references and build settings. The actual code lives in the project files it points to (.csproj for C#, .vbproj, .vcxproj) and the source files those projects include, such as the individual .cs files of a C# project. This is why double-clicking a .sln and expecting a document to appear is confusing: there is nothing to view, only a workspace that an IDE assembles.

The format version header

An SLN file is UTF-8 text saved with a byte-order mark. It is identified, and versioned, by its first non-blank lines:


Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 17
VisualStudioVersion = 17.11.35208.52
MinimumVisualStudioVersion = 10.0.40219.1

The first line declares the file’s format version, which has stayed at 12.00 across many Visual Studio releases; the format itself has changed little. The # Visual Studio Version comment and the VisualStudioVersion line record which product wrote the file, which the IDE uses to pick sensible defaults. There is no binary magic number: the leading text string is the signature.

Project blocks: type GUID, name, path and project GUID

The heart of a solution is a set of Project blocks, one per project, each closed by EndProject. A block names four things:

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "MyApp", "MyApp\MyApp.csproj", "{5B9CCABF-2F7E-407C-ACD7-53C37BB859EE}"
EndProject

The first GUID, in parentheses, is the project type GUID. It tells Visual Studio which project system to load: {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC} is the well-known identifier for a C# project, and other languages and project kinds have their own fixed GUIDs. Then comes the human-readable project name, the relative path to the project file on disk, and finally the project GUID in braces, a unique identifier for this particular project instance. That second GUID is what the rest of the solution uses to refer to the project; the build-configuration sections map settings onto it by GUID, not by name, so renaming a project in the file does not break its configuration.

Solution folders, the grouping folders you see in Solution Explorer, are themselves stored as projects with a special type GUID and no path on disk, which is how a purely organisational folder fits into the same Project grammar.

Global and GlobalSection: build configurations

After the project blocks comes a single Global block containing several GlobalSection entries, each tagged preSolution or postSolution to tell the IDE whether to process it before or after loading projects.

Global
	GlobalSection(SolutionConfigurationPlatforms) = preSolution
		Debug|Any CPU = Debug|Any CPU
		Release|Any CPU = Release|Any CPU
	EndGlobalSection
	GlobalSection(ProjectConfigurationPlatforms) = postSolution
		{5B9CCABF-2F7E-407C-ACD7-53C37BB859EE}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
		{5B9CCABF-2F7E-407C-ACD7-53C37BB859EE}.Debug|Any CPU.Build.0 = Debug|Any CPU
	EndGlobalSection
	GlobalSection(NestedProjects) = preSolution
	EndGlobalSection
EndGlobal

SolutionConfigurationPlatforms lists the solution-wide configurations, the familiar Debug and Release crossed with a platform such as Any CPU or x64. ProjectConfigurationPlatforms then maps each solution configuration onto each project’s own configuration, keyed by the project’s GUID. The .ActiveCfg entry says which project configuration to use, and a matching .Build.0 entry marks whether that project is built when the solution is built. Other sections carry solution-level properties (SolutionProperties) and the nesting of projects into solution folders (NestedProjects).

SLN versus CSPROJ: two different files

A common confusion is treating .sln and .csproj as interchangeable. They are different layers. A .csproj (or .vbproj, .vcxproj) defines exactly one project: the source files it compiles, its references and NuGet packages, its target framework and its build settings. An .sln defines a grouping of one or more such projects into a workspace, plus the solution-level build matrix above. You open the .sln to work on everything at once, or a single .csproj to work on just that project. There is no conversion between them, because the solution does not contain the project; it references it. A project already exists on disk alongside the .sln that points to it.

The SLNX successor

Microsoft has introduced a newer solution format, .slnx, an XML-based replacement for the legacy syntax above. It does the same job, list the projects and their configurations, in a cleaner, more diff-friendly XML form, and Visual Studio 2022 (from 17.10) plus the dotnet CLI can migrate a .sln to .slnx with dotnet sln migrate. The classic .sln remains the format you will see in the large majority of repositories, so both are worth recognising.

Opening and building without Visual Studio

You do not need the full Visual Studio IDE to use a solution. Visual Studio Code with the C# Dev Kit extension detects and loads the .sln when you open its folder, and JetBrains Rider opens the file directly; both work on Windows, macOS and Linux, which matters because Visual Studio for Mac was retired in August 2024. You can also skip an IDE entirely and build from a terminal: with the .NET SDK installed, dotnet build MySolution.sln compiles the whole solution and dotnet run runs it. Because the .sln is plain text, you can even open it in Notepad to read or repair a broken project path, though it is easy to corrupt the GUIDs or sections by hand, so letting the IDE add and remove projects is safer.

References