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?

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. — Tejs, Dec 29 '11 at 15:39

Peter · Accepted Answer · 2011-12-29T16:16:40.303

38

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

edited Dec 29 '11 at 16:16

answered Dec 29 '11 at 15:53

Peter

9,643
6
61
108

@kenny - Updated with a little bit of info – Peter Dec 29 '11 at 16:20
5

`System.Reflection.Assembly.GetExecutingAssembly().Location` points in my Web Application to: _C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files..._ – ms007 Apr 10 '13 at 10:24
@ms007 - 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. – Peter Apr 10 '13 at 13:09
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. – vlad2135 Aug 02 '13 at 13:03
10

I believe it would be more correct to use `AppDomain.RelativeSearchPath` instead of hardcoding "bin". – Oskar Berggren Oct 02 '13 at 18:51
AppDomain.CurrentDomain.RelativeSearchPath returns null in the windows desktop apps – hB0 Aug 13 '14 at 15:28
6

string basePath = AppDomain.CurrentDomain.RelativeSearchPath ?? AppDomain.CurrentDomain.BaseDirectory; – Jesper Mygind Jun 07 '16 at 11:21
3

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. – Rudey Dec 22 '17 at 09:39
This approach fails when executing code on some background thread where there is no HttpContext – Cesar Jan 11 '21 at 16:58
@Cesar When there is no HttpContext, does the `null` check in the first line not catch that? – Peter Jan 24 '21 at 03:37
@Peter 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. – Cesar Jan 25 '21 at 07:08

score 25 · Answer 2 · edited Apr 01 '22 at 03:31

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(@"~\");

score 15 · Answer 3 · answered Dec 29 '11 at 15:40

15

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

answered Dec 29 '11 at 15:40

M4N

94,805
45
217
260

1

Note, according to MSDN PrivatBinPath may be a comman delimited string of folders. http://msdn.microsoft.com/en-us/library/system.appdomainsetup.privatebinpath.aspx – Peter Dec 29 '11 at 15:50
+1 This is by far the best answer @Peter FWIW in practice it doesn't seem to from my observations. Not ready to call it a full doc bug yet though – Ruben Bartelink Jul 02 '13 at 10:41
This will return null in a console application. – Robb Vandaveer Sep 29 '15 at 14:06
that wont give real exe location – M at Jul 27 '16 at 07:46
@RobbVandaveer yes it can return null so you should use `PrivateBinPath ?? BaseDirectory`. – Rudey Dec 22 '17 at 09:50
@M4N @Peter `PrivateBinPath` can be a list of paths. Use `AppDomain.CurrentDomain.RelativeSearchPath` instead to ensure you always get a single path. – Rudey Dec 22 '17 at 09:54

score 2 · Answer 4 · edited Oct 31 '12 at 15:32

2

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");

edited Oct 31 '12 at 15:32

friism

19,068
5
80
116

answered Dec 29 '11 at 20:51

Siarhei Kuchuk

5,296
1
28
31

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

4 Answers4

Linked

Related