Infamous assembly binding error

I really need help on this because I lost my hopes to correct the problem.

I am using Office Communications Server 64bit libraries. There are 3 dlls I use in the project, Microsoft.Rtc.Collaboration.dll, Microsoft.Rtc.Internal.Media.dll and SIPEPS.dll. I am not sure about Microsoft.Rtc.Collaboration but Internal.Media and SIPEPS are both x64. On the GAC assembly list Rtc.Collaboration shows MSIL under Processor Arhitecture and the others show AMD64.

My project compiles without errors with these references but at runtime I receive the error:

Could not load file or assembly 'Microsoft.Rtc.Internal.Media' or one of its dependencies. An attempt was made to load a program with an incorrect format.

I tried compiling the project with CPU set to Any CPU but nothing changes. With both under x64 and x86 setting I receive this error.

Any help is appreciated.

UPDATE: Below is the assembly binding log.

=== Pre-bind state information ===
LOG: User = CONTOSO\elodie
LOG: DisplayName = Microsoft.Rtc.Internal.Media
 (Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: Microsoft.Rtc.Internal.Media | Domain ID: 9
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:/Users/elodie/Documents/Visual Studio 2010/Projects/TFS/proto/Main/Source/WebBot.Web/
LOG: Initial PrivatePath = C:\Users\elodie\Documents\Visual Studio 2010\Projects\TFS\proto\Main\Source\WebBot.Web\bin
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Users\elodie\Documents\Visual Studio 2010\Projects\TFS\proto\Main\Source\WebBot.Web\web.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\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/Framework/v4.0.30319/Temporary ASP.NET Files/root/e3d82f59/764fa8c3/Microsoft.Rtc.Internal.Media.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/e3d82f59/764fa8c3/Microsoft.Rtc.Internal.Media/Microsoft.Rtc.Internal.Media.DLL.
LOG: Attempting download of new URL file:///C:/Users/elodie/Documents/Visual Studio 2010/Projects/TFS/proto/Main/Source/WebBot.Web/bin/Microsoft.Rtc.Internal.Media.DLL.
ERR: Failed to complete setup of assembly (hr = 0x8007000b). Probing terminated.

In my case i got this issue because i was running a web project compiled for x64 using IISExpress. I fixed the issue by checking the following setting in Visual Studio:

Tools | Options | Projects and Solutions | Web Projects | Use the 64 bit version of IIS Express

Hope this helps anyone else with this same scenario and issue

I had this problem with ASP.NET IIS and after trying everything, I enabled 32-bit for my app pool and restarted the application pools. Then it worked.

In the IIS7 Manager: Application Pools -> DefaultAppPool -> Advanced Settings -> Set "Enable 32-bit applications" to true.

Also make sure the correct .Net version is selected.

I also set the ISAPI 64bit to allowed under "ISAPI and CGI Restrictions", but I'm not sure if that helped.

Replaced the 64bit versions of all the three dlls with their 32 bit versions, cleaned Temporary ASP.NET files folder and compiled again. Now works without problems. Thanks for the help.

Try setting Copy Local in solution explorer for those assemblies and make sure they are being dropped into the folder's specified in the binding log.

Also, they were probably built using the V2 CLR. If they were, you'll have to enable Mixed Mode binding by adding this to your web/app config

<configuration>
   <startup  useLegacyV2RuntimeActivationPolicy="true">
       <supportedRuntime version="v4.0"/>
  </startup>
</configuration> 

To solve this, I ensured all my projects used the same version by running the following command and checking the results:

update-package Newtonsoft.Json -reinstall

And, lastly I removed the following from my web.config:

  <dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
  </dependentAssembly>

I know this is an old question, but still seems to be a popular result when searching for a solution regarding a partial binding error in Visual studio. I had experienced a very similar issue to the original poster, but with the EntityFramework.dll and Visual studio 2015 (.ASP Web Forms project), however, the solution I found relates to a broad problem. Since I didn't find any answers similar to my solution, I thought it might be helpful to contribute what I found, and I hope it does help someone.

In my web.config I am impersonating a domain user that is a service account. This service account did not have access to my Temporary files folder, therefore when debugging, it could not copy the dlls out there, and therefore could not load them.

What finally tipped we off was going and physically looking in the temporary folder mentioned in the error message. In the original question above, you'll notice the lines "Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files..." When I looked in that folder, my DLLs were not there.

The solution for me was this: Since I was using 64bit environment, and impersonating a domain account, I added the domain service account user to my local C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files folder with write (and modify - for good measure) access.

Bottom line - make sure your Temp files folder grants write access to the user your app is running as.

This is an old question, but was still the top result when I had this same issue today. I had switched my project compilation in Visual Studio to target x64 instead of 'All CPUs' (it's on a 64-bit machine). As per the other answers, there would be two ways to fix it - either change everything to 32-bit or everything to 64-bit. In this case, I needed 64-bit.

KabanaSoft's answer worked perfectly for me. Still correct as of Visual Studio 15.6.6.

I was getting the error when trying to run the web application from Visual Studio, but in my case the answer was simple. When I read the exception carefully I could see that the assembly in question was no longer used by the application but a copy was still in the bin folder. After the offending assembly was removed, the error vanished.

In my case I had gone through my site and replaced the name of the site with a new name. I inadvertently replaced the 'PreviousWebSiteName' with the 'NewWebSiteName' in Web.config where the assembly name was being specified.

    <pages enableSessionState="false" enableViewStateMac="true" enableEventValidation="true" controlRenderingCompatibilityVersion="4.0" clientIDMode="AutoID">
  <controls>
    <add assembly="NewWebSiteName" namespace="App_Code.Controls" tagPrefix="blog" />
  </controls>
</pages>

The site was still building an assembly with the old name - I only intended to change the site name where it was appearing on the pages of the site; I didn't need to change anything internally. Restoring the Web.config entry as it was before my naming change (resulting in an entry that matched the name of the built assembly) resolved the error for me.

In my case I had some crap in my web.config, specifically a half-commented out httpHandler that once I cleaned that up, my binding issue disappeared.

This answer helps too if you only have one or a few projects in your solution that require 32bits IIS:

Add

<Use64BitIISExpress>false</Use64BitIISExpress> 

under the tag of your csproj project.

It's also available through the UI by clicking on project properties -> Web tab -> Bitness (change to x64).

Answer from: Override iis 64 option per project

With this you can leave the option in Web Projects as is. (see KabanaSoft's answer)