How to Get the Current Assembly Path in C#

By the end of this page, you will understand how assembly paths work in C#, why unit test runners can make them confusing, and how to choose the right API for finding either the executing assembly, its directory, or the application base directory.

In C#, there are several different "paths" you might mean when you ask for the assembly path:

• Current working directory: where the process is currently running from
• Assembly file location: the path to the loaded DLL or EXE
• Assembly code base: the original path the assembly was loaded from
• Application base directory: the base folder the runtime uses to resolve assemblies

These are not always the same.

This matters especially in unit tests, because test runners often do one or more of these things:

• launch your tests from their own installation folder
• change the current working directory
• shadow copy your test assembly into a temporary folder before loading it

That means code like Environment.CurrentDirectory or even Assembly.Location may not point to your original project output folder.

A commonly useful distinction is:

• Use Assembly.Location when you want the actual file path of the loaded assembly.
• Use AppDomain.CurrentDomain.BaseDirectory when you want the runtime's base folder for loading files.
• Use Assembly.CodeBase or Assembly.GetName().CodeBase only when you specifically need the original source URI, keeping in mind it is a URI, not a normal file path.

For many test scenarios, the safest choice is not "the assembly that originally lived in bin\Debug" but rather the directory where the test runner expects dependent files to exist at runtime. In modern code, that usually means copying test files to the output directory and reading them from AppContext.BaseDirectory or AppDomain.CurrentDomain.BaseDirectory.

Think of your code as an actor performing on a stage.

There are several locations you could ask about:

• Where the theater building is → the host process folder
• Where the actor is standing right now → current working directory
• Which dressing room the actor was loaded from → assembly location
• Which theater the show uses as home base → app domain base directory
• Where the actor originally came from before being moved backstage → code base

A test runner may move your assembly to a temporary backstage area before running it. So if you ask, "Where is the DLL?" you may get the temporary shadow-copy folder, not your original bin\Debug folder.

That is why the right answer depends on what you actually need:

• original source location
• runtime location
• runtime base folder for test files

The most common APIs are:

using System;
using System.IO;
using System.Reflection;

1. Get the loaded assembly's file path

string assemblyPath = Assembly.GetExecutingAssembly().Location;
string assemblyDirectory = Path.GetDirectoryName(assemblyPath);

This gives the path of the assembly containing the currently executing code.

2. Get the directory of a specific type's assembly

string assemblyPath = typeof(DaoTests).Assembly.Location;
string assemblyDirectory = Path.GetDirectoryName(assemblyPath);

This is often clearer than GetExecutingAssembly() because it explicitly refers to the assembly containing DaoTests.

3. Get the application base directory

string baseDirectory = AppDomain.CurrentDomain.BaseDirectory;

This is often the best choice for loading runtime files in tests or apps.

4. Get the original code base URI

string codeBase = typeof(DaoTests).Assembly.CodeBase;
Uri uri = new Uri(codeBase);
string originalPath = uri.LocalPath;
string originalDirectory = Path.GetDirectoryName(originalPath);

This may point to the original location even when shadow copying is used, but it returns a URI, so you must convert it.

Practical example

using System;
using System.IO;
using System.Reflection;

public static class TestFileHelper
{
    public static string GetTestDataPath(string fileName)
    {
        string baseDir = AppDomain.CurrentDomain.BaseDirectory;
        return Path.Combine(baseDir, "TestData", fileName);
    }
}

If sample.xml is copied into TestData under the runtime output folder, you can load it reliably with:

string path = TestFileHelper.GetTestDataPath("sample.xml");

This avoids depending on the original project folder layout.

Consider this code:

using System;
using System.IO;
using System.Reflection;

class Program
{
    static void Main()
    {
        string location = typeof(Program).Assembly.Location;
        string folder = Path.GetDirectoryName(location);
        Console.WriteLine(location);
        Console.WriteLine(folder);
    }
}

Step by step

1. typeof(Program) gets metadata for the Program class.
2. .Assembly gets the assembly that contains that class.
3. .Location returns the full file path of the loaded assembly.
   • Example:
   • C:\projects\MyApp\bin\Debug\MyApp.dll
4. Path.GetDirectoryName(location) removes the file name.
   • Result:
   • C:\projects\MyApp\bin\Debug
5. Console.WriteLine prints both values.

What changes under a test runner?

If the runner shadow copies your DLL, step 3 may instead return something like:

C:\Users\you\AppData\Local\Temp\...\MyTests.dll

That is not wrong. It is the actual loaded location.

If you instead inspect CodeBase, you may get the original source path as a URI:

file:///C:/projects/myapplication/daotests/bin/Debug/daotests.dll

You would then convert it to a local file system path before using it.

This concept appears in many everyday situations:

Loading configuration or data files

A desktop app may read a JSON or XML file stored next to the executable.

string configPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "appsettings.json");

Unit tests using sample files

Tests often need fixture files such as:

• XML payloads
• JSON samples
• CSV imports
• image files

Instead of relying on the project source folder, developers usually copy these files into the output directory and load them from the base directory.

Plugins and extensions

A plugin may need to locate files stored relative to its own DLL.

string pluginDir = Path.GetDirectoryName(typeof(MyPlugin).Assembly.Location);

Logging and exports

An application may write logs or generated files relative to its runtime folder.

Scripts and tools

Command-line tools often use the executable directory as a stable reference point for bundled resources.

In real projects, developers usually avoid hard-coding assumptions about bin\Debug paths.

Common patterns include:

1. Use the base directory for runtime resources

string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "TestData", "input.xml");

This works well when files are copied to output during build.

2. Use typeof(SomeType).Assembly for clarity

string assemblyDir = Path.GetDirectoryName(typeof(DaoTests).Assembly.Location);

This is easier to understand than GetExecutingAssembly() when helper methods live in shared libraries.

3. Guard against nulls

string assemblyPath = typeof(DaoTests).Assembly.Location;
string assemblyDir = Path.GetDirectoryName(assemblyPath) ?? string.Empty;

4. Prefer deployment-friendly test assets

Instead of reading files from the original source tree, teams often:

• mark files as Content
• set Copy to Output Directory
• load them from the base directory

This makes tests more portable across IDEs, CI servers, and test runners.

5. Handle URIs correctly when using CodeBase

Uri uri = new Uri(typeof(DaoTests).Assembly.CodeBase);
string path = uri.LocalPath;

This pattern avoids mistakes like treating a file:/// URI as a normal Windows path.

6. Use helper methods to centralize file resolution

public static class Paths
{
    public static string TestData(string fileName) =>
        Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "TestData", fileName);
}

This keeps path logic in one place and makes tests easier to maintain.

Mistake 1: Using Environment.CurrentDirectory as if it were the assembly folder

string path = Environment.CurrentDirectory;

This returns the process working directory, which may belong to the test runner, not your DLL.

How to avoid it:

• Use AppDomain.CurrentDomain.BaseDirectory for runtime files.
• Use typeof(MyType).Assembly.Location if you truly need the loaded assembly path.

Mistake 2: Assuming Location always points to the original bin\Debug folder

string path = typeof(DaoTests).Assembly.Location;

Under shadow copying, this may point to a temp directory.

How to avoid it:

• Decide whether you need the loaded location or original source location.
• If you need the original source URI, inspect CodeBase and convert it.

Mistake 3: Using CodeBase like a normal file path

Broken example:

string path = typeof(DaoTests).Assembly.CodeBase;
string xmlPath = Path.Combine(path, "test.xml");

CodeBase is usually a URI such as file:///C:/..., so Path.Combine is not appropriate yet.

Correct approach:

Uri uri = new Uri(typeof(DaoTests).Assembly.CodeBase);
string path = uri.LocalPath;
string xmlPath = Path.Combine(Path.GetDirectoryName(path), "test.xml");

Mistake 4: Depending on source-tree-relative paths in tests

Broken example:

string xmlPath = @"..\..\..\TestData\sample.xml";

This may break on CI, different runners, or changed folder structures.

How to avoid it:

• Copy files into the output folder.
• Resolve them from BaseDirectory.

Mistake 5: Choosing the wrong assembly

If a helper method is in a shared library, GetExecutingAssembly() may return the helper library, not the test assembly you expected.

How to avoid it:

• Use typeof(DaoTests).Assembly when you mean a specific assembly.
• Be explicit about which assembly matters.

Which one should you choose?

• Want the runtime folder for reading files? Use AppDomain.CurrentDomain.BaseDirectory.
• Want the loaded DLL path? Use typeof(MyType).Assembly.Location.
• Want the original source path despite shadow copying? Try CodeBase and convert it from URI.
• Want the current process working folder? Use Environment.CurrentDirectory, but only if that is truly what you need.

// Loaded path of a specific assembly
string assemblyPath = typeof(MyType).Assembly.Location;

// Directory containing that assembly
string assemblyDir = Path.GetDirectoryName(assemblyPath);

// Runtime base directory
string baseDir = AppDomain.CurrentDomain.BaseDirectory;

// Original source path (URI -> local path)
string codeBase = typeof(MyType).Assembly.CodeBase;
string originalPath = new Uri(codeBase).LocalPath;
string originalDir = Path.GetDirectoryName(originalPath);

Rules of thumb

• Environment.CurrentDirectory is not the same as assembly directory.
• Location gives the path of the loaded assembly.
• CodeBase may preserve the original source location, but it is a URI.
• Test runners may shadow copy assemblies to temp folders.
• For test data, prefer:
  • copy files to output
  • load them from AppDomain.CurrentDomain.BaseDirectory

Best practical choice for tests

string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "TestData", "sample.xml");

If you specifically need the assembly folder

string folder = Path.GetDirectoryName(typeof(DaoTests).Assembly.Location);

How do I get the directory of the current assembly in C#?

Use:

string dir = Path.GetDirectoryName(typeof(MyType).Assembly.Location);

This gets the directory of the assembly containing MyType.

Why does Environment.CurrentDirectory return the wrong folder in tests?

Because it returns the process working directory, which may be the test runner's folder rather than your test DLL folder.

Why does Assembly.Location point to a temp folder?

Some test runners shadow copy assemblies before executing them. In that case, the loaded assembly really is in a temporary folder.

How can I get the original assembly path instead of the shadow-copy path?

Try Assembly.CodeBase and convert it from a URI to a local path:

string path = new Uri(typeof(MyType).Assembly.CodeBase).LocalPath;

What is the best way to load test files in unit tests?

Usually, copy the files to the output directory and load them with AppDomain.CurrentDomain.BaseDirectory.

Should I use GetExecutingAssembly() or typeof(MyType).Assembly?

typeof(MyType).Assembly is often clearer because it explicitly identifies which assembly you want.

Is CodeBase always the best choice?

No. It is useful when you need the original source location, but for normal runtime file loading, BaseDirectory is often simpler and more reliable.

• Reflection — assembly APIs such as Location and CodeBase are accessed through reflection.
• AppDomain — the base directory for an application or test run comes from the current app domain.
• File paths in C# — understanding Path.Combine, Path.GetDirectoryName, and path normalization is essential.
• Unit testing in .NET — test runners often affect working directories and assembly loading behavior.
• Shadow copying — explains why assemblies may run from temporary folders instead of their original build output.
• Embedded resources — an alternative to storing test files beside the DLL.
• Build output and content files — important when copying XML or JSON fixtures into the runtime folder.