VS2013 解决方案文件结构分析
2016-08-21 12:17
465 查看
http://www.cnblogs.com/haogj/p/4248030.html
Visual Studio 的解决方案文件是一个文本文件,其中的内容不是太复杂,有些时候 Visual Studio 会把这个文件搞乱,理解一下这个文件的结构,对我们处理一些异常情况有所帮助。
# 表示注释行
VisualStudioVersion:打开这个解决方案文件需要的 Visual Studio 版本号
MinimumVisualStudioVersion:能够打开这个解决方案的最低 Visual Studio 版本号。
下面是一个解决方案文件的示例。
Project( 项目在解决方案中的编号=显示名称, 实际路径, 项目唯一标识 )
项目唯一标识来自项目文件,在 ConsoleApplication22.csproj 文件中可以找到如下说明。
比如,在解决方案中创建了一个名为 NewFolder1 的解决方案文件夹。
在解决方案文件中就会多出来一个特殊的 Project。
所以,我们可以理解为什么解决方案文件夹不能嵌套了。
如果我们在解决方案文件夹中创建了一个项目。
项目的说明示例如下。
那么,在解决方案文件中中的 Global 节中,会多出来一个 GlobalSection(NestedProjects) = preSolution
你会看到前面是项目的标识,等号的后面就是解决方案文件夹的标识。这个嵌套的 NestedProjects 用来说明使用解决方案文件夹组织的项目。
可以看到有三个部分组成
整个解决方案的配置信息在 SolutionConfigurationPlatforms 中。
每个项目的平台配置信息在 ProjectConfigurationPlatforms 中。
项目的属性。
需要注意的是,这个多出来的配置节只能有一个,有的时候 TFS 会错误的多添加若干个,这时候,在打开项目的时候,你应该会看到如下的提示信息。
注意解决方案中实际包含的项目数量,多出来的 TeamFoundationVersionControl 配置节中项目数量一般不对。一般来说,保留第一个,将其他的删除就可以了。
下面是一个配置节的示例。
其中
SccNumberOfProjects 是说明在 TFS 管理之下共有多少个项目。
SccTeamFoundationServer:TFS 服务器的地址。
SccLocalPath0:源代码管理器的本地目录
具体解决方案中的项目再分别列出来,每个项目占 4 行。
SccProjectUniqueName1:项目的路径
SccProjectTopLevelParentUniqueName1:就是解决方案的名称
SccProjectName1:项目的名称,注意已经包含了项目文件夹前缀
SccLocalPath1:保存在本地的项目路径
Visual Studio 的解决方案文件是一个文本文件,其中的内容不是太复杂,有些时候 Visual Studio 会把这个文件搞乱,理解一下这个文件的结构,对我们处理一些异常情况有所帮助。
# 表示注释行
版本信息
Microsoft Visual Studio Solution File:用来说明解决方案文件的版本号,12.00 说明是 VS2013 的解决方案文件。VisualStudioVersion:打开这个解决方案文件需要的 Visual Studio 版本号
MinimumVisualStudioVersion:能够打开这个解决方案的最低 Visual Studio 版本号。
下面是一个解决方案文件的示例。
Microsoft Visual Studio Solution File, Format Version 12.00 # Visual Studio 2013 VisualStudioVersion = 12.0.31101.0 MinimumVisualStudioVersion = 10.0.40219.1
项目
解决方案中包含若干个项目,每个项目有一个 Project 的说明。Project( 项目在解决方案中的编号=显示名称, 实际路径, 项目唯一标识 )
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ConsoleApplication22", "ConsoleApplication22\ConsoleApplication22.csproj", "{312AC167-D533-4A6C-B5F9-9CBA3280DDD8}" EndProject
项目唯一标识来自项目文件,在 ConsoleApplication22.csproj 文件中可以找到如下说明。
<ProjectGuid>{312AC167-D533-4A6C-B5F9-9CBA3280DDD8}</ProjectGuid>
解决方案文件夹
如果是解决方案文件夹, 则实际路径与显示名称一致。比如,在解决方案中创建了一个名为 NewFolder1 的解决方案文件夹。
在解决方案文件中就会多出来一个特殊的 Project。
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "NewFolder1", "NewFolder1", "{86426712-B46D-4FBB-B5CD-28376414DD94}" EndProject
所以,我们可以理解为什么解决方案文件夹不能嵌套了。
如果我们在解决方案文件夹中创建了一个项目。
项目的说明示例如下。
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ClassLibrary1", "NewFolder1\ClassLibrary1\ClassLibrary1.csproj", "{DD66205E-FEB8-42C5-BF26-55A48274E65C}" EndProject
那么,在解决方案文件中中的 Global 节中,会多出来一个 GlobalSection(NestedProjects) = preSolution
GlobalSection(NestedProjects) = preSolution {DD66205E-FEB8-42C5-BF26-55A48274E65C} = {86426712-B46D-4FBB-B5CD-28376414DD94} EndGlobalSection
你会看到前面是项目的标识,等号的后面就是解决方案文件夹的标识。这个嵌套的 NestedProjects 用来说明使用解决方案文件夹组织的项目。
Global 配置节
在所有 Project 说明之后,应该存在一个 Global 配置节Global GlobalSection(SolutionConfigurationPlatforms) = preSolution Debug|Any CPU = Debug|Any CPU Release|Any CPU = Release|Any CPU EndGlobalSection GlobalSection(ProjectConfigurationPlatforms) = postSolution {312AC167-D533-4A6C-B5F9-9CBA3280DDD8}.Debug|Any CPU.ActiveCfg = Debug|Any CPU {312AC167-D533-4A6C-B5F9-9CBA3280DDD8}.Debug|Any CPU.Build.0 = Debug|Any CPU {312AC167-D533-4A6C-B5F9-9CBA3280DDD8}.Release|Any CPU.ActiveCfg = Release|Any CPU {312AC167-D533-4A6C-B5F9-9CBA3280DDD8}.Release|Any CPU.Build.0 = Release|Any CPU EndGlobalSection GlobalSection(SolutionProperties) = preSolution HideSolutionNode = FALSE EndGlobalSection EndGlobal
可以看到有三个部分组成
整个解决方案的配置信息在 SolutionConfigurationPlatforms 中。
GlobalSection(SolutionConfigurationPlatforms) = preSolution Debug|Any CPU = Debug|Any CPU Release|Any CPU = Release|Any CPU EndGlobalSection
每个项目的平台配置信息在 ProjectConfigurationPlatforms 中。
GlobalSection(ProjectConfigurationPlatforms) = postSolution {312AC167-D533-4A6C-B5F9-9CBA3280DDD8}.Debug|Any CPU.ActiveCfg = Debug|Any CPU {312AC167-D533-4A6C-B5F9-9CBA3280DDD8}.Debug|Any CPU.Build.0 = Debug|Any CPU {312AC167-D533-4A6C-B5F9-9CBA3280DDD8}.Release|Any CPU.ActiveCfg = Release|Any CPU {312AC167-D533-4A6C-B5F9-9CBA3280DDD8}.Release|Any CPU.Build.0 = Release|Any CPU EndGlobalSection
项目的属性。
GlobalSection(SolutionProperties) = preSolution HideSolutionNode = FALSE EndGlobalSection
TFS 中特殊的 Global 配置节
如果使用 TFS 来管理项目,在 Global 配置节中会多出来一个 GlobalSection(TeamFoundationVersionControl) = preSolution 的配置节。需要注意的是,这个多出来的配置节只能有一个,有的时候 TFS 会错误的多添加若干个,这时候,在打开项目的时候,你应该会看到如下的提示信息。
注意解决方案中实际包含的项目数量,多出来的 TeamFoundationVersionControl 配置节中项目数量一般不对。一般来说,保留第一个,将其他的删除就可以了。
下面是一个配置节的示例。
GlobalSection(TeamFoundationVersionControl) = preSolution SccNumberOfProjects = 25 SccEnterpriseProvider = {4CA58AB2-18FA-4F8D-95D4-32DDF27D184C} SccTeamFoundationServer = http://tfs.xxxxxxx.com:8080/tfs/xxxxxxx SccLocalPath0 = . SccProjectUniqueName1 = xxx\\yyy\\zzz.csproj SccProjectTopLevelParentUniqueName1 = ttt.sln SccProjectName1 = xxx/yyy SccLocalPath1 = xxx\\yyy EndGlobalSection
其中
SccNumberOfProjects 是说明在 TFS 管理之下共有多少个项目。
SccTeamFoundationServer:TFS 服务器的地址。
SccLocalPath0:源代码管理器的本地目录
具体解决方案中的项目再分别列出来,每个项目占 4 行。
SccProjectUniqueName1:项目的路径
SccProjectTopLevelParentUniqueName1:就是解决方案的名称
SccProjectName1:项目的名称,注意已经包含了项目文件夹前缀
SccLocalPath1:保存在本地的项目路径
相关文章推荐
- VS2013 解决方案文件结构分析
- VS2013 解决方案文件结构分析
- C++ MFC / VS2013 之二 解决方案各个文件结构
- VS中的解决方案设置--文件结构
- win32模版文件分析(VS2013)
- 使用vs2013打开VS2015的工程文件的解决方案(适用于大多数vs低版本打开高版本)
- vs2010打不开vs2013的.sln文件,选择的文件是解决方案文件 但是用此应用程序的较新版本创建的,无法打开
- 【VS2013】解决方案加载失败,无法读取项目文件“xxx.vcxproj”
- 【问题】VS2010 VS2012 VS2013 安装之后提示 "无法打开文件 kernel32.lib" 解决方案
- win10下vs2013为程序集新建强名称文件时“未能完成操作。拒绝访问”的解决方案
- 安装了VS2013 又安装VS2010 遇到 LINK : fatal error LNK1123: 转换到 COFF 期间失败: 文件无效或损坏 解决方案
- VS2013添加解决方案内项目的引用,编译时提示找不到文件
- VS2013 编译程序时报无法加载PDB文件错误解决方案
- VS2013/MFC编程入门之二(VS2013应用程序工程中文件的组成结构)
- VS2013 编译程序时报无法加载PDB文件错误解决方案
- VS2013/MFC入门之二(应用程序工程中文件的组成结构)
- 转:使用vs2013打开VS2015的工程文件的解决方案(适用于大多数vs低版本打开高版本)
- VS2013 编译程序时报无法加载PDB文件错误解决方案
- 【VS2013】目录结构,文件的组成结构