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

Question

I have a web project like:

namespace Web
{
    public partial class _Default : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            lbResult.Text = PathTest.GetBasePath();
        }
    }
}

The method PathTest.GetBasePath() is defined in another Project like:

namespace TestProject
{
    public class PathTest
    {
        public static string GetBasePath() 
        {
            return AppDomain.CurrentDomain.BaseDirectory;
        }
    }
}

Why it's display ...\Web\ while the TestProject assembly is compiled into bin folder(in other words it should display ...\Web\bin in my thought).

Now I got a troublesome if I modified method into:

namespace TestProject
{
    public class FileReader
    {
        private const string m_filePath = @"\File.config";
        public static string Read() 
        {
            FileStream fs = null;
            fs = new FileStream(AppDomain.CurrentDomain.BaseDirectory + m_filePath,FileMode.Open, FileAccess.Read);
            StreamReader reader = new StreamReader(fs);
            return reader.ReadToEnd();
        }
    }
}

The File.config is created in TestProject. Now AppDomain.CurrentDomain.BaseDirectory + m_filePath will returen ..\Web\File.config (actually the file was be copied into ..\Web\bin\File.config), an exception will be thrown.

You could say that I should modified m_filePath to @"\bin\File.config". However If I use this method in a Console app in your suggest, AppDomain.CurrentDomain.BaseDirectory + m_filePath will return ..\Console\bin\Debug\bin\File.config (actually the file was copyed into .\Console\bin\Debug\File.config), an exception will be thrown due to surplus bin.

In other words, in web app, AppDomain.CurrentDomain.BaseDirectory is a different path where file be copyed into (lack of /bin), but in console app it's the same one path.
Any one can help me?

Onus

The base of a web application is the web root where the ASPX pages are contained. The bin folder is just a subfolder of the root. – Finalize

Phew! I thought I had gone mad! I had the same problem ... – Maledict

Answer 1

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;
} 

Pro

@kenny - Updated with a little bit of info – Pro

System.Reflection.Assembly.GetExecutingAssembly().Location points in my Web Application to: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files... – Uxorious

@Uxorious - This path will probably dependon whether you are working with an ASP.Net Web Site vs Web Application. Since with a web site the code is compiled on the fly Temporary ASP.NET Files makes sense; and probably not a good choice for what you are doing. – Pro

GetExecutingAssembly().Location points to temporary folder because assembly was shadow-copied to that folder by IIS to allow hot-update. Use GetExecutingAssembly().Codebase (CodeBase?) property to get original location of the assembly. – Echikson

I believe it would be more correct to use AppDomain.RelativeSearchPath instead of hardcoding "bin". – Starry

AppDomain.CurrentDomain.RelativeSearchPath returns null in the windows desktop apps – Groundwork

string basePath = AppDomain.CurrentDomain.RelativeSearchPath ?? AppDomain.CurrentDomain.BaseDirectory; – Marshland

Checking HttpContext.Current for null to determine if you're running a web app is a bad idea. For example, this doesn't work in async contexts. Use RelativeSearchPath ?? BaseDirectory instead. – Miserere

This approach fails when executing code on some background thread where there is no HttpContext – Panga

@Panga When there is no HttpContext, does the null check in the first line not catch that? – Pro

@Pro no it does not. If you create a background thread (in some scenario), then there is no HttpContext, but the path is still \bin. RelativeSearchPath solves that. – Panga

Answer 2

In case you want a solution that works for WinForms and Web Apps:

public string ApplicationPath
{
    get
    {
        if (String.IsNullOrEmpty(AppDomain.CurrentDomain.RelativeSearchPath))
        {
            //exe folder for WinForms, Consoles, Windows Services
            return AppDomain.CurrentDomain.BaseDirectory;
        }
        else
        {
            //bin folder for Web Apps 
            return AppDomain.CurrentDomain.RelativeSearchPath;
        }
    }
}

The above code snippet is for binaries locations.

The AppDomain.CurrentDomain.BaseDirectory is still a valid path for Web Apps, it's just the root folder where the web.config and Global.asax are, and is same as Server.MapPath(@"~\");

Charr

Answer 3

If you use AppDomain.CurrentDomain.SetupInformation.PrivateBinPath instead of BaseDirectory, then you should get the correct path.

Sherrard

Note, according to MSDN PrivatBinPath may be a comman delimited string of folders. msdn.microsoft.com/en-us/library/… – Pro

+1 This is by far the best answer @Pro FWIW in practice it doesn't seem to from my observations. Not ready to call it a full doc bug yet though – Unamuno

This will return null in a console application. – Camm

that wont give real exe location – Indiscernible

@RobbVandaveer yes it can return null so you should use PrivateBinPath ?? BaseDirectory. – Miserere

@Sherrard @Pro PrivateBinPath can be a list of paths. Use AppDomain.CurrentDomain.RelativeSearchPath instead to ensure you always get a single path. – Miserere

Answer 4

When ASP.net builds your site it outputs build assemblies in its special place for them. So getting path in that way is strange.

For asp.net hosted applications you can use:

string path = HttpContext.Current.Server.MapPath("~/App_Data/somedata.xml");

Competition