程序集引用无法在我们的构建服务器上正确解析 [英] Assembly references won't resolve properly on our build server

问题描述

我们使用 VS2008 SP1 用 C# 编写代码.我们有一台运行 Team System Server 2008 的服务器，用于源代码控制、任务等.服务器 也是我们用于 Team Build 的构建机器.这已经工作了很长时间.直到目前.当我们尝试构建一个引用到一个外部程序集的项目时，我们会收到这些错误消息(这通过 Team Build、以及在实际登录并通过 Visual Studio 进行常规构建时):

We code in C# using VS2008 SP1. We have a server that runs Team System Server 2008 which we use for source control, tasks etc. The server is also our build machine for Team Build. This has been working just fine for a long time. Untill now. We get these error messages when trying to build one of our projects that has a reference to one external assembly (this happens both via Team Build, and when logging on physically and doing a regular build via Visual Studio):

C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets:警告 MSB3246:已解析的文件具有图像不好，没有元数据，或者是否则无法访问.不能加载文件或程序集 'C:\Program文件\同步融合\基本Studio\7.1.0.21\Assemblies\3.5\Syncfusion.XlsIO.Base.dll'或其依赖项之一.模块预计包含一个程序集清单.

C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets : warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Could not load file or assembly 'C:\Program Files\Syncfusion\Essential Studio\7.1.0.21\Assemblies\3.5\Syncfusion.XlsIO.Base.dll' or one of its dependencies. The module was expected to contain an assembly manifest.

C:\程序Files\MSBuild\Microsoft\VisualStudio\v9.0\ReportingServices\Microsoft.ReportingServices.targets(24,2):错误 MSB4062:Microsoft.Reporting.RdlCompile"任务无法从程序集加载Microsoft.ReportViewer.Common，版本=9.0.0.0，文化=中性，PublicKeyToken=b03f5f7f11d50a3a.可以不加载文件或程序集'Microsoft.ReportViewer.Common,版本=9.0.0.0，文化=中性，PublicKeyToken=b03f5f7f11d50a3a' 或它的依赖项之一.模块预计包含一个程序集显现.确认声明是正确的，并且程序集及其所有依赖项是可用.

C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\ReportingServices\Microsoft.ReportingServices.targets(24,2): error MSB4062: The "Microsoft.Reporting.RdlCompile" task could not be loaded from the assembly Microsoft.ReportViewer.Common, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. Could not load file or assembly 'Microsoft.ReportViewer.Common, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The module was expected to contain an assembly manifest. Confirm that the declaration is correct, and that the assembly and all its dependencies are available.

引用的组件'Syncfusion.XlsIO.Base' 不能找到了.

The referenced component 'Syncfusion.XlsIO.Base' could not be found.

这些错误是针对一个有问题的程序集引用的项目.当我尝试构建整个解决方案时，当然会因为这个错误而出现更多错误.还有两个其他项目与其他程序集引用存在相同的问题.我有一个 VS 似乎无法解析的引用程序集列表:

These errors are for one project with one problematic assembly reference. When I try to build the entire solution there are of course many more errors because of this one. And there are two other projects that has the same problem with other assembly references. I have a list of the referenced assemblies that VS can't seem to resolve:

• Microsoft.ReportViewer.Common
• Microsoft.ReportViewer.WinForms
• Syncfusion.Compression.Base
• Syncfusion.Core
• Syncfusion.XlsIO.Base

Syncfusion 组件来自第 3 方组件包.另外两个与 Microsoft ReportViewer 组件有关.

The Syncfusion assemblies are from a 3rd-party component package. The other two are related to the Microsoft ReportViewer component.

引用已通过添加引用"窗口添加到 .NET 选项卡中，因此我认为没有任何可疑之处.在程序集引用的属性窗口中，区域性、描述、路径、运行时版本或强名称中没有值.版本说 0.0.0.0 和 Resolved 是假的.我想很明显 VS 无法解析引用.我的问题是为什么???我已经为这个问题挠头了.这仅发生在服务器上，该解决方案在我的机器和我的同事机器上都可以正常构建.装配参考属性在我们的机器上很好.

The references has been added via the Add Reference window, in the .NET tab, so I don't think there is anything suspicious about that. In the properties window for the assembly reference, there is no value in Culture, Description, Path, Runtime Version or Strong Name. Version says 0.0.0.0 and Resolved is False. I guess it is pretty obvious that VS cant resolve the reference. My question is why??? I've scratched my head a lot over this one. This only occurs on the server, the solution builds just fine on both my machine, and my coworkers machine. The assembly reference properties are fine on our machines.

我已经尝试卸载第三方组件(当然是在服务器上)，然后重新安装.没有帮助.我尝试修复VS2008 安装.没有帮助.试图从源代码控制(我知道以前在服务器上构建过)检索早期版本，但我收到了相同的错误消息.我已经检查了文件权限，一切似乎都井井有条.我的想法快用完了...

I have tried uninstalling the 3rd-party component (on the server of course), and then reinstalling it again. Didn't help. I tried to repair the VS2008 installation. Didn't help. Tried to retrieve an earlier version from source control (that I know has buildt on the server before), and I got the same error messages. I have checked file permissions, and everything appears to be in order. I am running out of ideas...

我该如何解决这个问题?

How do I solve this?

2009 年 2 月 16 日更新:
我试图比较我的电脑和服务器上 dll 的 ildasm 输出(请参阅我写的评论)，并且在我看来似乎是评论.我必须承认，我根本不明白为什么会有区别，所以也许有人可以向我解释一下?
我还尝试在服务器上运行病毒扫描.没有帮助.尝试删除引用，然后通过浏览到磁盘上的 dll 来读取它.没用.

Update 16.02.2009:
I have tried to compare ildasm output of the dll on my pc and on the server (see the comment I wrote about that), and there is one small difference in a line that to me appears to be a comment. I must admit that I don't understand why there is a difference at all, so maybe someone could explain that to me?
I also tried running a virus scan on the server. Didn't help. Tried to remove the reference and then readd it by browsing to the dll on disk. Didn't work.

2009 年 3 月 17 日更新:
我找到了解决方案！罪魁祸首是Panda Antivirus 的TruPrevent 模块.禁用模块后，一切正常！=)
我在 fuslogvw.exe 以及它生成的日志.谷歌搜索结果，偶然发现 此博客条目..希望这可以帮助其他人.

Update 17.03.2009:
I've found the solution! The culprit was the TruPrevent module of Panda Antivirus. After disabling the module, everything works! =)
I discovered this with the help of fuslogvw.exe and the log it generated. Googled the result, and stumbled upon this blog entry.. Hope this can help somebody else to.

推荐答案

几乎可以肯定，问题与环境有关 - 与源无关.

Almost certainly the problem is environmental - not source related.

一些想法......

(i) 尝试禁用您的防病毒/反恶意软件工具 - 我见过这些工具(特别是 Trend Micro Antivirus，出于某种原因)可以在(期间?)扫描后保持 DLL 文件锁定的情况，干扰使用编译器.

(i) Try disabling your anti-virus/anti-malware tools - I've seen cases where these tools (particularly Trend Micro Antivirus, for some reason) can keep a DLL file locked after (during?) scanning, interfering with compilers.

(ii) 检查您的 PATH 环境变量.即使在现代，PATH 变量也被用来解决一些问题——如果它搞砸了(太长，最大长度为 2048 个字符 IIRC)那么事情可能会很奇怪.

(ii) Check your PATH environment variable. Even in these modern days, the PATH variable is used to resolve some things - if this is messed up (too long, maximum length is 2048 characters IIRC) then things can be odd.

(iii) 您已检查文件权限 - 您是否已检查注册表中的权限?例如，SyncFusion 在用户和机器配置单元中安装其许可证密钥 - 如果构建服务器无法读取其中一个，可能会导致问题.

(iii) You've checked File permissions - have you checked permissions in the registry? For example, SyncFusion installs its license key in both the User and Machine hives - if the build server can't read one or the other, could cause issues.

祝你好运！

这篇关于程序集引用无法在我们的构建服务器上正确解析的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！