Why does ASP.NET 5 not start in IIS 7.5?

Question

I am running ASP.NET 5 (Core) with IIS 7.5. I already installed httpPlatformHandler and set the physical path of the site (in IIS) to the wwwroot folder that I published from visual studio 2015. All I get is a blank page with continuous loading. I am sure that everything is connected correctly. In addition, it loads normally if I uncomment the app.Run expression from the Configure method and comment out app.UseIISPlatformHandler, app.UseDefaultFiles, app.UseStaticFiles and app.UseMVC.

My code is below. I do not know what else to do at this moment. Any suggestions? If you need other snippets of code, let me know.

Startup.cs (setup method)

public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory) { app.UseIISPlatformHandler(); app.UseDefaultFiles(); app.UseStaticFiles(); app.UseMvc(); //app.Run(async (context) => //{ // var greeting = greeter.GetGreeting(); // await context.Response.WriteAsync(greeting); //}); } 

web.config

 <system.webServer> <handlers> <add name="httpPlatformHandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified" /> </handlers> <httpPlatform processPath="%DNX_PATH%" arguments="%DNX_ARGS%" stdoutLogEnabled="false" startupTimeLimit="3600" forwardWindowsAuthToken="true" /> 

New editing. I updated the folder structure to MVC (using controllers, views, etc.), and I changed the Configure method a bit. Now it loads a blank screen, and the console logs 404 not found. Additional suggestions?

Adding my full Startup.cs:

  public IConfiguration Configuration { get; set; } public static string ConnectionString { get; set; } public Startup() { var builder = new ConfigurationBuilder() .AddJsonFile("appsetting.json") .AddEnvironmentVariables(); Configuration = builder.Build(); ConnectionString = Configuration.GetSection("connString").Value; } // This method gets called by the runtime. Use this method to add services to the container. // For more information on how to configure your application, visit http://go.microsoft.com/fwlink/?LinkID=398940 public void ConfigureServices(IServiceCollection services) { services.AddMvc(); } // This method gets called by the runtime. Use this method to configure the HTTP request pipeline. public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory) { app.UseIISPlatformHandler(); //app.UseDefaultFiles(); app.UseFileServer(true); app.UseMvc(routes => { routes.MapRoute( name: "default", template: "{controller=Home}/{action=Index}"); }); } // Entry point for the application. public static void Main(string[] args) => WebApplication.Run<Startup>(args); 

Answer 1

Have you looked at IIS logs to see if even IIS makes a request?

You can also try placing a simple middleware module between each middleware module defined in the Configure () method of the Startup class. Your middleware can write a message to the Windows event log, which indicates where it is in the Http pipeline and the contents of the response body. It's like inserting warnings for debugging Javascript. This, at least, will let you know where it hangs or clears the body of the response.

I posted a very easy-to-understand demo on github that demonstrates how to create middleware in three easy steps. Click here to go to this demo.

UPDATE: Try changing your Configure () method to the code below (put your route if mine is not suitable for your installation).

 app.UseIISPlatformHandler(options => options.AuthenticationDescriptions.Clear()); app.UseStaticFiles(); app.UseMvc(routes => { routes.MapRoute( name: "default", template: "{controller=Home}/{action=Index}/{id?}"); }); 

Answer 2

Sorry for the delay, I did not have email notifications. Here is my web.config

 <configuration> <system.webServer> <handlers> <add name="httpplatformhandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified" /> </handlers> <httpPlatform processPath="..\approot\web.cmd" arguments="" stdoutLogEnabled="true" stdoutLogFile="..\logs\stdout.log" startupTimeLimit="3600"></httpPlatform> </system.webServer> </configuration> 

This may be the identity in which your application pool is running. The authentication user must have several dnx paths in its PATH environment variable. Therefore, it is easiest to specify your username as the application pool identifier, since you must have these paths in your PATH environment variable.

EDIT: When we set up our QA machine, we needed to create three system environment variables and specify them in the user profile that RC1 installed. It:

 DNX_HOME - C:\Users\<username>\.dnx DNX_PACKAGES - C:\Users\<username>\.dnx\packages DNX_PATH - C:\Users\<username>\.dnx\bin\dnvm.cmd 

And the application pool identification user must obviously have access to these paths.