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.
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!
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.
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.
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?
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.
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.
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.
Related
When I run unit testing to serialize to an xml file, I keep getting error message:
Could not load file or assembly
'Company.Fin.Bank.Common.XmlSerializers.dll, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. The
system cannot find the file specified.
I guess Company.Fin.Bank.Common.XmlSerializers.dll may be in cache somewhere but it is impossible to find this dll, even though i don't need that dll. I want to remove it. But where can i find it? is it possibly in a cache? if yes how can i clean the cache from VS? This problem is very new to me.
What a weird part is that i used another laptop (win 7) to run the unit testing, there is no error message i got - it worked. but when i used my own laptop (win 8) i keep getting error message. I have no idea why.
I hope to find solution from you. Your help means alot. Thanks!!!
That assembly is dynamically generated by the framework (XMLSerializer)
In .Net implementation, the XmlSerializer generates a temporary
assembly for serializing/deserializing your classes (for performance
reasons).
Also, this may be normal behavior - is it stopping your application from running?
even though i don't need that dll
Visual Studio will usually remove unneeded DLLs. Typically this is caused by dependencies (which are harder to keep track of).
I want to remove it.
Check in the References of the project in the Solution Explorer. If any of them have a yellow triangle that means they can't be found (the project may still compile and run if you aren't actually using that reference).
is it possibly in a cache?
As Daniel Kelley mentioned C:\Windows\assembly and C:\Windows\Microsoft.NET\assembly are where the global assembly cache is located. If it isn't there check the Hint Path of the reference (it will show up in Properties).
Good luck finding your reference, keep in mind that you need not only the actual DLL but all of its used references in most cases. Also a decompiler like DotPeek can be useful if you need a more discreet way of looking at references.
I got a DLL registered in the GAC which has a bug in it (v4.2.0).
I've therefore fixed that bug, updated the file version only (v4.2.1) (keeping the assembly version, v4.2.0) and built a new MSI package.
The problem is that the DLL is not installed in the GAC. I verified this by right-clicking on the DLL in C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MyDLL\v4.0_4.2.0.0__2269313d92725976 and checked the file version, which is still v4.2.0 There are also no other folders created under C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MyDLL.
But! If I uninstall the first version and then install the new DLL it get's installed OK in the GAC.
Am I approaching this the wrong way? Our applications are set to use specific versions, so just creating assembly version v4.3.0 and install it in the GAC wont work.
Update
I've found the article about publisher policies ( http://support.microsoft.com/kb/891030) and are attempting that instead. I've generated the policy assembly. But Visual Studio crashes when I try to add it to the setup project =(
I've also tried to add it as a content file to the primary project (and then add content files to GAC). But then it complains on the assembly not being signed.
So I'm still stuck.
Updating the [AssemblyFileVersion] for a bug fix is usually the right approach, although it gets iffy if you do so for an assembly in the GAC. You run the risk of breaking another app that also uses the assembly and unintentionally depends on the buggy behavior to function correctly. An unintentional mistake like renaming a public method is of course always a good way to break an app, the road to DLL Hell is paved with many good intentions that turned out bad.
The GAC however only pays attention to [AssemblyVersion] and ignores the file version. To get the updated assembly to replace the existing one you do have to remove the old one first. This is intentional, preventing accidental replacement.
A <bindingRedirect> in the .config file of the app you want to repair will be a lot easier to get going than a publisher policy.
I believe this has to do with what parameters of a .NET assembly the GAC uses to give it a unique identifier. If the assembly version is one of those uniqueness parameters, but file version is not, that may explain your symptoms. Specifically this pertains to the GACs need for a strong named assembly
This link says as much
http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx
The program worked fine until I did this:
Added a new class under an existing file and an existing namespace.
Added settings to that project the new class belongs to.
Build the solution.
Build the setup project.
Installed the new version on a machine.
When I start the new version on the machine, then I get:
Unhandled Exception:
System.TypeLoadException: Could not
load type
'SI.AS.CommonLogic.Utils.ErrorLog'
from assembly
'SI.AS.CommonLogic.ErrorUtils,
Versions=1.0.0.0, Culture=neutral,
PublicKeyToken=925c8734ae397609'. at
RSMonitor.RSMonitorMain.Main(String[]
args)
ErrorUtils is the new class I have added. There was a file with a static class in it. I added another static class under it and added settings to the project. It runs smoothly on my developer machine in debug mode. But I can't install and run it on another machine. The program can call the other static class from the same file. What am I missing here?
** update **
I tried to install it for a 2nd time and checked the DLL. The timestamp matched the latest compiled version and now it works. I have no idea why it didn't work last time, because it is the same package I installed again. But if I get same error, then I'll try out your suggestions.
Your program looks like it is having trouble locating another assembly, probably called SI.AS.CommonLogic.ErrorUtils.dll. Either that, or it can only find the wrong version of this assembly.
Is this an assembly that is part of your solution?
If so, is it in the "bin" directory on the machines that it is failing to run on (in other words, is this assembly being deployed correctly with your app)?
If not, is this a part of a seperately installed component or application that is installed on your machine but not on the others (ie is this an external dependency that is missing on the other machines)?
One thing that may help here, is to use the Assembly Binding Log Viewer on both the miachine this does work on, and the machine it doesn't to see where it gets loaded from in the working case, and where it is trying to load it from in the failing case.
Note you may need to make a registry change to get this to log all assembly bin info:
Set the HKLM\Software\Microsoft\Fusion\ForceLog registry value to 1 (the value is a DWORD).
It sounds like your DLLs aren't being deployed/overwritten correctly. Try copying your CommonLogic DLL from your development machine to the installation directory and see if it can load it then - and then figure out why!
The other assembly wasn't updated correctly, it is still the old version. Try replacing the assembly by hand with the current version and check if the problem persists; it should go away though.
It sounds like an old version of your assembly is being loaded from somewhere.
A few things to check:
Firstly, have you incorrectly set up a reference to an assembly instead of a project? This can result in subtle, order-dependent build problems. Ensure that the reference type is "project", not "assembly".
Secondly, is the culprit assembly in the GAC on the developer machine? Even if the assembly is a dependency of your build, if it's in the GAC, it may not be copied to your output directory. This problem manifests itself in a very pernicious fashion -- everything looks fine on the developer machine (as it has the assembly in the GAC) despite the build output being wrong, and the customer machine will blow up because the assembly is neither in the GAC nor the install directory. I can't remember if this only applies to assembly references or whether project references will pick it up, too. It's easy to test if it's a problem, though -- just do a clean build, then build your project and examine the assemblies copied to the output directory. They should all be there. If your culprit .dll is missing then you know it's a problem.
I worked at a company that (briefly) built installers for internal releases without using proper assembly versioning, resulting in absolutely terrible problems of this ilk (developer machines would be riddled with assemblies in the GAC).
Check the GAC on both the developer and customer machines. Also try what Josh suggested: Copy the culprit DLL from the developer machine to the customer machine's install directory to see if that fixes it, then work from there.
I have a .NET CF 1.1 application that has been running perfectly fine for years. Occasionally, I get a help desk ticket with the following error message (generic):
Method not found:
MethodName
AssemblyNamespace.Class
The DLL is there, and it's the same version as my other devices. What could change that would make it not find the method. Does this error imply that the assembly was loaded, or did it break before that even happened?
Does it matter how I added the reference in Visual Studio (2003, btw)? I have Copy Local set to true, and therefore I made the assumption that it needs to be in the same directory as my executable.
Any help you can offer is appreciated. Thanks.
EDIT: I believe this DLL is also in the windows directory of the device, possibly a different version. It contains a lot of hardware specific functions (i.e. backlight, keyboard state, etc.)
No it does not matter how you add the reference in Visual studio 2003. (100% sure)
Now for the not so sure : I think that someone else has the same assembly in the GAC of the phone. So the GAC assembly gets called rather than the one you deployed and that version of the assembly lacks the requested function.
Depends on how you reference the file in your code. You could be relying on the current working directory which depending on how the app is launched or what they do after, it might not be what you expect it to be.
Sometimes .NetCf throws this exception when the device is running out of memory, instead of the expected "Out of Memory" exception. I have observed this behaviour more often when loading native dlls using P/Invoke than loading pure netcf dlls.
I'm developing a custom PowerShell snap-in, which references another project in the solution.
When I try to debug the snap-in (following [these instructions][1]), the assembly fails to load and my cmdlet fails with the message "Could not load file or Assembly..."
How do you instruct PowerShell on how to locate assemblies, or how do you specify where are located the assemblies needed by the snap-in?
I'd prefer to avoid registering the assemblies in the GAC, at least during development.
Not sure of the exact behaviour, but I would try and make use of fuslogvw to see exactly where the runtime is looking for the problematic assemblies. That would give you a clue as to how to get them to be copied into the correct place on build. This post by Scott Hanselman is quite useful, and this is the official documentation.
If you find the solution, please add an answer, as this must be a common scenario.
SOLUTION (Posting it here as suggested by one of the comments to my question)
My problem was rather specific, as I'm developing on a 64 bits server machine, but I'm posting the solution in case it could help someone else as well.
Using fuslogvw as suggested, I saw that the dependent assembly was being searched using the machine.config file under C:\Windows\Microsoft.NET\Framework64 and then the binding failed; launching the project with "start without debugging", instead, the machine.config file under C:\Windows\Microsoft.NET\Framework was taken (notice the missing 64 at the end).
I thought that the problem could be due to the image format, and infact the dependent assembly was being compiled with x86 as CPU target; I changed it to "Any CPU" and now the assembly is loaded correctly.