What is the difference between these ways of getting current directory?

Question

They all give the same result, the location of folder that contains the exe that is being executed. I am sure there are no good or bad methods in the .net BCL. They are all appropriate in particular circumstances. Which one is appropriate for which scenario?

var appBaseDir = AppDomain.CurrentDomain.BaseDirectory; 
var currentDir = Environment.CurrentDirectory; 
var dir = Directory.GetCurrentDirectory(); 
var path = Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);

Answer 1

They all give the same result

They certainly don't. currentDir and dir both give you the current working directory – ie by default the directory your executable was run from (but it can be changed during the execution).

By contrast, appBaseDir and path get the directory which contains the executing assembly's file.

To illustrate how they differ, consider that you have an executable which sits in C:\bar\baz.exe . Now I can execute the application by entering the following chain of commands in a terminal:

$ md C:\foo
$ cd C:\foo
$ ..\bar\baz.exe

Now the current working directory is C:\foo but the application's base directory is C:\bar . There exist analogous means of setting the working directory for other methods of launching an application (eg via a shortcut icon or programmatically, such as via Process.Start ).

Still, the framework provides different ways of accessing this information:

Environment.CurrentDirectory quite directly conveys the meaning that the execution environment (an environment variable) is queried. Directory.GetCurrentDirectory() may actually do the same internally (I have no idea) but it encapsulates this, and rather focuses on providing the user with a logical API for querying information about directories.

AppDomain.CurrentDomain has information about the current AppDomain (roughly, the executable). Part of that information is, logically, the AppDomain 's path. By contrast, System.Reflection.Assembly gives you general information about assembles – these represent any kind of binary objects in .NET, including DLLs and EXEs. GetExecutingAssembly in particular returns the currently executed assembly. And you can get its path again by querying its Location property, which gives the physical path of an assembly file.

Answer 2

Consider the example above The myTest.exe file contains the entry point and is at located at D:\myTest.exe . This exe calls via reflection a method in an assembly in F:\ . This assembly contains all the find directory code.

In the command prompt I have my current directory set to C:\

Here are the results

AppDomain.CurrentDomain.BaseDirectory

D:\

Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location)

F:\

Environment.CurrentDirectory and Directory.GetCurrentDirectory()

C:\

Answer 3

AppDomain.CurrentDomain.BaseDirectory will give you the directory the application is running in.

Environment.CurrentDirectory & Directory.GetCurrentDirectory can change during the execution of an application. You can see the behavior if you get the value at the start of execution, then use something like OpenFileDialog , then then get the value again. You will notice that the value will have changed to where the OpenFileDialog was pointing.

Answer 4

I found with .net 5 that if the application is published as a self-contained single-file EXE, all of these well-known methods to get the EXE location return an empty string:

System.Reflection.Assembly.GetExecutingAssembly().Location System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase typeof(Program).Assembly.ManifestModule.FullyQualifiedName

However this does work to get the containing folder path:

AppDomain.CurrentDomain.BaseDirectory