Introduction

Listing all loaded assemblies in a .NET process is useful for debugging dependency issues, plugin loading, version conflicts, and runtime diagnostics. The standard answer is AppDomain.CurrentDomain.GetAssemblies(), but it also helps to understand what "loaded" really means and when some assemblies may not appear yet.

The Basic API

The simplest way to list loaded assemblies is:

1using System;
2using System.Linq;
3
4class Program
5{
6    static void Main()
7    {
8        var assemblies = AppDomain.CurrentDomain.GetAssemblies()
9            .OrderBy(a => a.GetName().Name);
10
11        foreach (var assembly in assemblies)
12        {
13            Console.WriteLine($"{assembly.GetName().Name} - {assembly.Location}");
14        }
15    }
16}

This returns the assemblies currently loaded into the application's default AppDomain.

What "Loaded" Means

Assemblies are usually loaded on demand. If code has never referenced a library and nothing else forced it to load, it may not appear in the list yet.

That means the output is a snapshot of runtime state, not a list of every assembly the application could possibly use. This distinction matters when debugging lazy-loaded plugins or optional features.

Useful Details to Print

Often the assembly name alone is not enough. Common details worth printing include:

• simple name
• version
• full name
• physical path

1foreach (var assembly in AppDomain.CurrentDomain.GetAssemblies())
2{
3    var name = assembly.GetName();
4    Console.WriteLine($"{name.Name} {name.Version}");
5    Console.WriteLine(assembly.FullName);
6}

This is especially useful when you suspect a version mismatch or duplicate dependency load.

Watching Future Loads

If you want to know when assemblies are loaded later during runtime, subscribe to the load event:

1using System;
2
3class Program
4{
5    static void Main()
6    {
7        AppDomain.CurrentDomain.AssemblyLoad += (_, args) =>
8        {
9            Console.WriteLine($"Loaded: {args.LoadedAssembly.FullName}");
10        };
11
12        // Application code continues here.
13    }
14}

This is useful in plugin hosts, test runners, or large applications where assemblies appear long after startup.

.NET Core and Load Contexts

In modern .NET, AppDomain.CurrentDomain.GetAssemblies() is still the common practical answer, but assembly loading can also involve multiple AssemblyLoadContext instances. That matters mainly in advanced scenarios such as plugin isolation.

If you are debugging one of those systems, remember that an assembly may be loaded in a specific context for isolation reasons. The everyday listing API is still helpful, but the broader load-context design may explain behavior that looks surprising.

Tools Outside Code

You do not always need to write code for this. IDE and diagnostic tools can also show loaded assemblies or modules while debugging. Those views are helpful when you need a quick look without changing the program source.

Code is still the best choice when you need logging in production or inside an automated diagnostic path.

Logging for Runtime Diagnostics

If assembly issues happen only in customer environments, logging the loaded assemblies at startup can save a lot of guesswork. A compact runtime dump of names, versions, and paths often makes version conflicts obvious much faster than reading project files.

Common Pitfalls

• Expecting unloaded but referenced assemblies to appear in the list.
• Printing only simple names and missing version conflicts.
• Assuming one assembly name means one version, even when multiple contexts or copies exist.
• Forgetting that single-file deployments and runtime loading strategies can affect Location.
• Using assembly lists as if they were a complete dependency graph rather than a runtime snapshot.

Summary

• 'AppDomain.CurrentDomain.GetAssemblies() is the usual way to list loaded assemblies.'
• The list reflects what is loaded now, not every assembly the app could ever use.
• Print version and path information when debugging dependency issues.
• Use the AssemblyLoad event if you want to observe future loads.
• For advanced plugin scenarios, assembly load contexts can matter too.