C# 程序集引用无法在我们的构建服务器上正确解析

Assembly references won't resolve properly on our build server

提问by Sub-Star

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 serveris also our build machine for Team Build. This has been working just fine for a long time. Untill now. We get these error messageswhen trying to build one of our projects that has a referenceto one external assembly(this happens both via Team Build, and when logging on physically and doing a regular build via Visual Studio):

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

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:\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.

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

C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets ：警告 MSB3246：已解析的文件包含错误图像、没有元数据或无法访问。无法加载文件或程序集“C:\Program Files\Syncfusion\Essential Studio\7.1.0.21\Assemblies\3.5\Syncfusion.XlsIO.Base.dll”或其依赖项之一。该模块应包含程序集清单。

C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\ReportingServices\Microsoft.ReportingServices.targets(24,2)：错误 MSB4062：无法从 Microsoft 程序集加载“Microsoft.Reporting.RdlCompile”任务。 ReportViewer.Common，版本=9.0.0.0，文化=中性，PublicKeyToken=b03f5f7f11d50a3a。无法加载文件或程序集“Microsoft.ReportViewer.Common，Version=9.0.0.0，Culture=neutral，PublicKeyToken=b03f5f7f11d50a3a”或其依赖项之一。该模块应包含程序集清单。确认声明正确，并且程序集及其所有依赖项都可用。

找不到引用的组件“Syncfusion.XlsIO.Base”。

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:

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

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

• Microsoft.ReportViewer.Common
• Microsoft.ReportViewer.WinForms
• Syncfusion.Compression.Base
• 同步融合核心
• 同步融合.XlsIO.Base

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

Syncfusion 程序集来自第 3 方组件包。另外两个与 Microsoft ReportViewer 组件有关。

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.

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

I have tried uninstallingthe 3rd-party component(on the server of course), and then reinstalling it again. Didn't help. I tried to repairthe VS2008 installation. Didn't help. Tried to retrieve an earlier versionfrom 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...

我试过卸载第3 方组件（当然是在服务器上），然后重新安装。没有帮助。我试图修复与VS2008安装。没有帮助。试图从源代码管理中检索早期版本（我知道之前在服务器上已经构建过），但我收到了相同的错误消息。我已经检查了文件权限，一切似乎都井井有条。我的想法不多了...

How do I solve this?

我该如何解决这个问题？

Update 16.02.2009:
I have tried to compare ildasm outputof 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 scanon the server. Didn't help. Tried to removethe referenceand then readdit by browsing to the dll on disk. Didn't work.

2009 年 2 月 16 日更新：
我试图比较我的电脑和服务器上 dll 的ildasm 输出（请参阅我写的评论），并且在我看来似乎是评论的一行中有一个小差异。我必须承认，我根本不明白为什么会有区别，所以也许有人可以向我解释一下？
我还尝试在服务器上运行病毒扫描。没有帮助。试图除去的参考，然后重新进行添加通过浏览到磁盘上的DLL它。没用。

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.exeand the log it generated. Googled the result, and stumbled upon this blog entry.. Hope this can help somebody else to.

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

采纳答案by Bevan

Almost certainly the problem is environmental - not source related.

几乎可以肯定，问题是环境问题——与来源无关。

Some ideas ...

一些想法...

(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.

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

(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.

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

(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.

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

Good luck!

祝你好运！

回答by Brian

Do you see any differences between ildasm of this file

你看到这个文件的 ildasm 有什么不同吗？

'C:\Program Files\Syncfusion\Essential Studio\7.1.0.21\Assemblies\3.5\Syncfusion.XlsIO.Base.dll'

'C:\Program Files\Syncfusion\Essential Studio\7.1.0.21\Assemblies\3.5\Syncfusion.XlsIO.Base.dll'

on your machine versus on the server?

在您的机器上还是在服务器上？

回答by Brian Rudolph

My suspicion is that the user that the build process is under does not have access to the folder that your 3rd party control is in. Since this functions properly on your machines, it is almost certainly user/permission specific.

我怀疑构建过程所在的用户无权访问您的第 3 方控件所在的文件夹。由于这在您的机器上正常运行，因此几乎可以肯定它是特定于用户/权限的。

回答by Rovpedal

It could also be that the referenced assemblies are in the GAC on the dev machine, but not on the build machine. Get it out of the GAC, into your source repository, and reference it by path.

也可能是引用的程序集位于开发机器上的 GAC 中，而不是构建机器上。将它从 GAC 中取出，放入您的源存储库，并通过路径引用它。

回答by laktak

Your 3rd party dll may depend on unmanaged dlls. Often it's because a specific version of the VC++ Runtime Dlls are missing.

您的第 3 方 dll 可能依赖于非托管 dll。通常是因为缺少特定版本的 VC++ 运行时 Dll。

Open the Dll with the Dependency Walker http://www.dependencywalker.com/on your server and check for missing references.

在您的服务器上使用 Dependency Walker http://www.dependencywalker.com/打开 Dll并检查是否缺少引用。

回答by Davy8

Not sure if this'll help in your case, but I did have something similar before where a dll apparently got unregistered somehow, and running regsvr32 on the dll did the trick.

不确定这对您的情况是否有帮助，但我之前确实有类似的东西，其中 dll 显然以某种方式未注册，并且在 dll 上运行 regsvr32 可以解决问题。

回答by Kobi

We've had the same problem, turns out the C drive was full(only had 28MB).
Freeing space resolved the issue, even though the build happens on D.

我们遇到了同样的问题，结果C 驱动器已满（只有 28MB）。
释放空间解决了这个问题，即使构建发生在 D 上。