Introduction

In .NET, you usually do not "append a folder" to a mutable global assembly search path the way you might tweak an environment variable. The practical runtime solution is to handle assembly resolution explicitly and load missing assemblies from a known directory.

Understand the Real Mechanism

When the runtime cannot locate an assembly through its normal rules, it raises a resolution hook. In .NET Framework that hook is AppDomain.CurrentDomain.AssemblyResolve. In modern .NET, plugin scenarios often use AssemblyLoadContext.

So the solution is not "tell .NET to always probe this random folder forever." The solution is:

• choose a specific directory
• subscribe to the resolution event before the first load fails
• load only the assembly you actually expect from that folder

.NET Framework Example with AssemblyResolve

This pattern works well for desktop or service applications on .NET Framework.

1using System;
2using System.IO;
3using System.Reflection;
4
5class Program
6{
7    static void Main()
8    {
9        string pluginFolder = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "plugins");
10
11        AppDomain.CurrentDomain.AssemblyResolve += (sender, args) =>
12        {
13            string assemblyName = new AssemblyName(args.Name).Name + ".dll";
14            string candidatePath = Path.Combine(pluginFolder, assemblyName);
15
16            if (!File.Exists(candidatePath))
17            {
18                return null;
19            }
20
21            return Assembly.LoadFrom(candidatePath);
22        };
23
24        var plugin = Assembly.Load("MyPlugin");
25        Console.WriteLine(plugin.FullName);
26    }
27}

The important part is that the handler only resolves assemblies from the directory you control. It does not blindly load whatever name was requested from arbitrary locations.

Modern .NET with AssemblyLoadContext

In modern .NET, especially for plugin systems, AssemblyLoadContext is the cleaner abstraction.

1using System;
2using System.IO;
3using System.Reflection;
4using System.Runtime.Loader;
5
6string pluginFolder = Path.Combine(AppContext.BaseDirectory, "plugins");
7
8AssemblyLoadContext.Default.Resolving += (context, assemblyName) =>
9{
10    string path = Path.Combine(pluginFolder, assemblyName.Name + ".dll");
11
12    if (!File.Exists(path))
13    {
14        return null;
15    }
16
17    return context.LoadFromAssemblyPath(path);
18};
19
20Assembly pluginAssembly = Assembly.Load("MyPlugin");
21Console.WriteLine(pluginAssembly.FullName);

This is better aligned with current .NET runtime behavior than older AppDomain-centric patterns.

When Configuration Is Better Than Runtime Code

If the folder is known up front and never changes, configuration may be simpler than runtime resolution logic. On .NET Framework, probing paths in app configuration can be appropriate for private assemblies. For plugin folders discovered dynamically at runtime, event-based resolution is more flexible.

A good rule is:

• static folder known at startup: prefer configuration if available
• dynamic folder chosen at runtime: use resolution hooks

Safety and Design Considerations

Loading assemblies from extra folders changes more than convenience. It also changes trust and versioning boundaries.

Be careful about:

• loading an unexpected DLL with the same simple assembly name
• mixing incompatible dependency versions
• creating resolution loops by triggering another unresolved load inside the handler

A defensive handler should only resolve assemblies from a small, known set and should return null for everything else so the runtime can continue its normal failure behavior.

You can also load a dependency directly from path if you already know what file you want:

1using System.Reflection;
2
3Assembly asm = Assembly.LoadFrom(@"C:\apps\plugins\ReportingPlugin.dll");
4Console.WriteLine(asm.GetName().Name);

That is useful when you are not trying to extend general probing behavior, but only want one explicit assembly.

Plugin-Friendly Structure

If you control the application architecture, a cleaner design is to give each plugin its own folder with its dependencies next to it. Then the resolver only has to map assembly names into that folder. That is easier to reason about than maintaining a long shared list of extra directories.

In larger systems, the problem is often not "how do I add another path" but "how do I keep dependency ownership clear." A controlled plugin layout usually solves both.

Common Pitfalls

Registering the resolver after the first assembly load attempt is too late. Subscribe before the code path that needs the dependency.

Loading every unresolved assembly from the same folder without checking the requested name can accidentally bind the wrong DLL.

Using Assembly.LoadFrom repeatedly with loose path logic can create confusing version and load-context issues.

Treating runtime assembly resolution as a substitute for clear packaging can turn dependency management into a long-term maintenance problem.

Summary

• In .NET, the practical way to use an extra assembly folder at runtime is to handle assembly resolution explicitly.
• Use AppDomain.CurrentDomain.AssemblyResolve on .NET Framework and AssemblyLoadContext in modern .NET scenarios.
• Resolve only known assemblies from known paths.
• Prefer configuration for static probing needs and runtime hooks for dynamic plugin paths.
• Keep the folder strategy narrow and explicit to avoid security and versioning problems.