SLN文件格式[通俗易懂]

大家好，又见面了，我是你们的朋友全栈君。

Visual Studio开发套装进入.net时代后，使用解决方案文件Solution（后缀为sln的文件）表示一个项目组，他通常包含一个项目中所有的工程文件信息。了解sln文件格式，可以手动修改错误的sln文件，也可以对解析sln文件有帮助。

以下就Visual Studio .Net 2003的sln文件说明其格式。

sln文件是一个文本文件，虽然它没有用最流行的XML文件表示，但数据结构却类似于XML文件，基本上也是由节组成，一个节由标记和End加标记来限定，比如说工程信息的标记为Project，那么他们由Project和EndProject来限定。每个节可以有自己的属性，并且节内部可以再嵌套子节。子节的名称由标记加section表示，然后在名称的后面加上一个小括号，其中记录这个子节的意义，比如表示工程依赖关系的子节就是ProjectSection(ProjectDependencies)。子节也可以有属性，但是子节的属性都是由一个等式表示。

一个sln文件通常由三部分组成：

1．  文件版本。在Visual Studio .NET 2003中是这样的一句话：

2．  工程信息

工程信息包含了解决方案中有哪些工程组成和他们之间的相互依赖关系，每个工程信息都是单独由Project和EndProject所包括，见下面这个例子：

Project有三个属性，由逗号分成三个部分：

第一部分 (“{8BC9…C942}”) = “Qb”，表示工程名称，“8BC9…C942”是固定值，等号后面是工程名称。大部分情况下，工程名称和工程文件名相同。

第二部分是工程文件，它是解决方案文件的相对路径。

第三部分是工程的GUID，解决方案通过这个GUID识别工程。在后面的依赖关系和编译配置中都会用到。

工程信息中的子节用ProjectSection表示，括号内的标记ProjectDependencies表示该工程的依赖工程。这个子节的属性就是依赖工程的GUID，等式两边的GUID是相同的，有多少个依赖工程，就有多少行的GUID等式。

3．  全局设置

全局设置的标记是Global，通常对我们比较有用的子节包括SourceCodeControl，SolutionConfiguration和ProjectConfiguration。

l         SourceCodeControl记录了解决方案在SourceSafe中的信息。

首先是Scc的基本信息，通常有四行属性，如下：

注意，SccNumberOfProjects比所包含工程数多一个。

有时候，会多出两个属性SccProjectName和SccProvider，大多数时候没用，如下：

接下来，每四行都表示一个工程在SourceSafe中的信息，如下：

注意这些属性后面都带有一个数字标记这是第几个工程属性。

有时候，会多出一个属性SccProjectName，并且SccLocalPath也不是当前路径“.”，不过这些信息都没有太多用。

l         SolutionConfiguration记录了解决方案可用的编译版本。比如通常能看到的：

l         ProjectConfiguration记录了工程可用的编译版本，对于SolutionConfiguration中指定的某些没有编译版本，则指定可替代的编译版本。比如：