Erroneous assembly binding error

I really need help with this because I have lost my hope of fixing the problem.

I use the 64-bit Office Communications Server libraries. The project uses three DLLs, Microsoft.Rtc.Collaboration.dll, Microsoft.Rtc.Internal.Media.dll and SIPEPS.dll. I'm not sure about Microsoft.Rtc.Collaboration, but Internal.Media and SIPEPS are both x64. In the GAC build list, Rtc.Collaboration shows MSIL in the Processor Architecture section, and in others - AMD64.

My project compiles without errors with these links, but at runtime I get an error message:

Failed to load file or assembly "Microsoft.Rtc.Internal.Media" or one of its dependencies. An attempt was made to download a program with the wrong format.

I tried to compile the project with the CPU installed in Any CPU, but nothing changed. Both when setting up x64 and in x86, I get this error.

Any help is appreciated.

UPDATE: The assembly binding log is presented below.

=== 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. 
+53
64bit visual-studio-2010
Sep 19 '10 at 12:13
source share
9 answers

Replaced the 64-bit versions of all three DLLs with their 32-bit versions, cleared the Temporary ASP.NET folder and compiled it again. Now it works without problems. Thanks for the help.

+18
Sep 19 '10 at 13:19
source share

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

In IIS7 Manager: Application Pools → DefaultAppPool → Advanced Settings → Set Enable 32-bit Applications to true.

Also make sure that the correct version of .Net is selected.

I also installed 64-bit ISAPI to allow ISAPI and CGI restrictions, but I'm not sure if that helped.

+57
Mar 29 '12 at 19:20
source share

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

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

Hope this helps someone else with the same script and release

+42
Dec 04 '14 at 23:50
source share

Try the Copy Local setting in the solution explorer for these assemblies and make sure that they are deleted in the folder specified in the binding log.

In addition, they were probably built using the V2 CLR. If that were the case, you need to enable mixed mode binding by adding this to your website / application configuration

 <configuration> <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0"/> </startup> </configuration> 
+3
Sep 19 '10 at 12:32
source share

I know this is an old question, but still seems like a popular result when looking for a solution regarding a partial binding error in Visual Studio. I ran into very similar problems with the original poster, but with the EntityFramework.dll project and Visual studio 2015 (ASP.NET Web Forms project), however, the solution I found relates to a wide problem. Since I did not find answers similar to my solution, I thought it would be useful to contribute what I found, and I hope this helps someone.

In my web.config, I impersonate a domain user who is a service account. This service account did not have access to the temporary files folder, so when it was debugged, it could not copy the DLL files and, therefore, could not download them.

Which finally brought us to the past and physically looked in the temporary folder mentioned in the error message. In the original question above, you will see the line "Attempting to load a new file URL: /// C: /Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files ..." When I looked in this folder my DLLs didn’t It was.

The solution for me was as follows: since I was using a 64-bit environment and posing as 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 with writeability (and changes - for a good grade).

Bottom line - make sure that the folder with Temp files provides write access to the user who runs your application.

+2
Feb 06 '17 at 17:24
source share

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

 update-package Newtonsoft.Json -reinstall 

And finally, 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> 
+1
Nov 12 '14 at 16:34
source share

I was getting an error when trying to start a web application from Visual Studio, but in my case the answer was simple. When I carefully read this exception, I saw that this assembly is no longer used by the application, but the copy is still in the bin folder. After the remote assembly was deleted, the error disappeared.

0
Jun 30 '14 at 11:15
source share

In my case, I went through my site and replaced the site name with a new name. I inadvertently replaced "PreviousWebSiteName" with "NewWebSiteName" in Web.config, where the assembly name was 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 the assembly with the old name - I just wanted to change the name of the site where it appeared on the site pages; I did not need to change anything internally. Restoring the Web.config entry, as it was before the name change (as a result of which the entry coinciding with the name of the built-in assembly), allowed me an error.

0
Apr 24 '15 at 9:40
source share

In my case, I had some kind of crap in my web.config, in particular, half commented on httpHandler, that as soon as I cleaned it up, my binding problem disappeared.

0
Jun 24 '15 at
source share



All Articles