IIS 10.で実行されているASP.NET Core Webアプリケーションに問題があります。AngularJSで単一ページアプリケーションを開発しています。
Index.htmlは完全にロードされますが、バックエンドリクエストはIIS 10の404エラーコードで失敗します。VisualStudioからIIS Expressで完全に動作します。
誰でもバックエンドのリクエストを修正する方法を見つけることができますか?
これが私のProgram.csです
public static void Main(string[] args)
{
var Host = new WebHostBuilder()
.UseKestrel()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseIISIntegration()
.UseStartup<Startup>()
.Build();
Host.Run();
}
そして、Startup.csのConfigureメソッドです。
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
app.UseDefaultFiles();
app.UseStaticFiles();
app.UseIdentity();
// Custom middleware for Angular UI-Router
app.Use(async (context, next) =>
{
if (!Path.HasExtension(context.Request.Path.Value)
&& context.Request.HttpContext.Request.Headers["X-Requested-With"] != "XMLHttpRequest"
&& context.Request.Method.ToUpper() != "POST"
&& context.Request.Method.ToUpper() != "PUT"
&& context.Request.Method.ToUpper() != "DELETE")
{
await context.Response.WriteAsync(File.ReadAllText(env.WebRootPath + "/index.html"));
}
await next();
});
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "api/{controller=Home}/{action=Index}/{id?}");
});
}
あなたのコードはKestrelを使って私のマシンで動作しています。適切なトラブルシューティング手順は、問題がASP.NET Coreアプリケーションにあるのか、IIS Hosting構成にあるのかを調べることです。
プロジェクトのルートからこれを試してください。
dotnet restore
dotnet run
次のようなものが表示されます。
Hosting environment: Production
Content root path: C:\MyApplicationPath
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
ブラウザで、次の2つのURLにアクセスします。動作しない場合は、アプリケーションに何か問題があります。動作する場合は、IISホスティングに問題があります。
localhost:5000 // you will see your index.html page
localhost:5000/api // you will see your default routes output
私の場合、問題はコントローラーが例外をスローしたため、フレームワークが使用できない例外ハンドラーページを使用しようとしたため、404エラー、コントローラー自体が500エラーをスローしたことでした
検索者の利益のために。
IISを使用すると404が表示されました。パブリッシュ( here )と詳細な展開 here の正しい手順に従いました。
理解するのに時間がかかりましたが、最終的に Rick Strahlのブログ投稿 に答えが隠されていることに気付きました。
基本的に、アプリケーションプールを作成するとき、および「マネージコードなし」に設定するとき、高度な設定に入り、アプリケーションプールIDを「ネットワークサービス」に設定する必要もありました。私のマシンのApplicationPoolIdentityでは問題ありませんでしたが、デプロイ先のマシンではそうではありませんでした。
したがって、明確にするために、私の完全な手順は次のとおりでした。
パッケージを作成するには:
パブリッシュ。 VSの発行機能を使用することもできましたが、パッケージマネージャー経由でCLRを使用しました。コマンドは:
dotnet publish -c Release -r win-x64 --self-contained
64ビットWindows Server 2008との互換性が必要なため、 win-x64 identifier を使用する必要がありました。
デプロイするには:
iisreset
としてコマンドプロンプトを開きます。これは、dotnetコアランタイムをインストールした後に初めて必要になります。別の非常に愚かな可能性の高い亜種は、誤った展開設定のために、アプリが予期したものとは異なるフォルダー(例:サブフォルダーではなくサーバールート)に展開されたことです。