Infamous assembly binding error

Question

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.

Acceptable

always actual... excelent title... – Barriebarrientos

Answer 1

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.

Acceptable

I had the problem with the Microsoft.Dynamics.GP.eConnect DLLs. It turned out my dev environment was loading the 64 bit DLL from the GAC but the project's lib folder had the 32 bit DLL. The 32 bit version was being deployed. In VS2010, check where the DLL is pulled from in the Output window with Show output from set to Debug – Depressomotor

Answer 2

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

Lease

What version of VS do you use? I don't have that option in VS 2012, but I have two of these. 1. Use IIS Express for new file-based web sites and projects. 2. Warn before running web applications when there are errors in the eror list. – Durance

Answer 3

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.

Civil

Thank you so much for this instant easy fix. It bothered me for hours. – Cutaway

I am wondering if one step is missing in your action. Here is what I did (note the extra DefaultAppPool) Application Pools -> DefaultAppPool > Advanced settings -> set "Enable 32-bit. applications" to true. DefaultAppPool is the one used for the app with the problem. – Cutaway

Instructions with images can be seen at beyondrelational.com/modules/2/blogs/45/posts/12032/… – Wheelwork

Remember to make sure that your application is running under the selected App Pool. – Vehicular

This answer! I've been trying to figure this out for the last two days. Thank you! – Placentation

Answer 4

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> 

Reverence

Thanks Jaimal. Copy Local is set to true for all three of them. And useLegacyV2RuntimeActivationPolicy is already added in web.config. Any other options? – Darrick

Answer 5

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>

Sindee

Answer 6

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. 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.

Fingertip

Answer 7

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.

Bratton

Answer 8

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.

Nitpicking

Answer 9

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.

Talus

Answer 10

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.

Unwitnessed

Answer 11

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)

Meill