程序集引用无法在我们的构建服务器上正确解析
我们使用 VS2008 SP1 用 C# 进行编码。 我们有一台运行 Team System Server 2008 的服务器，用于源代码控制、任务等。该服务器也是我们用于Team Build的构建机器。 这已经运行了很长一段时间了。 直到现在。 当我们尝试构建一个对一个外部程序集有引用的项目时，我们会收到这些错误消息（这种情况会通过 Team Build 发生，当物理登录并通过 Visual Studio 进行常规构建时）：
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets : 警告 MSB3246: 已解析的文件有一个 图像不好，没有元数据，或者是 否则无法访问。 不能加载 文件或程序集 'C:\Program 文件\Syncfusion\Essential Studio\7.1.0.21\Assemblies\3.5\Syncfusion.XlsIO.Base.dll' 或其依赖项之一。 模块 预计将包含一个集会 明显。
C:\程序 文件\MSBuild\Microsoft\VisualStudio\v9.0\ReportingServices\Microsoft.ReportingServices.targets(24,2)： 错误 MSB4062： “Microsoft.Reporting.RdlCompile”任务 无法从程序集中加载 Microsoft.ReportViewer.Common， 版本=9.0.0.0，文化=中立， 公钥令牌=b03f5f7f11d50a3a。 可以 不加载文件或程序集 '微软.ReportViewer.Common, 版本=9.0.0.0，文化=中立， PublicKeyToken=b03f5f7f11d50a3a' 或 它的依赖项之一。 该模块 预计将包含一个集会 显现。 确认 声明是正确的，并且 程序集及其所有依赖项是 可用。
引用的组件 'Syncfusion.XlsIO.Base' 无法 找到了。
这些错误针对具有一个有问题的程序集引用的一个项目。 当我尝试构建整个解决方案时，当然会因为这个错误而出现更多错误。 还有另外两个项目与其他程序集引用也存在相同的问题。 我有一个 VS 似乎无法解析的引用程序集列表：
- Microsoft.ReportViewer.Common
- Microsoft.ReportViewer.WinForms
- Syncfusion.Compression.Base
- Syncfusion.Core
- Syncfusion.XlsIO.Base
Syncfusion 程序集来自第 3 方组件包裹。 另外两个与 Microsoft ReportViewer 组件相关。
这些引用是通过 .NET 选项卡中的“添加引用”窗口添加的，因此我认为这没有任何可疑之处。 在程序集引用的属性窗口中，区域性、描述、路径、运行时版本或强名称中没有值。 版本显示 0.0.0.0，已解决为 False。 我想很明显 VS 无法解析引用。 我的问题是为什么？？？ 我为这个问题绞尽脑汁。 这只发生在服务器上，该解决方案在我的机器和我同事的机器上都构建得很好。 装配参考属性在我们的机器上很好。
我尝试卸载第3方组件（当然在服务器上），然后再次重新安装。 没有帮助。 我尝试修复VS2008安装。 没有帮助。 尝试从源代码管理检索早期版本（我知道之前已经在服务器上构建过），并且我收到了相同的错误消息。 我已检查文件权限，一切似乎都正常。 我的想法已经用完了...
我该如何解决这个问题？
2009 年 2 月 16 日更新：
我尝试在我的电脑和服务器上比较 dll 的 ildasm 输出（请参阅我写的评论），并且在一行中存在一个小差异，对我来说似乎是评论。 我必须承认我根本不明白为什么会有差异，所以也许有人可以向我解释一下？
我还尝试在服务器上运行病毒扫描。 没有帮助。 尝试删除引用，然后通过浏览磁盘上的 dll读取它。 没用。
2009 年 3 月 17 日更新：
我找到了解决方案！ 罪魁祸首是 Panda Antivirus 的 TruPrevent 模块。 禁用模块后，一切正常！ =)
我在 fuslogvw.exe 及其生成的日志。 谷歌搜索结果，偶然发现此博客条目。。 希望这可以帮助其他人。
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
: 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.
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
The Syncfusion assemblies are from a 3rd-party component package. The other two are related to the Microsoft ReportViewer component.
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.
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?
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.
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
几乎可以肯定，问题是环境问题，与来源无关。
一些想法...
(i) 尝试禁用您的防病毒/反恶意软件工具 - 我见过这些工具（特别是趋势科技防病毒软件，出于某种原因）可以在扫描后（期间？）锁定 DLL 文件的情况，干扰编译器。
(ii) 检查您的 PATH 环境变量。 即使在现代，PATH 变量也用于解决一些问题 - 如果这被搞乱了（太长，最大长度为 2048 个字符 IIRC），那么事情可能会很奇怪。
(iii) 您已检查文件权限 - 您是否检查了注册表中的权限？ 例如，SyncFusion 在用户和机器配置单元中安装其许可证密钥 - 如果构建服务器无法读取其中之一，可能会导致问题。
祝你好运！
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.
(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) 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.
Good luck!
也可能是引用的程序集位于开发计算机上的 GAC 中，但不在构建计算机上。 将其从 GAC 中取出，放入源存储库中，然后按路径引用它。
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.
我们遇到了同样的问题，结果C 驱动器已满（只有 28MB）。
尽管构建发生在 D 上，但释放空间解决了该问题。
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:\Program Files\Syncfusion\Essential Studio\7.1.0.21\Assemblies\3.5\Syncfusion.XlsIO.Base.dll”的 ildasm 之间存在任何差异？
您是否发现您的计算机上与服务器上的
Do you see any differences between ildasm of this file
'C:\Program Files\Syncfusion\Essential Studio\7.1.0.21\Assemblies\3.5\Syncfusion.XlsIO.Base.dll'
on your machine versus on the server?
我怀疑构建过程所在的用户无权访问您的第 3 方控件所在的文件夹。由于此功能在您的计算机上正常运行，因此几乎可以肯定它是特定于用户/权限的。
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 方 dll 可能依赖于非托管 dll。 通常是因为缺少特定版本的 VC++ 运行时 Dll。
在服务器上使用 Dependency Walker http://www.dependencywalker.com/ 打开 Dll，并检查缺少参考文献。
Your 3rd party dll may depend on unmanaged dlls. Often it's because a specific version of the VC++ Runtime Dlls are missing.
Open the Dll with the Dependency Walker http://www.dependencywalker.com/ on your server and check for missing references.
不确定这对你的情况是否有帮助，但我之前确实有过类似的情况，其中一个 dll 显然以某种方式未注册，并且在 dll 上运行 regsvr32 就可以解决问题。
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.