Why Appdomain.Currentdomain.Basedirectory Not Contains "Bin" in ASP.NET App

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

Why is AppDomain.CurrentDomain.BaseDirectory targeting bin catelog in console application?

The AppDomain.CurrentDomain.BaseDirectory isn't defined by the assembly but the hosting environment (i.e. the application or service).

Once you build a console application your executable and satellite assemblies go to the output path defined in your *.csproj file. Default is bin\$(Configuration) (for example: bin\Debug).

Since the whole executable is being executed in the output path, this is the base directory.

Why in ASP.NET WebAPI projects worked fine in your case? Probably because you're hosting ASP.NET WebAPI in IIS. If you would do it using OWIN/Katana hosted in a Windows service, you would end up with the same issue.

AppDomain.CurrentDomain.BaseDirectory returns unit test project root location instead of source project

That's the expected behaviour.

You could consider copying the required files to the unit test directory.

In Visual Studio 2010, look at "Deployment" under "Test Settings".



Related Topics



Leave a reply



Submit