IIS内のASP.NETコアアプリケーション内の仮想ディレクトリ

Question

ASP.NET Core 1.0 RC1を使用するアプリケーションがあり、IIS上でホストされています。それはうまく動作します。これで、ファイル共有で利用可能な静的コンテンツが作成され、アプリケーションからアクセスできるようになりました。

ASP.NET 5以前は、IISに仮想ディレクトリを追加して、共有コンテンツに簡単にアクセスできました。私たちのホスティングされたASP.NET 5アプリケーションでは、これは残念なことに動作していないようです。静的コンテンツにアクセスしようとすると、ちょうど404が返されます。

私たちのアプリケーションはapp.UseIISPlatformHandler()とapp.UseStaticFiles()を使用していますが、これは機能しません。私たちは、FileServerOptionsのカスタムでapp.UseFileServer()を使用して目的の動作を得ることができることを発見しましたが、IISで仮想ディレクトリを追加するのは通常の「古い」方法で可能であるかどうか不思議です。

Answer 1

直接ではありません。

.NET-Coreアプリケーションを使用している場合、アプリケーションはIISではなくKestrellで実行されることがわかります。

IISで.NETコアアプリケーションをホストするために、AspNetCoreModuleは、ポートXで127.0.0.1のKestrellで.NETコアアプリケーションを起動し、iis-domain + virtualからトラフィックを逆プロキシしますディレクトリを127.0.0.1のポートXにコピーします（TCP以外のものを使用する可能性があります）。

問題1は、Kestrellはかなり限定された機能しか持たないため、仮想ディレクトリはありません。
問題2は、IISは、nginxとは異なり、実際にリバースプロキシを適切に実行しないか、「完全に」と言うべきですか？

IISはdomainxy：80〜127.0.0.1:random okrightを転送できます。 しかし、正しく動作しないのは、domainxy：80/fooから127.0.0.1:random（画像、ヘッダー、json-ajax-results、urls、return-urls、cookiesなど）を書き換えることです。 代わりに、domain：80/fooを127.0.0.1:random/fooに書き換えます。これは、127.0.0.1:random（Kestrell）のサーバーが仮想ディレクトリをサポートしていない場合に問題になります。

アプリケーションを仮想ディレクトリで実行したい場合は、2つの方法があります（それを行うことができる場合は、両方のアプリケーションを変更する必要があります）：
1）すべてのものをディレクトリ "foo "（MVCコントローラのルートを含む）、あなたのアプリケーションが一度だけデプロイされる場合。 https://github.com/aspnet/Hosting/issues/416#issuecomment-149046552で示唆したように

2）あなたは、アプリケーション・フレームワークはkindofがRoRの中のように、あなたのためにそのフォルダをシミュレートすることができます：

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) 
{ 
    string virtual_directory = "/Virt_DIR"; 
    // virtual_directory = "/"; 

    if (virtual_directory.EndsWith("/")) 
     virtual_directory = virtual_directory.Substring(0, virtual_directory.Length - 1); 

    if (string.IsNullOrWhiteSpace(virtual_directory)) 
     Configure1(app, env, loggerFactory); // Don't map if you don't have to 
     // (wonder what the framework does or does not do for that case) 
    else 
     app.Map(virtual_directory, delegate(IApplicationBuilder mappedApp) 
      { 
       Configure1(mappedApp, env, loggerFactory); 
      } 
     ); 
} 

// Configure is called after ConfigureServices is called. 
public void Configure1(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) 
{ 
     [...] (here comes what used to be in your old Configure method) 

あなたはどこかの仮想ディレクトリの名前を設定する必要があります。 JavaScript/ajax-requestsでURLを取得/返しても、自動的にマッピングされることはありません。あなたはこれを自分で行う必要がありますが、それは以前のASP.NETでもこの方法でした。 RoRのような本当に

、：

マップRails.application.config。relative_url_root || "/" アプリケーション内の仮想ディレクトリについては
       実行RedmineApp ::アプリケーション
エンド

の操作を行います。 いいえ、これはそれほど単純ではありません。
IISは完全なWebサーバーであり、そこにあったように（コンテンツを読むことができる場合）そのマップされたディレクトリのコンテンツを提供します。

あなたはKestrellに全体の親ディレクトリを転送する場合は、IISはサブディレクトリを提供することはできません、あなたがしているアプリケーションは、それを行う必要があります。つまり、特定のディレクトリの静的ファイルサーバーをセットアップして、ファイルの場所を指定する必要があります。

あなたができることは、特定の仮想サブディレクトリをプロキシしないようにすることです（IISがおそらくその機能をサポートしていないことを除けば、nginxで静的ファイルの場所を定義できるのと同じです）。

しかし、Windowsがその（mklink）を使用できる場合は、ネットワークディレクトリに移動するアプリケーションディレクトリ内にシンボリックリンクを作成することができます。その後、.NET Coreは静的にサービスを提供できるはずです。しかし、実際には、それはハックのように聞こえる。

IISを設定できない場合は、実際にはapp.UseFileServer（）を使用して、データベース内のドキュメントの場所を定義する必要があります。あなたはちょうど&を削除して後でアプリケーションを再挿入することができます。

Answer 2

私のソリューションは、私は今日、この問題が発生したweb.configファイル

Answer 3

に代わりpath="*"のpath="/"を使用して、最終的にそれを修正するために管理されていました。このトリックは（私にとってはおそらく誰にとっても）サブアプリケーションでaspNetCoreハンドラが無効になっており、メイン（ASP.NET Core）アプリケーションで有効になっていることを確認しています。

私のASP.NETコアアプリは、基本的なWeb.configファイル

<configuration> 
    <system.webServer> 
    <handlers> 
     <add name="aspNetCore" path="*" verb="*" type="" modules="AspNetCoreModule" scriptProcessor="" resourceType="Unspecified" requireAccess="Script" allowPathInfo="false" preCondition="" responseBufferLimit="4194304" /> 
    </handlers> 
    <aspNetCore processPath="dotnet" arguments=".\bin\Debug\netcoreapp2.0\myapp.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" /> 
    </system.webServer> 
</configuration> 

を持っており、IISでのサブアプリケーションが

<configuration> 
    <!-- removed --> 
    <system.webServer> 
     <handlers> 
      <remove name="aspNetCore" /> 
     </handlers> 
    </system.webServer> 
</configuration> 

Answer 4

を持っているように、アプリケーションは、私が1でその質問を知っ追加しました8年ですが、誰かが同じ問題を解決する必要がある場合は、次のようにしてください：

public void Configure(IApplicationBuilder app) 
{ 
    app.UseStaticFiles(); // For the wwwroot folder 

    app.UseStaticFiles(new StaticFileOptions() 
    { 
     FileProvider = new PhysicalFileProvider(
      Path.Combine(Directory.GetCurrentDirectory(), @"wwwroot", "images")), 
     RequestPath = new PathString("/MyImages") 
    }); 
} 

完全に可能ですo PhysicalFileProviderのパラメータを任意のローカルまたは共有フォルダに変更し、ファイルを提供します。

このようにすることは、セキュリティが推奨されていません。しかし、研究のために、その許容可能な提案します。

静的ファイルモジュールには、 認可チェックはありません。 wwwrootの下にあるファイルを含む、それによって配信されるファイルはすべて公開されています。 承認に基づいてファイルを提供するには：wwwrootおよび静的ファイルミドルウェアにアクセスできる任意のディレクトリ の外部に格納し、 コントローラーアクションを実行して、承認が の場合はFileResultを返します。

MicrosoftのAsp.Netドキュメントでは、この問題の解決に役立つより詳しい情報があります。

このリンクをチェックしてください：https://docs.microsoft.com/en-us/aspnet/core/fundamentals/static-files

Answer 5

私はOPで書かれていなければならないと思うのブログを発見しました。

upshotは、IISで仮想ディレクトリを使用するのではなく、Startup.csのパスを物理サーバーディレクトリにマップします。私はOPが以下のブログを貼り付けたことに気にしないことを願っていますが、今日この問題に最初に遭遇したときに助けになりました。

出典：あなたはあなたのアプリケーションで静的なコンテンツを提供したいときhttps://www.jauernig-it.de/asp-net-coreiis-serving-content-from-a-file-share/

状況がありますが、それは例えば、それの一部ではありません共通のファイル共有上に存在するためです。ビジネス部門によって管理されるウェブサイトのコンテンツは、そのようなユースケースになる可能性があります。 ASP.NET before Coreでは、これはIISでは問題ありませんでした。IIS Webサイト内に仮想ディレクトリを作成し、ファイル共有を指すようにしてください。

残念ながら、ASP.NETコアでは、この方法はもう機能しません。 IISでASP.NETコアアプリケーションに仮想ディレクトリを追加すると、仮想ディレクトリが認識されず、404が返されます。これは、HttpPlatformHandlerモジュールを使用してIISの下で実行され、IISが要求を仲介するだけのDNX/Kestrelが原因です。 KestrelはIISの仮想ディレクトリについて何も知らない。また、ASP.NETコアアプリケーションはIISとは独立しており、実行しなくても実行できます（たとえば、Kestrelスタンドアロンを実行するなど）。これは良いことと考えられます。

しかし、今私たちの問題のための別の解決策が必要です...幸いにも、ASP.NETコアはどこからでもファイルを提供するプログラマティックなインターフェイスを提供します。ちょうどあなたのStartup.cs設定するには、次のコードを追加します（）メソッド：この本質的何

app.UseFileServer(new FileServerOptions 
{ 
    FileProvider = new PhysicalFileProvider(@"\\server\path"), 
    RequestPath = new PathString("/MyPath"), 
    EnableDirectoryBrowsing = false 
}); 

は、物理サーバのパスにファイルサーバーを追加して、それが特定のリクエストに応じて利用可能ですこの場合、ディレクトリブラウジングが無効になっています。新しいPhysicalFileProvider（env.WebRootPath + "\ path"）（EnvはIHostingEnvironmentタイプがConfigure（）のパラメータとして指定されている）を使用して、アプリケーションに関連するパスからサービスを提供することもできます。 Voila、それだけです。 IISに「仮想ディレクトリ」を追加する必要はありません。これは廃止され、過去のものです。私たちにとって、これは良いことです。なぜなら、私たちはIIS全体からより独立しているからです。