当通过TFS构建服务执行时,MSBuild找不到引用

3
我有一个基于Telerik程序集的解决方案。所引用的版本已经安装在构建服务器上。问题在于,持续集成构建一直成功,直到我升级了解决方案和构建服务器上的Telerik程序集。现在构建失败,并出现经典的错误:

无法解析此引用。

我检查了我的解决方案,一切都设置为引用特定版本。最令人惊讶的是,如果我在构建服务器上本地打开解决方案,一切都可以顺利构建......这意味着Telerik程序集已经以某种方式被发布,但由于未知原因,在通过构建服务调用MSBuild编译解决方案时,它不能正常工作。

有任何想法吗?


获取两个构建的详细MSBuild日志并进行比较。它会告诉你成功时获取了哪些参考程序集,以及失败时尝试了哪些地方。 - fsimonazzi
是的,我会执行Alexey下面说的操作。几天前我也遇到了类似的问题,删除所有引用并重新创建它们是解决方案。 - Ademar
逐一重新创建所有引用绑定并未解决错误。已经花费了将近一天的时间来解决这个问题,因此Telerik升级可能要等到压力较小的时期。回滚到以前的版本,一切都恢复正常了。我查看了MSBuild日志,发现构建服务器似乎没有在正确的文件夹中查找某些原因不明的文件。也许问题源于新的Telerik软件包部署。 - Ucodia
3个回答

7

在更新到Q3版本后,我也遇到了相同的问题。

为了解决这个问题,我使用日志详细程度设置为诊断级别构建了解决方案,发现MSBuild从未查找过Telerik文件夹。

因此,为了将该文件夹包含在构建中,我们只需通过添加MSBuild参数来添加它: /p:ReferencePath="C:\Program Files\Telerik\RadControls for WPF Q3 2012\Binaries\WPF40"

这可能不是最好的方法,并且需要在每次更新RadControls时进行更新,但它能够工作。

我们在x86安装上运行构建服务器,因此Telerik位于C:\Program Files下,但如果您在x64上运行,则位于C:\Program Files(x86)下,因此如果您在x64和x86安装的多个构建服务器上运行,则必须指定两个路径。


0

尝试删除然后添加对更新的dll的引用 - 然后您可以在proj文件中查看是否存在与引用程序集不同的差异。

为msbuild启用详细\诊断模式(/v:diag命令行键),并检查构建日志。诊断模式提供有关引用库搜索过程的非常详细的输出。


我删除了所有对Telerik的引用,然后逐个重新制作,但构建时仍然出现相同的错误。修复和追踪错误已经花费了将近一天的时间,因此我们决定回滚到以前的版本,这样就可以正常工作了...此外,构建服务搜索过程在数百个文件夹中查找,但通过Visual Studio构建时却没有发现任何问题。 - Ucodia
1
从Visual Studio日志中,您可以确定正确的dll的位置。然后确保TFS搜索该目录。检查proj文件中的<HintPath和proj.user文件中的<ReferencePath(我怀疑后者可能是原因-VS将使用该文件,但TFS不应该)。 - Alexey Shcherbak

0
通常我发现最好将引用的程序集复制到解决方案中,并从那里引用它们。这样,构建服务器和其他开发人员就不需要担心安装特定版本,并且您可以支持运行不同组件版本的多个项目。

我只为那些不容易或根本无法重新分发的程序集这样做。我不太喜欢在源代码控制数据库中加载大量的dll,因为有些项目有很多引用,获取一个包含50MB程序集的项目源代码可能会很痛苦,特别是当你离开办公室并且网络连接不好时。但我认为这确实是一种安全的做法。 - Ucodia
2
或者创建一个包含DLL的自定义NuGet包,并启用包恢复模式。这样就不会在源代码控制中包含DLL,没有安装的机器也可以获取它(并且它比从Telerik下载要小),而且机器可以构建引用多个不同版本的项目。 - Betty

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接