We Keep Coding

Could not load file or assembly...even when 'correct' version is found

This seems like the standard issue of an incorrect version of a DLL is being found and to put an assembly binding redirect (or update the DLL version referenced) to resolve. However...
The full error message appearing is;
System.IO.FileLoadException: Could not load file or assembly 'Microsoft.SqlServer.Smo, Version=15.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Microsoft.SqlServer.Smo, Version=15.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91'
at DatabaseManagement.clsDatabaseManagement.DeployDatabase(clsDatabaseDeploymentElement deployment, String scriptPath, String dataFilePath, String logFilePath)
at DatabaseManagement.clsDatabaseManagement.DeployDatabase(clsDatabaseDeploymentElement deployment) in C:\agent\_work\4\s\src\Database\DatabaseManagement\DatabaseManagement.cs:line 920
at DBAdmin.clsProgram.ProcessAction(Action action, clsDatabaseManagement manager) in C:\agent\_work\4\s\src\Database\DBAdmin\Program.cs:line 664
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
Processing aborted!
Picking apart that message, the file it's looking for is 'Microsoft.SqlServer.Smo, Version=15.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91'.
The file it's finding is: 'Microsoft.SqlServer.Smo, Version=15.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91'
The strings are identical.
The assembly binding configuration;
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.SqlServer.Smo" publicKeyToken="89845dcd8080cc91" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-15.0.0.0" newVersion="15.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
A hindrance here is that .NET's assembly binding logging doesn't appear to be in effect (as per the error message). I've gone through the steps to enable it but it remains disabled. The registry settings are correctly set and persist after a restart. It...just doesn't work, and the text that it's not enabled still appears as part of the error message.
What I've tried/confirmed so far;
The correct version of the DLL is present in the exe's folder (v15)
The dependencies of the DLL are also present in the same folder (dependencies found via ilasm, and cross-checked with ilspy)
The specific version of .NET that is used by the DLL (v15 was build on .NET 4.5), is installed and present on the target machine
The assembly binding config is being used, as if I change the newVersion to 16.0.0.0, the message changes accordingly
Registering the correct version of the file into the GAC completed successfully but had no effect on the error message.
Putting v16 of the DLL into the exe's folder had no effect on the message. It still finds v15. This suggests the binding is not looking at the DLLs in the exe's folder (at least for that assembly).
The various tests point me at the conclusion that it is finding the correct version of the file (somewhere, I'm assuming the GAC), but that there is some other incompatibility that's triggering the error message.
Without the Fusion logs, I'm left with black-box testing to try and diagnose.

The solution was ultimately the usual one, putting in the appropriate assembly binding redirects, but getting the right redirect was a bit of a journey.
The message displayed (assuming that .NET's binding logging is not enabled) is the assembly's display name. This string contains a version as part of it but this is distinct from the assembly's actual version or file version. This can make figuring out what's going on, as well as the correct binding, troublesome.
The display name will get shown as part of the error message. In Windows Exporer, right-clicking and going to Properties and the Details tab will list the file version. Getting the actual version was a bit trickier but you can use ildasm or ILSpy to open the dll and look.
In my case, the message was correct for the display name - they are indeed the same. What was actually happening is that the assembly being found was registered as 15.100.0.0, not 15.0.0.0, so there was a minor version mis-match. A further annoyance is that the assembly in the GAC was actually the correct version (I did a bit comparison to be sure), but had been registered incorrectly.
I was able to find this out by getting the binding logging turned on. While I had set the registry settings manually, they weren't functional. I used FusionLog++ to capture the binding steps, and these clearly showed;
the assembly it was finding
the reason for the binding failure
Some nuances to keep in mind when assessing the bindings/references;
there are some expected binding failures that are normal but will show as an error in the logs
some assembles will look for a *.resources.dll with the local culture setting (e.g., it may look for en-US, then en). This is normal and if those assembles don't exist, .NET will use the strings in the calling DLL.
some assembles look for msvcm90.dll (or there's no specified calling assembly in the log). This can be ignored.
if your application uses the XmlSerializer object, the .NET logic will look for an assembly YourApplication.XmlSerializers.dll. This is by design and can be ignored.
the binding will look in the GAC first for the referenced assembly. If found, this will ignore any DLL in the same folder as the application. It won't matter if you have the correct version deployed with your app if the target machine has a version in the GAC.
if your application is being built in a pipeline, the VM doing the build will need the appropriate 3rd party libraries installed if they are not specified by Nuget. Ensure they are the correct/same version as your development/target machine.
reference external packages via Nuget where possible rather than a direct reference

Could not load file or assembly 'PdfSharpCore, Version=1.3.40.0

I am using PdfSharpCore version 1.3.40 in a MVC ASP.Net netcoreapp2.1 and it works perfectly on my windows localhost, but when I publish it on a server Linux running Apache the follow exception occurs:
Could not load file or assembly 'PdfSharpCore, Version=1.3.40.0, Culture=neutral, PublicKeyTo ken=null'. The system cannot find the file specified.
I already checked that the PdfSharpCore dll is there, but the system couldn't find it.
Does anyone know what's going on?

We managed to solve the problem, we were forgetting to replace the .deps.json file that contains the dependencies with the new PdfSharpCore.dll dll included in the project. Solved!

Application requires that assembly office version 12.0.0.0 be installed in GAC

I have a .csproj that I want to publish to a clickonce server.
When I publish the application from one development computer it works and the program can be started from the server without any problems.
I download the same project from svn to another computer and try to publish it. That step kinda works, i guess, since the program is published successfully without any errors.
But when I try to start the program from the server I get the error:
Application requires that assembly office version 12.0.0.0 be installed in the Global Assembly Cache(GAC) first.
Update: (also posted info in comments). I am receiving this warning on both machines though I don't know how to solve. But it's probably the cause of the problem I guess:
No way to resolve conflict between "office, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" and "office, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c". Choosing "office, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" arbitrarily.
1> Consider app.config remapping of assembly "office, Culture=neutral, PublicKeyToken=71e9bce111e9429c" from Version "12.0.0.0" [C:\Windows\assembly\GAC\office\12.0.0.0__71e9bce111e9429c\office.dll] to Version "14.0.0.0" [D:\Visual Studio\Visual Studio Tools for Office\PIA\Office14\office.dll] to solve conflict and get rid of warning.

So I finally solved this.
First I thougt I'd describe how the project looked. Under references there was no reference to the office.dll file though this actually ended up in the published directory when computer1, which was able to publish a working copy, published the project. Also under properties->publish->ApplicationFiles the office.dll was listed as exluded.
computer2, which couldn't publish a working project, had the same installed programs as computer1. So I tried to add the reference to office.ddl, set it to copy local and include it in applicationfiles. Now there was a office.dll copied to the published directory but the same error appeared. installed and re-installed a bunch of programs, no improvement. After I've been trying alot of randomstuff I ended up copying the dll from computer1, referenced it, set it to copy local and included it. And, voila, it worked?

Could not load file or assembly 'AjaxControlToolkit, Version=4.1.7.1213

I have Publish Project with reference of Ajax Version=4.1.7.1213 and deployed single page(Not ajax dll version 4.1) at Other machine (that machine having ajax version 1.0).
It shows me error like:Could not load file or assembly 'AjaxControlToolkit, Version=4.1.7.1213
But when I Publish again with reference of Ajax Version=1.0 and deployed same single page at Other machine (that machine having ajax version 1.0). Its work fine.
My question is When DLL get created after Publish is it stored reference of Ajax Version.
Please help

Edit the web.config file to remove the reference, which is not required for normal operation:
1 - Open the web.config file in the root of your site
2 - Find the following line and comment it out():xxxxx-is your assembly name.
<add assembly="xxxxx", Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
3 - Save and close the web.config file and try again
ref : Mismatch in Assembly and Product Version

I'm not sure if I understand you correctly. If your project is dependent on AjaxControlToolkit, Version=4.1.7.1213 you should make sure that it is available on target machine.

C# AWS Could not load file or assembly 'AWSSDK

When I publish my app to my server, and call a function which is dealing with Amazon SQS, I'm getting the following error:
ErrorMessage: "Could not load file or assembly 'AWSSDK, Version=1.5.19.0, Culture=neutral, PublicKeyToken=9f476d3089b52be3' or one of its dependencies. The system cannot find the file specified."
However the same method works fine in the localhost.
How should I solve this problem ?
Thanks.

Most common cause is the .dll is not present in the bin folder of your publish web-site.
Verify that the bin folder contains the AWSSDK.dll file.
You can ensure that the .dll is copied by setting the "Copy Local" proprety of your reference to true

I had this problem with the MysticMind port of the HtmlAgilityPack
Could not load file or assembly 'MysticMind.HtmlAgilityPack, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. Access is denied.
The problem was the version number - the nuGet package is tagged as version 1.0.0, but in the .csproj file of the source I found that the actual version was 1.4.9.4 (the version of the upstream package). I fixed it by changing the version number in my own .csproj file.

My DLLs were being copied to the bin properly but I was still getting the error.
My project was in SVN I resolved this by getting a fresh copy of the dll from svn and then doing a clean and build.
Seems somehow the dlls got corrupted or something.

In my case, it happened because my App.config file contained:
<configSections>
<section name="aws" type="Amazon.AWSSection, AWSSDK"/>
</configSections>
I included it blindly from the doc here. It has a new example on the top but the old ones are in the examples below. The right way now is:
<configSections>
<section name="aws" type="Amazon.AWSSection, AWSSDK.Core"/>
</configSections>
I sent feedback to AWS (March 21, 2022) and hope they will fix it soon