-
Notifications
You must be signed in to change notification settings - Fork 0
MS_GettingWebSitePaths
- 戻る(各種パスを取得する方法)
Web サイトの様々なパスを取得する方法。
補足(「物理パス」と「仮想パス」の区別): Web では
2 種類のパスが常に併存するため、まずこの区別を押さえる。ブラウザから見える URL → 仮想パス https://example.com/app/Order/List ~~~~~~~~~~~~~~~ /app/Order/List サーバ上の実際の場所 → 物理パス C:\inetpub\wwwroot\app\Order\List.aspx
仮想パス 物理パス 例 /app/Order/ListC:\inetpub\...\List.aspx用途 リンク・リダイレクトの生成 ファイルの読み書き 変換 Server.MapPath()(仮想 → 物理)- 仮想ディレクトリ配下に配置されるか(
/app/)どうかで
仮想パスが変わるため、URL をハード コーディングしないことが
本ページの実務上の主旨である。
仮想パスに対応する物理ファイル パス
Server 組み込みオブジェクトから HttpServerUtility インスタンスを取得。
string path = Server.MapPath("./");HttpContext.Current.Server プロパティから HttpServerUtility インスタンスを取得。
string path = HttpContext.Current.Server.MapPath("./");補足(
HttpContext.Currentは避ける): 「Page 外」から
HttpContext.Currentを使う方法は動作するが、
設計としては望ましくない。・静的プロパティに依存するため、単体テストできない ・[async/await](MS_AsyncAwait) の後で null になることがある (ASP.NET の同期コンテキストに依存するため) ・バッチや別スレッドから呼ぶと null業務ロジックの層にパスの解決を持ち込まない
(必要なパスは引数で渡す)のが定石である。ASP.NET Core では
HttpContext.Current自体が存在しない。
必要ならIHttpContextAccessorを注入する
(ASP.NET Core における DI)が、
パスの取得には後述のIWebHostEnvironmentを使うのが正しい。
https://learn.microsoft.com/en-us/dotnet/api/system.web.httprequest.physicalapplicationpath
サーバー アプリケーションのルート ディレクトリの物理ファイル システム パス
https://learn.microsoft.com/en-us/dotnet/api/system.web.httprequest.physicalpath
要求された URL に一致する物理ファイル システム パス
https://learn.microsoft.com/en-us/dotnet/api/system.web.httprequest.applicationpath
現在のアプリケーションのルート仮想パス(「/」や「/アプリ名」のような)。
https://learn.microsoft.com/en-us/dotnet/api/system.web.httprequest.currentexecutionfilepath
現在の要求の仮想パス(Transfer または Execute を反映)
https://learn.microsoft.com/en-us/dotnet/api/system.web.httprequest.filepath
現在の要求の仮想パス(Transfer または Execute を反映しない)
https://learn.microsoft.com/en-us/dotnet/api/system.web.httprequest.path
現在の要求の仮想パス(URL 拡張子付きリソースに追加パス情報を反映)
補足(具体例で見る違い): 4 つの違いは文章だと分かりにくいので、
実際の値を並べておく。前提: アプリを仮想ディレクトリ /app に配置し、 /app/Default.aspx で Server.Transfer("Other.aspx") した後、 URL は /app/Default.aspx/extra ApplicationPath → /app FilePath → /app/Default.aspx (Transfer 前) CurrentExecutionFilePath → /app/Other.aspx (Transfer 後) Path → /app/Default.aspx/extra (PathInfo 付き) PathInfo → /extra
ApplicationPathが最も使用頻度が高い。
「アプリがルートに置かれるか、仮想ディレクトリ配下に置かれるか」を
吸収するために使う。// ✗ ルート配置を前提にしている Response.Redirect("/Order/List"); // ○ アプリのルートからの相対("~/" が ApplicationPath に解決される) Response.Redirect("~/Order/List"); string url = VirtualPathUtility.ToAbsolute("~/Order/List");
~/記法を使えば、ApplicationPathを意識せずに済む。
ASP.NET MVC ではUrl.Content("~/...")/
Url.Action(...)を使う(ASP.NET MVCの用語)。
補足(ASP.NET Core での対応物/最新化):
System.Webが無いため、
API がすべて置き換わっている。
ASP.NET (System.Web) ASP.NET Core Server.MapPath("~/x")Path.Combine(env.ContentRootPath, "x")Server.MapPath("~/wwwroot/x")Path.Combine(env.WebRootPath, "x")Request.PhysicalApplicationPathenv.ContentRootPathRequest.ApplicationPathRequest.PathBaseRequest.FilePath/PathRequest.PathRequest.UrlRequest.GetDisplayUrl()(拡張メソッド)public class MyService(IWebHostEnvironment env) { public string GetTemplatePath() => Path.Combine(env.ContentRootPath, "Templates", "invoice.html"); public string GetImagePath() => Path.Combine(env.WebRootPath, "images", "logo.png"); }
ContentRootPathとWebRootPathの区別が重要である。ContentRootPath … アプリのルート(appsettings.json などがある場所) WebRootPath … wwwroot(静的ファイルとして公開される場所) ← ここに置いたものは URL で直接取得できる機密ファイルを
wwwrootに置かないこと。
ASP.NET では「公開したくないものを塞ぐ」設計だったのに対し、
ASP.NET Core は**「公開するものだけをwwwrootに置く」**という
逆の設計になっている(ASP.NET MVCの用語 のフォルダ構成も参照)。
PathBaseは、リバース プロキシ配下で
サブパスに配置する場合(/appの下に置く)に効いてくる
(ASP.NET CoreのWebサーバ の
UseForwardedHeadersと併せて設定する)。app.UsePathBase("/app");
-
ASP.NET Web サイトのパス
https://learn.microsoft.com/ja-jp/previous-versions/aspnet/ms178116(v=vs.100) -
[ASP.NET]Webサイトのルートの物理パスを取得するには?[C#、VB]:.NET TIPS - @IT
http://www.atmarkit.co.jp/ait/articles/0811/06/news150.html
- ASP.NET Core の基礎(IWebHostEnvironment)
https://learn.microsoft.com/ja-jp/aspnet/core/fundamentals/environments - ASP.NET Core の静的ファイル
https://learn.microsoft.com/ja-jp/aspnet/core/fundamentals/static-files
Tags: 移行, .NET開発, ASP.NET
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。