views:

4133

answers:

7

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.

A: 

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?

Brian
I directed the output of ildasm into a txt-file on the server and on my machine. I compared them using the diff tool in VS2008 Team System, and one line showed up different:On the server:// Image base: 0x03220000On my machine:// Image base: 0x043C0000So yes there is a tiny difference.
Sub-Star
A: 

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.

Brian Rudolph
+1  A: 

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.

Rovpedal
A: 

I have exactly the same problem with all open source dlls (nhibernate, log4net, rhino.mocks, ...) that are downloaded (not installed) on my machine. The only way to use them is to recompile the source code. The same dlls are resolved without any problem in all other developer machines here in my office (and probably worldwide).

So there is no "in GAC/out of GAC" issue, nor a "reference path not found" problem. It's not even a user permissions issue, because it happens even when I run Visual Studio as administrator.

The only other reference to this problem I have found so far is this: http://www.codeproject.com/script/Forums/View.aspx?fid=1650&msg=2551634 and it is not resolved yet.

I think (though I'm not sure) that it must be a code trust issue, having to do with Visual Studio in XP SP3 or Windows Server OS not trusting downloaded dlls.

Please post the solution here, if you ever find one!


UPDATE


Things are weirder than I thought... I did the following experiment: I compiled the solution that exhibits this problem with SharpDevelop on the same machine under the same user credentials and it doesn't complain! If it were a CAS issue, SharpDevelop would have choked on it too. Unless of course it's some kind of checking that only Visual Studio (not the framework) performs.

Go figure...

A: 

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.

chris
A: 

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.

Davy8
Running RegSvr32 on a DLL is only needed for COM components; this question is about references .NET DLL assemblies, not COM. Good thinking, just not relevant here.
Bevan
+1  A: 

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!

Bevan
I didn't see your answer until after I had discovered the solution myself, but I'll give you the accepted answer because your suggestion was spot on. Disabling TruPrevent in Panda Antivirus did the trick. =)
Sub-Star