Should I Use Appdomain.Currentdomain.Basedirectory or System.Environment.Currentdirectory

C#-Difference between System.CurrentDomain.AppDomain.BaseDirectory and Directory.GetCurrentDirectory()

According to this question the difference is that

System.AppDomain.CurrentDomain.BaseDirectory returns current
directory, not executable location, i.e. when run from outlook (sent
as a link to \server\folder\file.exe it will set BaseDirectory to
user documents instead executable location
from Jakub Pawlinski whereas Directory.GetParent(Assembly.GetExecutingAssembly().Location)
gets the parent folder of the current execting assembly.

So the code I'm using now is:

string location = Assembly.GetExecutingAssembly().Location;
if (location != null)
{
    string config = Path.Combine(Directory.GetParent(location).FullName, "Config.xml"));
}

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

They all give the same result

They certainly don’t. currentDir and dir both give you the current working directory – i.e. 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 (e.g. 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.

Why AppDomain.CurrentDomain.BaseDirectory not contains bin in asp.net app?

Per MSDN, an App Domain "Represents an application domain, which is an isolated environment where applications execute." When you think about an ASP.Net application the root where the app resides is not the bin folder. It is totally possible, and in some cases reasonable, to have no files in your bin folder, and possibly no bin folder at all. Since AppDomain.CurrentDomain refers to the same object regardless of whether you call the code from code behind or from a dll in the bin folder you will end up with the root path to the web site.

When I've written code designed to run under both asp.net and windows apps usually I create a property that looks something like this:

public static string GetBasePath()          
{       
    if(System.Web.HttpContext.Current == null) return AppDomain.CurrentDomain.BaseDirectory; 
    else return Path.Combine(AppDomain.CurrentDomain.BaseDirectory,"bin");
} 

Another (untested) option would be to use:

public static string GetBasePath()          
{       
    return System.Reflection.Assembly.GetExecutingAssembly().Location;
} 

System.Environment.CurrentDirectory returns wrong Directory

From the documentation:

Environment.CurrentDirectory Property

Gets or sets the fully qualified path of the current working
directory.

It looks like you are using ReSharper to launch your tests, which is probably setting the working directory to that location.

Program launching incorrectly when using a shortcut

Do not use Environment.CurrentDirectory for dealing with DLLs. That's a horrible security flaw. Your application is searching for DLLs in the current directory, rather than the application directory. Hopefully, it's not loading them from the current directory, but this is something to be very careful about.

To get the application directory, you can use AppDomain.CurrentDomain.BaseDirectory instead. This will not change depending on the (user configurable!) current directory.

---

Related Topics