Pourquoi AppDomain.CurrentDomain.BaseDirectory ne contient pas de" bin " dans asp.net app?
j'ai un projet web comme:
namespace Web
{
public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
lbResult.Text = PathTest.GetBasePath();
}
}
}
la méthode PathTest.GetBasePath() est définie dans un autre projet comme:
namespace TestProject
{
public class PathTest
{
public static string GetBasePath()
{
return AppDomain.CurrentDomain.BaseDirectory;
}
}
}
pourquoi afficher ...Web alors que L'ensemble de TestProject est compilé dans le dossier bin (en d'autres termes, il devrait afficher ...Webbin dans ma pensée).
maintenant j'ai un problème si je modifie la méthode dans:
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();
}
}
}
le File.config est créé dans le projet d'essai. Maintenant AppDomain.CurrentDomain.BaseDirectory + m_filePath reviendra ..WebFile.config (en fait le fichier a été copié dans ..WebbinFile.config ), une exception sera jetée.
vous pourriez dire que je devrais modifier m_filePath en @"binFile.config" . Cependant si j'utilise cette méthode dans une application de Console dans votre suggestion, AppDomain.CurrentDomain.BaseDirectory + m_filePath retournera ..ConsolebinDebugbinFile.config (en fait le fichier a été copié dans .ConsolebinDebugFile.config ), une exception sera lancée en raison de l'excédent bin .
En d'autres termes, web app, AppDomain.CurrentDomain.BaseDirectory est un autre chemin où le fichier sera copyed (manque de /bin ), mais dans l'application console c'est le même chemin.
Quelqu'un peut-il m'aider?
4 réponses
Par MSDN, un Domaine d'Application "Représente un domaine d'application, qui est un environnement isolé où les applications s'exécutent."Quand on pense à un ASP.Net application la racine où réside l'application n'est pas le dossier bin. Il est tout à fait possible, et dans certains cas raisonnable, de n'avoir aucun fichier dans votre dossier bin, et éventuellement aucun dossier bin. Depuis AppDomain.CurrentDomain se réfère au même objet, que vous appelez la code de code derrière ou à partir d'une dll dans le bin folder vous finirez avec le chemin racine vers le site web.
quand j'ai écrit un code conçu pour fonctionner sous les deux asp.net et Windows apps habituellement je crée une propriété qui ressemble à quelque chose comme ceci:
public static string GetBasePath()
{
if(System.Web.HttpContext.Current == null) return AppDomain.CurrentDomain.BaseDirectory;
else return Path.Combine(AppDomain.CurrentDomain.BaseDirectory,"bin");
}
une autre option (non testée) serait d'utiliser:
public static string GetBasePath()
{
return System.Reflection.Assembly.GetExecutingAssembly().Location;
}
si vous utilisez AppDomain.CurrentDomain.SetupInformation.PrivateBinPath au lieu de BaseDirectory , alors vous devez obtenir le chemin correct.
dans le cas où vous voulez une solution qui fonctionne pour WinForms et applications Web
public string ApplicationPath
{
get
{
if (String.IsNullOrEmpty(AppDomain.CurrentDomain.RelativeSearchPath))
{
return AppDomain.CurrentDomain.BaseDirectory; //exe folder for WinForms, Consoles, Windows Services
}
else
{
return AppDomain.CurrentDomain.RelativeSearchPath; //bin folder for Web Apps
}
}
}
code de la solution ci-dessus snippet is for binaires emplacements
le AppDomain.CurrentDomain.BaseDirectory est toujours valide pour les applications Web, c'est juste un dossier racine où le web.config et Global.asax et est identique à Server.MapPath(@"~\");
quand ASP.net construit votre site il produit construire des assemblages dans sa place spéciale pour eux. Il est donc étrange que le chemin soit ainsi tracé.
pour asp.net applications hébergées que vous pouvez utiliser:
string path = HttpContext.Current.Server.MapPath("~/App_Data/somedata.xml");