Introduction

The error "Could not load file or assembly 'DotNetOpenAuth.Core'" means the CLR resolved a reference to that assembly name but could not load a matching DLL at runtime. In practice, the root cause is usually one of four things: missing output files, version mismatch, bad binding redirects, or deployment that did not carry the dependency.

What the Runtime Is Trying To Do

When a .NET application starts and reaches code that depends on DotNetOpenAuth.Core, the runtime tries to locate an assembly that matches the requested identity:

• assembly name
• version
• culture
• public key token

If any of those do not line up with what is available in the application output or load context, the runtime throws the load error.

That is why "the DLL exists somewhere on my machine" is not enough. The identity still has to match what the application requested.

Start With the Output Folder

The first practical check is simple: is DotNetOpenAuth.Core.dll actually in the application's output directory?

For an old ASP.NET or desktop project, build first and inspect bin:

dotnet build
Get-ChildItem .\bin -Recurse | Where-Object { $_.Name -eq "DotNetOpenAuth.Core.dll" }

If nothing appears, the package reference, restore step, or copy-local behavior is already wrong.

Version Mismatch Is Very Common

This error often appears after package upgrades or partial manual reference changes. The project may compile against one version while the runtime finds a different one.

In older .NET Framework apps, binding redirects are often the deciding factor. If the config file still redirects to an old version, the runtime can fail even though a DLL exists.

Example app.config or web.config fragment:

1<configuration>
2  <runtime>
3    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
4      <dependentAssembly>
5        <assemblyIdentity
6          name="DotNetOpenAuth.Core"
7          publicKeyToken="2780ccd10d57b246"
8          culture="neutral" />
9        <bindingRedirect oldVersion="0.0.0.0-4.3.4.13329"
10                         newVersion="4.3.4.13329" />
11      </dependentAssembly>
12    </assemblyBinding>
13  </runtime>
14</configuration>

The exact version and token must match the package you actually ship.

Restore and Reference Problems

If the project uses NuGet, make sure restore succeeded and the reference still points at a valid package.

nuget restore MySolution.sln
msbuild MyProject.csproj /t:Clean,Build

For SDK-style projects:

dotnet restore
dotnet build

If the package is missing or the project still uses a stale local DLL reference, fix that before touching config files.

Deployment Can Break a Working Build

Sometimes the project runs locally but fails after publish or server deployment. In that case, the issue is usually not compilation but packaging.

Typical problems:

• the DLL was excluded during publish
• the server got only part of the bin folder
• a transform changed the binding redirect
• an older copy of the app is still running with stale assemblies

That is why you should compare the local working output to the deployed output, not just the project file.

Use Fusion Logs on .NET Framework

For classic .NET Framework apps, Fusion Log Viewer is extremely useful because it shows where the runtime searched and why loading failed.

The diagnostic flow is:

1. enable fusion logging
2. reproduce the failure
3. inspect the attempted bind
4. compare the requested identity to the found DLLs

This is much faster than guessing between package restore and config issues.

A Typical Fix Sequence

Use a fixed checklist:

1. clean and rebuild the solution
2. confirm DotNetOpenAuth.Core.dll exists in output
3. verify package restore or reference path
4. inspect config binding redirects
5. compare deployed files to local files
6. use Fusion logs if the reason is still unclear

That order prevents random edits that hide the original cause.

Example: Detecting a Missing Reference Early

If the package reference is broken, the project file or packages list should make that obvious.

For a classic package-based project, inspect packages.config:

<packages>
  <package id="DotNetOpenAuth.Core" version="4.3.4.13329" targetFramework="net48" />
</packages>

If the package is missing there, or if the version does not match your config redirects, runtime loading problems are expected.

Common Pitfalls

• Assuming the problem is the GAC when the real issue is a missing local DLL.
• Updating the package but forgetting to update binding redirects.
• Copying only the main application assembly during deployment and not its dependencies.
• Mixing old manual file references with NuGet-managed package references.
• Skipping Fusion logs and guessing at the cause from the exception text alone.

Summary

• The error means the runtime could not load the exact DotNetOpenAuth.Core assembly identity it needed.
• Check the output folder first, then check versions and binding redirects.
• Package restore and deployment are the most common failure points.
• In older .NET Framework apps, Fusion logs are one of the best diagnostic tools.
• Fix the reference and load path systematically instead of changing config files blindly.