Visual Studio的TeamCity生成步骤中的MSBUILD错误MSB4025

Visual Studio的TeamCity生成步骤中的MSBUILD错误MSB4025,msbuild,teamcity,Msbuild,Teamcity,当我运行TeamCity构建时,唯一的构建步骤是runner类型的Visual Studio(sln),我得到以下错误: C:\TeamCity\buildAgent\work\4978ec6ee0ade5b4\Test\Code\Test.sln(2, 1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 2, position 1. 这在运行TeamC

当我运行TeamCity构建时,唯一的构建步骤是runner类型的Visual Studio(sln),我得到以下错误:

C:\TeamCity\buildAgent\work\4978ec6ee0ade5b4\Test\Code\Test.sln(2, 1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 2, position 1.
这在运行TeamCity Professional 8.1.1(build 29939)的专用CI服务器上。此服务器上还有其他几个成功运行的生成

奇怪的是,相同的构建在我的开发机器上的TeamCity上成功运行。我接着问了一个类似的问题,并将指定的文件夹复制到了不同的文件夹中,但这没有帮助

我确信项目/解决方案文件不是无效的,因为除了在我的开发设备上运行的构建之外,我已经在VisualStudio中打开了解决方案,并且在那里构建了它,没有任何问题

有什么建议吗?

我刚刚解决了这个问题


在Test.sln文件中查找未关闭的Project或EndProject标记。对我们来说,EndProject丢失了,在teamcity上中断了,但在Visual Studio中没有问题。

在我们的例子中,它是解决方案文件中的重复项目引用(由几乎同时提交和自动合并引起)。

似乎teamcity错误消息会因任何根本原因出现。在我的例子中,出现问题的原因是GlobalSection(NestedProjects)部分中的一行引用的项目Guid与解决方案文件中定义的任何项目都不相关

与上一篇文章一样,我在VisualStudio中构建没有任何问题。我只得到了一条更有用的错误消息,它让我能够发现使用msbuild构建时真正的问题是什么


请参阅以获取另一个示例,其中使用msbuild有助于确定真正的问题。

在我的示例中,在合并.sln文件后,下面的行不匹配

GlobalSection(NestedProjects) = preSolution  

{6B971E15-6B61-4AA8-9B93-9639C23269C3} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}

{54D14F01-D576-4DE6-9404-D21AD0DC4916} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}

... (was some extra entry here )
...

 EndGlobalSection
节。很明显,合并后添加了一些额外的行。因此,如果您已合并,请手动比较两个解决方案文件。您可以从两个文件中的总行号开始。

在另一种情况下

我们有一个空行-所以请确保删除所有空行


希望这对其他人也有帮助

我和詹金斯犯了同样的错误。原来根Jenkins文件夹被设置为C:\Program Files(x86)\n并且它没有对bin和obj目录的写入权限

错误: 错误MSB4025:未能加载项目文件。根级别的数据无效

我以管理员身份启动了cmd并运行了以下操作: “C:\Program Files(x86)\MSBuild\14.0\Bin\MSBuild.exe”“C:\Program Files(x86)\Jenkins\workspace\BuildBI\u 1\Reports\Test\ReportsTests.sln”/t:Build/p:RunOctoPack=true”


这给了我一些无法写入bin和obj的线索。

在我们的情况下,问题是指定了一个没有安装在该机器上的ToolsVersion。(VS2015有14个,但VS2017默认没有)

这对我很有用-
您可以安装,确保选择C++工具、Windows 10 SDK和MSBug和您的SET.

使用<代码> MSBudio来识别潜在问题:

$> msbuild mysolution.sln
用正确的错误行号给我这个美丽:

如果无法通过命令行/powershell访问msbuild,请尝试查找VisualStudio附带的msbuild.exe,例如
C:\Program Files(x86)\Microsoft Visual Studio\2019\Community\msbuild\Current\Bin\amd64\msbuild.exe


VisualStudio本身似乎非常“容忍”解决方案文件中的错误/不一致,因此在VS中打开它并不能保证
sln
文件是正确的。

有解析.sln文件的工具:我使用,任何命令都会告诉您.sln文件中缺少的内容。我还注意到,如果尝试使用MSBuild运行该文件,您会收到一条更有用的错误消息。请查找XML键入错误(通常在XML标记之外)。或者一个丢失的标签。您可以通过XML验证器运行它。以进行检查。这解决了我的问题。我最终安装了我需要的构建工具版本。这解决了我的问题。我最终安装了所需的构建工具版本