How to Enable Fusion Assembly Bind Failure Logging in .NET Framework

By the end of this page, you will understand what Fusion logging is, when it is useful, how to enable it for .NET Framework applications, where to view the logs, and how developers use the information to fix missing or mismatched assembly references.

Assembly binding is the process the .NET runtime uses to find and load the DLLs an application needs.

When a .NET Framework application starts, it may try to load assemblies from several places, such as:

• the application folder
• the Global Assembly Cache (GAC)
• paths defined in configuration
• probing paths for private assemblies

If the runtime cannot find the correct assembly, or if the version, culture, or public key token does not match, the application may fail with errors such as:

• FileNotFoundException
• FileLoadException
• BadImageFormatException

Fusion is the .NET Framework assembly binding engine. Fusion logging records details about how the runtime searched for an assembly and why the bind succeeded or failed.

This matters because assembly loading problems are often hard to diagnose from the exception message alone. A simple error like "Could not load file or assembly..." does not always show:

• which exact version was requested
• where the runtime looked
• whether a binding redirect was applied
• whether the wrong CPU architecture was involved
• whether the assembly was found but rejected

Fusion logs provide that missing detail.

Important: Fusion logging applies to .NET Framework, not modern .NET (such as .NET 5, .NET 6, .NET 7, or .NET 8) in the same way. The classic Fusion log viewer is primarily a .NET Framework troubleshooting tool.

Think of assembly binding like a delivery service trying to find a package.

• Your code requests a package: a specific assembly name and version.
• The runtime checks different addresses: app folder, GAC, configured paths.
• If the package is missing or the label does not match, delivery fails.
• Fusion logging is the delivery tracking history.

Without Fusion logging, you only know that the package did not arrive. With Fusion logging, you can see:

• what package was requested
• which addresses were checked
• what was found
• why the runtime rejected it

That tracking information is what makes the problem fixable.

Fusion logging is usually enabled with the Assembly Binding Log Viewer tool, fuslogvw.exe.

Common way to enable Fusion logging

1. Open the Developer Command Prompt for Visual Studio as administrator.
2. Run:

fuslogvw

1. In the viewer:
   • choose Settings
   • select Log bind failures to disk
   • optionally select Log all binds to disk if you need more detail
   • choose a custom log path if needed
2. Reproduce the assembly loading error.
3. Refresh the log viewer and open the generated entry.

Example scenario

Suppose this C# code depends on a missing assembly:

using System;
using SomeLibrary;

class Program
{
    static void Main()
    {
        Console.WriteLine(Helper.GetMessage());
    }
}

If SomeLibrary.dll is missing, the program may throw an error like:

Could not load file or assembly 'SomeLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.

The exception tells you something failed, but Fusion logging can show:

Consider this example:

using System;
using MissingDependency;

class Program
{
    static void Main()
    {
        Console.WriteLine(Service.GetValue());
    }
}

Now walk through what happens:

1. The application starts.
2. The runtime loads Program and sees it depends on MissingDependency.
3. The runtime creates an assembly bind request using the assembly identity, including name and version.
4. Fusion begins probing for the assembly.
5. It checks locations such as:
   • the application base directory
   • private probing paths
   • the GAC, if relevant
   • paths affected by configuration
6. If the assembly is not found, or if the wrong version is found, the bind fails.
7. The runtime throws an exception such as:

FileNotFoundException: Could not load file or assembly 'MissingDependency, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'

1. If Fusion logging is enabled, a log entry is created.
2. Opening that log shows:
   • the assembly identity requested
   • the application base path
   • each attempted path
   • configuration and redirect information
   • the reason the bind failed

That sequence is why Fusion logging is so useful: it captures the runtime's search process, not just the final error.

Fusion logging is commonly used in situations like these:

• Desktop applications failing at startup

  • A WinForms or WPF app works on one machine but not another.

• Version mismatch after deployment

  • The app expects MyLibrary, Version=2.0.0.0 but only 1.0.0.0 is deployed.

• Binding redirect problems

  • An app config file contains redirects, but the runtime still cannot load the requested assembly.

• Plugin systems

  • A host application loads extensions dynamically and one plugin depends on a missing DLL.

• IIS or ASP.NET applications

  • A web application throws "Could not load file or assembly" after a publish or server update.

• GAC-related issues

  • A strongly named assembly is expected in the GAC but is missing or the wrong version is registered.

• Indirect dependency failures

  • The top-level assembly exists, but one of its own dependencies is missing. Fusion logs help expose the real missing file.

In real projects, developers usually use Fusion logging as a temporary diagnostic tool, not as a permanent setting.

Common patterns include:

Validation during deployment troubleshooting

A developer checks whether all required DLLs were copied to the output folder after a CI build or installer run.

Verifying binding redirects

If app.config or web.config contains assembly redirects, Fusion logs help confirm whether the redirect was applied correctly.

Example redirect:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="MyLibrary" publicKeyToken="32ab4ba45e0a69a1" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  

1. Assuming Fusion logging applies the same way to modern .NET

Fusion logging is mainly for .NET Framework.

If you are using .NET 5+ or later, the runtime diagnostics are different.

2. Forgetting to run the tool with enough permissions

If fuslogvw.exe is not run appropriately, logs may not appear as expected.

3. Logging everything for too long

Log all binds to disk can generate many entries and slow things down.

Use it temporarily, then turn it off.

4. Looking only at the top-level assembly

Sometimes the reported assembly is present, but one of its dependencies is missing.

Fusion logging helps reveal nested dependency failures.

5. Ignoring architecture mismatches

This code may compile but fail at runtime if the dependency architecture is wrong:

// Example situation, not the direct cause in code:
// App built for x86 tries to load an x64-only native dependency indirectly.

That can lead to errors that look similar to normal binding problems.

6. Forgetting to disable logging afterward

Leaving verbose binding logs enabled can clutter the machine and waste time during future debugging.

7. Misreading the version in the exception

Broken assumption:

Fusion logging = .NET Framework assembly bind logging
Main tool = fuslogvw.exe
Use it for = "Could not load file or assembly" errors

Quick steps

1. Open Developer Command Prompt for Visual Studio.
2. Run fuslogvw.
3. Open Settings.
4. Choose Log bind failures to disk.
5. Reproduce the error.
6. Refresh and open the log entry.
7. Check:
   • requested assembly name
   • version
   • public key token
   • probing paths
   • redirect information
8. Disable logging when finished.

What to look for in the log

• DisplayName → exact assembly requested
• Appbase → application base folder
• Attempting download → where the runtime looked
• redirect info → whether config changed the requested version
• final failure message → why loading failed

Common causes of bind failures

• missing DLL
• wrong assembly version
• incorrect binding redirect
• missing indirect dependency
• GAC mismatch
• x86/x64 architecture mismatch

Important note

Fusion logging is mainly for .NET Framework.

How do I enable Fusion logs in .NET Framework?

Run fuslogvw.exe, open Settings, and enable Log bind failures to disk. Then reproduce the error and inspect the generated log entry.

Where is fuslogvw.exe located?

It is commonly available through Visual Studio developer tools or the Windows SDK. The easiest way to launch it is usually from a Developer Command Prompt.

Does Fusion logging work for .NET 6 or .NET 8?

Not in the classic .NET Framework sense. Fusion is primarily a .NET Framework assembly binding tool.

What does "Could not load file or assembly" usually mean?

It usually means the runtime could not find the required assembly, found the wrong version, or found an assembly whose identity did not match the request.

Should I log all binds or only failures?

Start with failures only. Use all binds only when you need deeper diagnostics.

Why does the assembly file exist but loading still fails?

The file name alone is not enough. The runtime also checks version, culture, public key token, configuration redirects, and dependencies.

Can Fusion logs help with indirect dependency issues?

Yes. Often the top-level assembly is present, but one of its dependent assemblies is missing or mismatched.

Do I need to disable Fusion logging afterward?

Yes. It is best to turn it off after troubleshooting to avoid unnecessary log generation.

• Assembly loading — Fusion logging exists to explain how assembly loading succeeds or fails.
• Global Assembly Cache (GAC) — Strongly named assemblies may be loaded from the GAC.
• Binding redirects — Redirects can change which assembly version the runtime loads.
• Strong naming — Public key tokens and identity matter during binding.
• NuGet package management — Package version mismatches often lead to binding issues.
• FileNotFoundException — A common exception when assembly binding fails.
• FileLoadException — Happens when an assembly is found but cannot be loaded correctly.
• x86 vs x64 architecture — Platform mismatches can appear similar to assembly load failures.