System.BadImageFormatException: Could not load file or assembly 'Microsoft.Sharepoint.Search
I've done a fair amount of digging on this and have found this postthat suggests that its caused by the .dll being marked for AMD and not for ia64. This error occurred after I linked the new cluster to the existing sharepoint farm prior to migration. Then started moving project files over and rebuilding for the upcoming new server name. I've tried copying the .dll from the regular 12 hive into the GAC but it won't make a change to the processor architecture.Do I need to re-run the configuration wizard or something? Anyone have an easy fix? Thanks.Jack Burnish
April 24th, 2009 6:43pm

Hello, Based on my research with similar issues, the issue will occur if the following steps are true: 1. When deploying the web service from the development server to the test server (at the root of the SharePoint website), the entire project folder was copied over, including the bin sub-folder. 2. The bin sub-folder of the web service contains the Microsoft.SharePoint.dll, Microsoft.SharePoint.Search.dll, Microsoft.SharePoint.Search.xml files 3. These files are all in the bin folder coming from the development server The development server is running 64-bit SharePoint 2007 The test server is running 32-bit SharePoint 2007 4. It is likely when the 32-bit SharePoint server on the test server trying to load the Microsoft.SharePoint.Search.dll assembly (64-bit) and found that it's not compatible with the on server version of SharePoint (32-bit). There are two resolutions for this issue: On the test server, copy the Microsoft.SharePoint.dll, Microsoft.SharePoint.Search.dll, Microsoft.SharePoint.Search.xml from 12\ISAPI\ into the web service's bin folder to replace those from the development server Delete the Microsoft.SharePoint.dll, Microsoft.SharePoint.Search.dll, Microsoft.SharePoint.Search.xml files in the web service bin folder, so that .NET will attempt to load these assemblies from the test server's GAC (which should be the 32 bits version) instead. Hope it helps. If I misunderstood anything, feel free to let us know. Thanks. Best Regards, Lionel
Free Windows Admin Tool Kit Click here and download it now
April 28th, 2009 1:11pm

That pretty much covered it. It was my Admin/Testing site that was screwing the whole thing up. The Sharepoint Search DLL's had been placed in the bin folder of my Admin site. after this article I went digging further. Found it, deleted it, and all was well. I also removed existing references to the Sharepont Search DLL's from my bin folder of my sharepoint sites. Thank you so much for your answer!Jack Burnish
July 29th, 2009 8:46pm

Delete the Microsoft.SharePoint.dll, Microsoft.SharePoint.Search.dll, Microsoft.SharePoint.Search.xml files in the web service bin folder, so that .NET will attempt to load these assemblies from the test server's GAC (which should be the 32 bits version) instead. I have used this step successfully. But in the same environment, it is not working now. I even saw it working randomly. We have many developers working on the same server (may be this is completely irrelevant). Anyone observed similar random behavior?
Free Windows Admin Tool Kit Click here and download it now
September 15th, 2009 2:42pm

My fix- In development environment, when this error appears don't close the browser immediately. First delete the SharePoint related dlls from the bin and then do CTRL F5 on browser. Don't know how it works behind the scenes :S
September 17th, 2009 4:32pm

Its the same as above. The 'randomness' of your issue might be due to the fact that if you reference the Sharepoint dll in just about any application, it installs a copy of the Sharepoint.Search dll in that applications /bin folder. That is basically what you are doing when you don't close the browser immediately and then hit 'run without debugging' or CTRL - F5. Since you are running it without compiling the whole thing, it never delivers the DLL to the bin folder to break it.The overall fix - Make sure when you are referencing the Sharepoint DLL in any local application, you are getting the correct version. 32bit or 64bit.Jack Burnish
Free Windows Admin Tool Kit Click here and download it now
September 18th, 2009 9:40pm

@Lionel, Thanks a lot for your detailed post ... I also had the same problem.Development server was 32 bit & test server 86 . & I had problem accessing the Microsoft.TeamFoundation.Build.Client in the test server with a big exception page!! ##################################################### Could not load file or assembly 'Microsoft.TeamFoundation.Build.Client' or one of its dependencies. An attempt was made to load a program with an incorrect format. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.BadImageFormatException: Could not load file or assembly 'Microsoft.TeamFoundation.Build.Client' or one of its dependencies. An attempt was made to load a program with an incorrect format. Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Assembly Load Trace: The following information can be helpful to determine why the assembly 'Microsoft.TeamFoundation.Build.Client' could not be loaded. === Pre-bind state information === LOG: User = NT AUTHORITY\NETWORK SERVICE LOG: DisplayName = Microsoft.TeamFoundation.Build.Client (Partial) WRN: Partial binding information was supplied for an assembly: WRN: Assembly Name: Microsoft.TeamFoundation.Build.Client | Domain ID: 7 WRN: A partial bind occurs when only part of the assembly display name is provided. WRN: This might result in the binder loading an incorrect assembly. WRN: It is recommended to provide a fully specified textual identity for the assembly, WRN: that consists of the simple name, version, culture, and public key token. WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue. LOG: Appbase = file:///C:/Program Files/Microsoft Team Foundation Server 2010/Application Tier/Web Services/TfsBuildErrorNotifier/ LOG: Initial PrivatePath = C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Services\TfsBuildErrorNotifier\bin Calling assembly : (Unknown). === LOG: This bind starts in default load context. LOG: Using application configuration file: C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Services\TfsBuildErrorNotifier\web.config LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config. LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind). LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/tfs_tfsbuilderrornotifier/818641fa/1ac064d1/Microsoft.TeamFoundation.Build.Client.DLL. LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/tfs_tfsbuilderrornotifier/818641fa/1ac064d1/Microsoft.TeamFoundation.Build.Client/Microsoft.TeamFoundation.Build.Client.DLL. LOG: Attempting download of new URL file:///C:/Program Files/Microsoft Team Foundation Server 2010/Application Tier/Web Services/TfsBuildErrorNotifier/bin/Microsoft.TeamFoundation.Build.Client.DLL. ERR: Failed to complete setup of assembly (hr = 0x8007000b). Probing terminated. ################################################## somehow it is solved now after I deleted Microsoft.TeamFoundation.Build.Client from the .dll & yes I had all the solution files copied to the webservice's location . Thanks once again ..u saved my time!!
October 14th, 2010 4:22pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics