[Announcement] Change to IIS hosting model

DamianEdwards commented 9 years ago

Discussions for aspnet/Announcements#69

guardrex commented 8 years ago

@jruckert

x86 version: http://go.microsoft.com/fwlink/?LinkId=690722 x64 version: http://go.microsoft.com/fwlink/?LinkId=690721

jruckert commented 8 years ago

@GuardRex Thanks!

jruckert commented 8 years ago

IIS + IIS Express + Windows Auth + Kestrel is looking really good with the IISPlatformHandler.

@davidfowl Can someone please give us some guidance for the following scenario (to run under our dev machines).

Kestrel (command line) + Windows Auth? With the Weblistener we were able to set the AuthenticationScheme, but there is no equivalent for Kestrel.

When we try to hook into the Security/Authorisation packages, we keep on getting a "Scheme not found" exception (which make sense) when running just the console (we like running the console app so we can view some verbose logging etc).

guardrex commented 8 years ago

NOTE: This issue comment is no longer maintained and only applies to beta8-to-RC1 conversions. There will be official guidance on converting an app from RC1-final to RC2-final by the time RC2 releases; additionally, you can get information in the meantime and after the official guidance comes out from Bart Calixto @Bartmax in Notes about my own experience migrating from RC1 to RC2 (Home/1381).

Notes, Comments, and Issues for Publishing to IIS (betaX-Helios to rc1-final-HttpPlatformHandler)

Publishing to IIS Official Documentation: https://docs.asp.net/en/latest/publishing/iis.html

Announcing ASP.NET 5 Release Candidate 1

Note on IIS Version: The requirement for the HttpPlatformHandler is Windows 7+ and IIS 7.5+ (WS2008 R2+).

Note for Windows Authentication: There are both server and application configurations to set. See @Tratcher https://github.com/aspnet/Hosting/issues/364#issuecomment-150294307 and Windows Authentication Providers before getting started with my notes. Also note @Tratcher comment following this post at https://github.com/aspnet/Hosting/issues/364#issuecomment-148570988.

Server

1. The server will obviously require the Web Server (IIS) role to have IIS. Under Web Server, you can set Common HTTP Features, Health and Diagnostics, Performance, and Security bits as needed; however, you do not need to select Application Development. There are two approaches you can take:

Check off Application Development with ASP.NET 4.5, ISAPI Filters, ISAPI Extensions, and .NET Extensibility 4.5. This will also prompt for ASP.NET 4.5 under .NET Framework 4.5 Features. However, the only thing this is going to do (apparently) is enable IIS to read the <handlers> section of the web.config file in order to use the HttpPlatformHandler. IMO this is not a good reason to install all of those pieces that aren't needed, so I'll be going forward and testing with the second option ...
We only need to unlock the <handlers> section so that IIS can read the configuration for the HttpPlatformHandler to be our handler of the app. Instructions ...
- Click the server name in IIS.
- Under Management, open the Configuration Editor.
- In the Section dropdown at the top, select system.webServer > handlers in the list.
- On the right side of the screen, click to Unlock Section.

That's it. That will allow IIS to read the <handlers> section. Also note that if you don't enable Application Development and you run into problems with IIS complaining about other sections of web.config that it can't read and that it used to be able to read back in .NET 4.x days that you can unlock additional sections in Configuration Editor as needed. 2. Download and install HttpPlatformHandler v1.2 on the server. For those who think they may already have some version installed but don't know which one or who wish to absolutely confirm the correct version is there, visit Control Panel > Programs > Programs and Features, where you should see "v1.2" plainly stated in the name. Several folks here either thought they had it (it wasn't installed) or thought they had the correct version (it was v1.0). This is so important that it should be one the first things checked if you can't get things running.

x86 version: http://go.microsoft.com/fwlink/?LinkId=690722 x64 version: http://go.microsoft.com/fwlink/?LinkId=690721 [WebPI and iis.net have been updated with the correct version. Always confirm the version, as there are still several spots on the Net where the old version is linked.]

3. DO NOT uninstall the .NET Framework 4.x from the server. WS 2012/2012R2 requires the .NET Framework for many features of the OS (e.g., WCF TCP Port Sharing, Hyper-V GUI Management Tools, the graphical UI of WS, Windows PowerShell, etc.). 4. For an application moving to the HttpPlatformHandler, change the AppPool Basic Setting for .NET Framework Version to "No Managed Code" either for an existing app in IIS or when you setup a new website in IIS. 5. Pay attention to Data Protection Keys. There is a section in the official doc dealing with this. For more info, including some tips and notes for using Azure Blob Storage and Azure Table Storage to persist keys in a webfarm scenario, see https://github.com/aspnet/DataProtection/issues/107 and https://github.com/aspnet/DataProtection/issues/92. 6. There might be an issue with the identity of the account for the AppPool when it is changed to a user account. See: https://github.com/aspnet/Hosting/issues/464 7. If you're on Windows 7 or WS 2008 R2, confirm you have Visual C++ Redistributable for Visual Studio 2012 Update 4 installed. 8 IIS-Kestrel is a reverse proxy server configuration with IIS managing the ports (i.e., IIS and Kestrel cannot share ports). Assign application ports in IIS and allow random ports to be configured automatically to Kestrel for each application. https://github.com/aspnet/Hosting/issues/629#issuecomment-194400447

Development Environment

1. Update VS2015 with rc1-final bits: Download and run the installer for your system:

https://get.asp.net/OtherDownloads

2. Use dnvm list to confirm the runtimes you need are installed. Use dnvm install 1.0.0-rc1-final -arch x<86/64> -r <core>clr to get each runtime you need. Use dnvm list to confirm your active runtime and default runtime are set properly. 3. Reboot the PC.

Application

Note: If you are using Azure Websites, see the notes below by @davidfowl, a comment by @rhwy at https://github.com/aspnet/Hosting/issues/364#issuecomment-149056384, a comment by @LifeguardConcepts at https://github.com/aspnet/Hosting/issues/364#issuecomment-149648109, and a comment by @mkelley82 at https://github.com/aspnet/Hosting/issues/364#issuecomment-151710024 (remove the forwardWindowsAuthToken attribute). There might be a problem with diagonistic logging that is turned on via the Azure Dashboard, see @samuraiken comment at https://github.com/aspnet/Hosting/issues/364#issuecomment-156365450. Another logging issue is tracked in https://github.com/aspnet/Logging/issues/218. If you're working with the web.cmd and trying to get a certain port for Azure Web Apps, see https://github.com/aspnet/dnx/issues/3181. You will probably run out of space if on the Free tier, see: https://github.com/aspnet/dnx/issues/3192.

Note: There is possibly a problem with having global.json alongside the project files when you publish. I'm testing now (12/3) to determine if this results in a process failure. See @ArieJones comment at https://github.com/aspnet/Home/issues/1147#issuecomment-161629047 for more details.

Note: If you need client cert support, it isn't available yet: See https://github.com/aspnet/IISIntegration/issues/27 and https://github.com/aspnet/Home/issues/1095.

Note: If you are planning to use VS publish with a different folder than wwwroot, see the Notes section at the bottom of this comment. If you are planning to use wwwroot, you should remove that entry from project.json, as its the default now if you have such a folder in the app.

Note: IIS Dynamic Compression is working with the reverse proxy out of Kestrel, but IIS Static Compression is not working right now. See: https://github.com/aspnet/IISIntegration/issues/40#issuecomment-162238448

Note: If you are publishing with VS, the --runtime active flag is added by VS automatically when publishing, which will provide the runtime for your deployment. If you are using the command line, make sure you include the --runtime active (or whichever runtime you plan to use if not the "active" one) when you do a manual dnu publish. You'll probably also want to get the application compiled into a NuGet package for the deployment; so when using the command line, add the --no-source flag. When using VS Publish, at Publish Web > Settings > File Publish Options and check the box in the publish settings for Compile source files into NuGet packages. See @Aerendel comment: https://github.com/aspnet/Hosting/issues/364#issuecomment-164171065

1. If you are refactoring an existing betaX application, you can remove the wwwroot > bin > AspNetLoader.dll. 2. If you are refactoring an existing betaX application, modify your wwwroot > web.config to include the following configuration bits. For people on Azure Web Apps, don't forget to check the note links above for important information. if you would like to see the full schema for the httpPlatform element, I put up a gist HERE and you can checkout the HttpPlatformHandler Configuration Reference. Note that if you add a child element to the httpPlatform element (e.g., environment variables), @DennisGlindhart found a bug where on publish it will remove your child element, see: https://github.com/aspnet/dnx/issues/3062.

<configuration>
  <system.webServer>
    <handlers>
      <add
        name="httpPlatformHandler"
        path="*"
        verb="*"
        modules="httpPlatformHandler"
        resourceType="Unspecified"/>
    </handlers>
    <httpPlatform
      processPath="%DNX_PATH%"
      arguments="%DNX_ARGS%"
      stdoutLogEnabled="false"
      stdoutLogFile="..\logs\httpplatform-stdout"
      startupTimeLimit="3600"/>
  </system.webServer>
</configuration>

3. Create a logs folder in the root of the project in case you turn on log files in web.config. If you don't provide the stdoutLogFile path, the logs are produced in your wwwroot folder, which isn't so good. A timestamp and .log extension will be added for you. As of 10/16, VS will not update this logs folder contents when the logs are written to disk ... you must browse to the folder in the OS or close and re-open the project to see them in the VS UI. If you provide a path like stdoutLogFile="..\logs\httpplatform-stdout" (the default), your logs will end up in a logs folder in the root of the project on the server (i.e., they will end up in the logs folder along with your approot and wwwroot folders). More info: https://github.com/aspnet/Tooling/issues/224 4. project.json: Drop "Microsoft.AspNet.Server.IIS": "1.0.0-betaX" and add the "Microsoft.AspNet.Server.Kestrel", "1.0.0-rc1-final" package. 5. project.json: Update betaX packages to rc1-final packages. 6. An issue has been reported by endink on using dnx451-x64 that results in an unresponsive app. Use dnx452 or better. More info: https://disqus.com/home/discussion/aspnetdocs/publishing_to_iis_aspnet_001_documentation_38/?utm_source=reply&utm_medium=email&utm_content=read_more#comment-2348633407. 7. Restore packages. If anything breaks, delete the project.lock.json file and close/reopen the project. If things are still broken, clear the packages folder and try again. 8. project.json: We need a command to trigger hosting.

"web": "Microsoft.AspNet.Server.Kestrel"

9. project.json, Startup.cs:Configure: Most apps will require the Microsoft.AspNet.IISPlatformHandler package and app.UseIISPlatformHandler(); per https://github.com/aspnet/Templates/issues/189. Put the app.UseIISPlatformHandler(); very high (perhaps first) in the list of middlewares. 10. If you were one of the folks who ever had the WEBPROJ_ENABLEBETA7RENAMES environment variable set, get rid of it. More info: https://github.com/aspnet/Tooling/issues/232#issuecomment-149686652 11. If your app deals with IIS virtual directories, an issue is open to address a problem with virtual directories. More info: https://github.com/aspnet/KestrelHttpServer/issues/214 and https://github.com/aspnet/IISIntegration/issues/14. 12. Update your Publish profiles for the latest runtime version (if you are using VS publish). 13. Update global.json for latest runtime version. If in the past you were unspecific about the architecture and runtime, you can state them explicitly ...

{
  "projects": [
    "src"
  ],
  "sdk": {
    "architecture": "x64",
    "runtime": "coreclr",
    "version": "1.0.0-rc1-update1"
  }
}

14. Compile the project. Fix any errors. See Announcements in-turn for each betaX all the way to rc1-final for breaking changes.

beta6 Announcements beta7 Announcements beta8 Announcements rc1-final Announcements

15. Comfirm running in IIS Express. 16. Confirm running on the server.

Notes

If you have a problem loading sni.dll on Win7/WS2008R2, see https://github.com/dotnet/corefx/issues/4503#event-464176257.
Beware a project folder/file layout where the sln, global.json and xproj files are in the same folder. @buraktamturk reports on this issue in https://github.com/aspnet/Hosting/issues/364#issuecomment-156576487.
Beware HttpPlatformHandler handling of Url paths with escaped ? (%3F) and backslashes. See https://github.com/aspnet/IISIntegration/issues/33.
If you're using DataProtection (esp. in a webfarm scenario), beware where and how the keys are being stored. See https://github.com/aspnet/DataProtection/issues/102 and https://github.com/aspnet/DataProtection/issues/92.
As of 10/16, there is a bug in the IISPlatformHandlerMiddleware such that HttpContext.Connection.RemoteIpAddress may come back null. More info: https://github.com/aspnet/IISIntegration/issues/17. A PR is in on this one and it should be fixed for RC2.
Folks sometimes end up getting a 502.3 Bad Gateway error when trying to access the app. This most likely means that you have the wrong version of the HttpPlatformHandler installed on your server (there are lots of links to v1.0 floating around the Net). Go to Control Panel > Programs > Programs and Features and see if v1.2 shows up as the one installed on the server. If not, get rid of v1.0 and use the correct installer link above for either x86 or x64. More info: https://github.com/aspnet/Hosting/issues/364#issuecomment-142517221 and https://github.com/aspnet/Hosting/issues/364#issuecomment-144003845 with @davidfowl responses.
If you are getting a 500.21 Internal Server Error with a message about a bad module reference, you might not have any version of the HttpPlatformHandler installed (or enabled). Check IIS Modules (presence of module), IIS Handler Mappings (enabled module), and Control Panel > Programs > Programs and Features (correct version of module).
If you are getting a 500.19 Internal Server Error with a message about a locked configuration section, then you need to either (a) add Application Development to the server roles (less preferred, since it loads a lot of bits that aren't needed), or (b) click the server in IIS and go into the Configuration Editor and click Unlock Section on the system.webServer > handlers section (see Server 1 above).
If you are working with an Azure Web App and getting the The specified CGI application encountered an error and the server terminated the process exception, see a note on the DNX_PATH at https://github.com/aspnet/Hosting/issues/412.
As of 10/22, there is a problem with VS Publish when you want to use a folder other than wwwroot. This folder is currently defined in project.json's webroot node. VS Publish does not fully respect this value. If you change the folder to something else, e.g., httpdocs, put static files in the folder and make changes to the web.config file there; when VS Publish is triggered, it will actually still create a wwwroot folder, not move your static files, and not create the folder you intend to use in the publish output folders. The only thing it does do (somewhat) correctly is move your web.config from the webroot-defined folder in your project into the VS-created wwwroot folder. This not quite right: The web.config file in your webroot-defined folder should be moved to a webroot-defined folder in your publish output. Because of this issue, you will need to manually create your folder in the output after the VS Publish, move your static files to the folder, and move the web.config file to the folder ... do all of this prior to moving the app to the server.

References:

.NET Web Development and Tools Blog: Announcing Availability of ASP.NET Beta8 http://blogs.msdn.com/b/webdev/archive/2015/10/15/announcing-availability-of-asp-net-5-beta8.aspx

Announcing ASP.NET 5 Release Candidate 1 http://blogs.msdn.com/b/webdev/archive/2015/11/18/announcing-asp-net-5-release-candidate-1.aspx

Ask the Core Team Blog: Removing .NET Framework 4.5/4.5.1 removes Windows 2012/2012R2 UI and other features http://blogs.technet.com/b/askcore/archive/2014/04/24/removing-net-framework-4-5-4-5-1-removes-windows-2012-2012r2-ui-and-other-features.aspx

aspnet/KestrelHttpServer: Sample Application https://github.com/aspnet/KestrelHttpServer/tree/dev/samples/SampleApp

aspnet/Announcements: Change to IIS hosting model https://github.com/aspnet/Announcements/issues/69 https://github.com/aspnet/Hosting/issues/364

Tratcher commented 8 years ago

@jruckert Kestrel does not natively support windows auth, you need to be behind IIS or use WebListener.

jruckert commented 8 years ago

@Tratcher Thanks!

ghost commented 8 years ago

@davidfowl It works now, thanks for releasing the tooling!

Anderman commented 8 years ago

I have upgrade my apllication from beta7 to beta8. Normal post request are fine but an ajax post request give me HTTP Error 502.3 - Bad Gateway

tuespetre commented 8 years ago

Doesn't seem to work for virtual applications. Created a new site pointed at the same folder and was able to go to it; the virtual application just give me 404 even though the event viewer indicates the HttpPlatformHandler has started a process successfully.

Anderman commented 8 years ago

The 404 is because the page doesn't exist in the default web template. The errors seems to come from a bug in EF or JSON. Running the site under kestrel(web) give me this error

(The response has already started, the error page middleware will not be executed.)

error   : [Microsoft.AspNet.Diagnostics.DeveloperExceptionPageMiddleware] An unhandled exception has occurred while executing the request
System.InvalidOperationException: The EF.Property<T> method may only be used within LINQ queries.
   at Microsoft.Data.Entity.EF.Property[TProperty](Object entity, String propertyName)
   at lambda_method(Closure , QueryResultScope )
   at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeList(JsonWriter writer, IEnumerable values, JsonArrayContract contract, JsonProperty member, JsonContainerContract collectionC
ontract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeValue(JsonWriter writer, Object value, JsonContract valueContract, JsonProperty member, JsonContainerContract containerContrac
t, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeObject(JsonWriter writer, Object value, JsonObjectContract contract, JsonProperty member, JsonContainerContract collectionCont
ract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeValue(JsonWriter writer, Object value, JsonContract valueContract, JsonProperty member, JsonContainerContract containerContrac
t, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeList(JsonWriter writer, IEnumerable values, JsonArrayContract contract, JsonProperty member, JsonContainerContract collectionC
ontract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeValue(JsonWriter writer, Object value, JsonContract valueContract, JsonProperty member, JsonContainerContract containerContrac
t, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeObject(JsonWriter writer, Object value, JsonObjectContract contract, JsonProperty member, JsonContainerContract collectionCont
ract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeValue(JsonWriter writer, Object value, JsonContract valueContract, JsonProperty member, JsonContainerContract containerContrac
t, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.Serialize(JsonWriter jsonWriter, Object value, Type objectType)
   at Newtonsoft.Json.JsonSerializer.SerializeInternal(JsonWriter jsonWriter, Object value, Type objectType)
   at Microsoft.AspNet.Mvc.JsonResult.ExecuteResultAsync(ActionContext context)
   at Microsoft.AspNet.Mvc.Controllers.FilterActionInvoker.<InvokeResultAsync>d__53.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at Microsoft.AspNet.Mvc.Controllers.FilterActionInvoker.<InvokeResultFilterAsync>d__52.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNet.Mvc.Controllers.FilterActionInvoker.<InvokeAllResultFiltersAsync>d__51.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at Microsoft.AspNet.Mvc.Controllers.FilterActionInvoker.<InvokeResourceFilterAsync>d__46.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNet.Mvc.Controllers.FilterActionInvoker.<InvokeAsync>d__41.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNet.Mvc.Infrastructure.MvcRouteHandler.<RouteAsync>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNet.Routing.Template.TemplateRoute.<RouteAsync>d__27.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNet.Routing.RouteCollection.<RouteAsync>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNet.Builder.RouterMiddleware.<Invoke>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.<Invoke>d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.<Invoke>d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.<Invoke>d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.<Invoke>d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.<Invoke>d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.<Invoke>d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.<Invoke>d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.<Invoke>d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNet.Diagnostics.Entity.DatabaseErrorPageMiddleware.<Invoke>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNet.Diagnostics.Entity.DatabaseErrorPageMiddleware.<Invoke>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNet.Diagnostics.DeveloperExceptionPageMiddleware.<Invoke>d__6.MoveNext()
warning : [Microsoft.AspNet.Diagnostics.DeveloperExceptionPageMiddleware] The response has already started, the error page middleware will not be executed.

Tratcher commented 8 years ago

@tuespetre virtual apps mostly work, but the PathBase isn't set correctly. See https://github.com/aspnet/IISIntegration/issues/14

As a workaround you can wrap your whole startup in an app.Map with the correct PathBase.

tuespetre commented 8 years ago

Thanks @Tratcher. That works well for a temporary workaround.

MaxxDelusional commented 8 years ago

Does anyone know why this might be happening?

guardrex commented 8 years ago

@MaxxDelusional Just spit-balling here, did you set the AppPool .NET Framework Version to "No Managed Code?"

guardrex commented 8 years ago

@MaxxDelusional Well, that's not it. I just switched back and my test app still loaded.

guardrex commented 8 years ago

@MaxxDelusional Are these entries case sensitive? Check your casing:

<handlers>
  <add
    name="httpPlatformHandler"
    path="*"
    verb="*"
    modules="httpPlatformHandler"
    resourceType="Unspecified"/>
</handlers>

MaxxDelusional commented 8 years ago

@GuardRex Yes, the ApplicationPool is set to "No Managed Code", and my handler element is identical to yours.

guardrex commented 8 years ago

@MaxxDelusional The module is in the list?

capture

guardrex commented 8 years ago

@MaxxDelusional Might be worth the trouble to uninstall and re-install the module to just to make sure the install was good. Follow with a reboot. Although I wouldn't think it necessary in just adding a module, a reboot has been helpful to me a few times with IIS feature installers.

capture

Installers:

x86 version: http://go.microsoft.com/fwlink/?LinkId=690722 x64 version: http://go.microsoft.com/fwlink/?LinkId=690721

MaxxDelusional commented 8 years ago

@GuardRex I think you are on to something, the Module was missing from my list. I'm going to try to reinstall.

guardrex commented 8 years ago

@MaxxDelusional Ahhhhh! Yeah. I've had crap like that happen before. Check the Handlers, too, and make sure it goes "enabled" after you do the re-install and reboot:

capture

MaxxDelusional commented 8 years ago

@GuardRex Looks like I'm back up and running. Thanks for your help!

guardrex commented 8 years ago

@MaxxDelusional Awesome!

"Oh! My horoscope said I'd be useful to somebody today." Organon (Geoffrey Bayldon), Dr. Who: The Creature from the Pit, 1979

... and on to the next one. Let me know if you see and/or solve this pesky POST problem: https://github.com/aspnet/IISIntegration/issues/16

jmblakl commented 8 years ago

After upgrading to beta8 from beta7 I am no longer able to run in Azure Websites. I get the generic 500 Internal Server error. I am running locally On IISExpress after following @GuardRex 's steps.

I've found the generic something went wrong is very difficult to diagnose on Azure Websites. I am publishing using the publish profile I have in Visual Studio.

guardrex commented 8 years ago

FYI for those looking at my steps earlier, I added one in the Application section:

7. project.json, Startup.cs:Configure: You will probably need the Microsoft.AspNet.IISPlatformHandler package and app.UseIISPlatformHandler(); per aspnet/Templates#189.

... per tip from @MaxxDelusional and based on aspnet/Templates#189 comment.

Anderman commented 8 years ago

The HTTP Error 502.3 - Bad Gateway has nothing to do with configuration. You will get this error when sending an incomplete response on an iisexpress server

guardrex commented 8 years ago

For those tracking the guidance I posted, updates:

I added to the Application section:

Add a log path to web.config: stdoutLogFile="..\logs\httpplatform-stdout"

3. Create a logs folder in the root of the project in case you turn on log files in web.config. If you don't provide the stdoutLogFile path, the logs are produced in your wwwroot folder, which isn't so good. A timestamp and .log extension will be added for you. As of 10/16, VS will not update this logs folder contents when the logs are written to disk ... you have to browse to the folder in the OS or close and re-open the project to see them in the VS UI. Also note that the VS tooling team is planning on providing a stable place for these log files (a logs folder is my dumb idea), and I'll update here when it's decided. More info: https://github.com/aspnet/Tooling/issues/224

I added a Notes section with:

As of 10/16, there is a bug in the IISPlatformHandlerMiddleware such that HttpContext.Connection.RemoteIpAddress may come back null. More info: https://github.com/aspnet/IISIntegration/issues/17

/cc @Rick-Anderson

tbprince commented 8 years ago

I'm having troubles running ASP.NET5 on Windows Azure Pack Websites v2. David, is it possible to get a template about web.config + web.cmd in order to run on WebSites v2 (not Azure itself but WAP) ? Of course standard project published via FileSystem option in VStudio doesn't work with a gateway error. I'm trying to follow up solution provided by GuardRex but his solution needs %DNX_PATH% in HTTPPlatformHandler path and I'm not sure that is the right way to go in WebSites v2. How would HTTPPlatformHandler know which command to start if %DNX_PATH% is defined inside web.cmd ?

Thanks.

davidfowl commented 8 years ago

I'm trying to follow up solution provided by GuardRex but his solution needs %DNX_PATH% in HTTPPlatformHandler path and I'm not sure that is the right way to go in WebSites v2. How would HTTPPlatformHandler know which command to start if %DNX_PATH% is defined inside web.cmd ?

Whatever you do, you need to publish. When you're running in Visual Studio, the web.config is different from web you publish.

How would HTTPPlatformHandler know which command to start if %DNX_PATH% is defined inside web.cmd ?

You can set a magic environment variable and it will generate an azure/azure pack friendly web.config. If you set DNU_PUBLISH_AZURE=true and then publish to the file system using dnu manually. You should something that will run on v2 of the azure pack.

mtebenev commented 8 years ago

It seems that SSL on custom domain on azure (basic tier) is not working. It works when you do request through azurewebsites.net but it does not work when you use custom domain. Azure redirects to HTTP with 302 when requesting a web site through custom domain. Also rewrite rules for SSL are not working as well:

<rewrite>
  <rules>
    <rule name="HTTP to HTTPS redirect" stopProcessing="true">
      <match url=".*" />
      <conditions>
        <add input="{HTTPS}" pattern="OFF" />
      </conditions>
      <action type="Redirect" url="https://{HTTP_HOST}/{R:0}" redirectType="Permanent" />
    </rule>
  </rules>
</rewrite>

When I set this rule in web.config application returns 502

mtebenev commented 8 years ago

Sorry, false report. It suddenly started to work after some time without any changes. Did not re-check rewrite rules though.

tbprince commented 8 years ago

@davidfowl thanks. Packaging the project by manually invoking DNU was easier said than done but maybe that's me ;-) It seems that the only difference is about providing full paths to HTTPPlatformModule instead of relative ones, like someone else said. For other people hitting the same problem, this is the only change I had to do to "Publish to FileSystem" package to make it work on WAP WebSites v2:

<httpPlatform processPath="%home%\site\approot\web.cmd" arguments="" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout.log" startupTimeLimit="3600"></httpPlatform>

Now it seems to be working fine. Maybe there should be an option when packaging for Azure to export to filesystem only to prepare for WAP or AS.

davidfowl commented 8 years ago

@tbprince The difference goes away once Azure pack supports the newer module.

tbprince commented 8 years ago

@davidfowl that's great, thanks. However it's nice to see our customers can start working with beta8 right now on WAP. I hope the WAP guys will soon upgrade to the new handler but in the meantime, we're not struck. Thanks.

MathiasKowoll commented 8 years ago

It would be great to have a Mac to IIS guide. i tried to publish my project using all the comments without any luck. It si a new project using aspnet generator for beta 8. I installed and verfied httpplatformhandler with version 1.2. I can confirm it is working from windows the web.cmd

rhwy commented 8 years ago

just to confirm what's been said before, for those working on a Mac ;-), the most important change to the publish to make it work on WAP is to provide the full paths to httpPlatformHandler.

my test config for this:

I'm on mac with the WebApplicationBasic app (generated by yo aspnet)
I restore/build then publish it with a clr rc1 runtime available locally : dnu publish --configuration Release --runtime /Fullpath/to/my/runtime//dnx-clr-win-x86.1.0.0-rc1-15838 -o ../../artifacts/WebApplicationBasic/
then change the web config as specified by @tbprince in ../../artifacts/WebApplicationBasic/wwwroot/web.config (replace full path for httpPlatformHandler as <httpPlatform processPath="%home%\site\approot\web.cmd" arguments="" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout.log" startupTimeLimit="3600"></httpPlatform>
then ftp the whole ../../artifacts/WebApplicationBasic folder to WAP site folder

Now I have an azure web app working

please note that

I was not able to pull the clr runtime directly from my dnvm mac and need to add a copy from my windows VM, if someone can help on that?...
when I try to publish directly from git publish the process failed because the dnvm fails to install the runtime from nuget (even with DNX_FEED set). When I log to console, the dnvm version used by kudu seems to be the beta6, I suppose there's some incompatibilities around ? but if that could be fixed it would be much better if we can git publish directly without publish locally+ftp ;-) thanks!

MathiasKowoll commented 8 years ago

What about non WAP services just Windows 2012 R2??

Im getting error 1000 and 1004 from event manager as already described above.

Any help is greatly appreciated

EDIT:

I was able to publish to Windows Server!!!, will update a small tutorial later.

guardrex commented 8 years ago

@BeelzeBu If you found something new, let me know, I'd like to add it to my notes here: https://github.com/aspnet/Hosting/issues/364#issuecomment-148567294

guardrex commented 8 years ago

There's an important update coming out of discussion and testing with @Rick-Anderson and followup to https://github.com/aspnet/Hosting/issues/364#issuecomment-141362612 by @davidfowl , and my https://github.com/aspnet/Hosting/issues/364#issuecomment-148567294 is updated to reflect this:

We all know well that to get IIS on WS we install the Web Server (IIS) role. Under Web Server, you can set Common HTTP Features, Health and Diagnostics, Performance, and Security bits as needed; however, you do not need to select Application Development for HttpPlatformHandler-handled .NET apps that are not using .NET 4.x based on Hello World! testing I just did. It seems that there are two approaches you can take:

Check off Application Development with ASP.NET 4.5, ISAPI Filters, ISAPI Extensions, and .NET Extensibility 4.5. This will also prompt for ASP.NET 4.5 under .NET Framework 4.5 Features. However, the only thing this seems to do is enable IIS to read the <handlers> section of the web.config file in order to use the HttpPlatformHandler. None of those .NET 4.5 and ISAPI bits seem to be used AFAIK. IMO this is not a good reason to install all of those pieces that I don't need; so instead of enabling Application Development, I'll be going forward (testing) with the second option ...
We only need to unlock the <handlers> section so that IIS can read the configuration for the HttpPlatformHandler to be our handler of the app. Instructions ...
- Click the server name in IIS.
- Under Management, open the Configuration Editor.
- In the Section dropdown at the top, select system.webServer > handlers in the list.
- On the right side of the screen, click to Unlock Section.

That's it. That will allow IIS to read the <handlers> section. Also note that if you don't enable Application Development and you run into problems with IIS complaining about other sections of web.config that it can't read and that it used to be able to read back in .NET 4.x days that you can unlock additional sections with the Configuration Editor as needed.

If anyone has a caveat, gotcha, edge case, or additional information about why Application Development would/should be enabled, I'd like to hear about it.

ddotlic commented 8 years ago

@GuardRex Hey, thanks for the detailed list of steps for beta 8.

I have a potentially silly question (seeing how you did not touch on this at all): what did you install on the server exactly?

I ask because when I update dnvm (using DotNetVersionManager-x64.msi) on my dev machine, I end up with:

It installs in c:\Program Files\Microsoft DNX\Dnvm\ but does not set env vars
I have to navigate there, then run dvnm setup which installs the same two commands (dnvm.cmd and dnvm.ps) into my account's folder (will call it [dnx_folder]), like this c:\Users\[my_account]\.dnx and adds the [dnx_folder]\bin of this folder to my env (to the path); side note: if it finds older version of the files already there (say, from beta 7) it does nothing - this is surprising to say the least
Then if I install runtime by using dnvm install ... I finally have a runtime, but it's installed in [dnx_folder]\runtimes (and its bin is added to the path) so all folders are tied to my user account

Since the Web sites that we run in IIS never use domain accounts (like mine) I don't see how to run a beta8 site. Also, the DNX_PATH or DNX_ARGS env vars aren't set by any of commands executed (true, I can set this myself).

Am I missing something obvious? What is the cleanest way to install vNext on a server so that it's available to all accounts? Or should I runas account which will ultimately serve the site and do the dance described above but as that account?

Oh yeah, one more thing :smile: do we really need to reboot the machine after installing platform handler 1.2? I noticed that I can see the handler in modules but not in handler mappings - is this because I did not restart?

Forgot to add, we're running 2008R2.

davidfowl commented 8 years ago

@ddotlic You need to publish your application and it will fix your web.config to have the right stuff.

ddotlic commented 8 years ago

@davidfowl Thanks for your comment, but I never said I had any issues with web.config :smile:

In any case I will publish, that's for sure, but that only creates approot and webroot with good/correct files inside (and I publish 'locally' or on a build machine, then I copy over to the server which has IIS). I still need DNX on the target machine - which most of my points above touch upon.

guardrex commented 8 years ago

@ddotlic The only thing installed on the server is the HttpPlatformHandler ... and of course ... the Web Server (IIS) role. Your DNX will be in approot > runtimes, so it will deploy with the app.

Following what @davidfowl said, what I do is use VS Publish to Filesystem ... with a twist. When I do a Publish to Filesystem, I'm using a very slightly modified PowerShell script.

You'll notice in VS Publish to Filesystem the option to publish via PowerShell script. I invoke a custom script of my own right after the application is published to my output folder that triggers a MSDeploy. See https://github.com/aspnet/Docs/issues/105#issuecomment-113716606 for details. That's just sitting in a file in my project called msdeploy.bat. Just keep in mind that with MSDeploy (if you go that route) you are publishing to the folder on the server above your approot and wwwroot folders; but in IIS, you'll be setting the physical path to the app directly to the wwwroot folder. Your other option is as the official docs specify: Use Xcopy.

To make it even more interesting, I've been playing with dropping MSDeploy altogether and just going pure PowerShell all the way. I have a highly experimental (and slightly code-smelly) repo you can check out here: https://github.com/GuardRex/net5-iis-ps-publish. The idea behind getting rid of MSDeploy is that it even requires .NET 3.5 to run (yuck!).

Yeah, for the server its just the HttpPlatformHandler. No, you don't need to restart the server for any of this. You can even setup the Web Server (IIS) role without restarting.

guardrex commented 8 years ago

@ddotlic One more note ...

What is the cleanest way to install vNext on a server so that it's available to all accounts?

The app is still going to run under the AppPool model of IIS, so it will be running under whatever account you have the AppPool set to run under. It isn't "available to all accounts" in any cosmic sense.

davidfowl commented 8 years ago

/cc @glennc

ddotlic commented 8 years ago

@GuardRex and @davidfowl Thanks for your comments. Like I said, there was something obvious that I missed which is the fact - and this was the dream from the very beginning of vNext - that the whole framework* and runtime are installed with our site, glorious!

The app is still going to run under the AppPool model of IIS, so it will be running under whatever account you have the AppPool set to run under

Yes and on top of that since the web app itself does not run any code per se (it delegates to kestrel) it does almost not matter which account is running it (though I guess when it itself starts kestrel it starts it under the same account so it does matter in the end).

My comment regarding 'availability to all accounts' was based on my mistaken assumption that the hosting in IIS will largely reuse the same approach as we have on our dev machines vis-a-vis runtime (DNX itself), which is not the case.

Thanks again for the clarifications!

of course not the whole framework but only the subset we're using which is magnificient :+1:

guardrex commented 8 years ago

@ddotlic Sure thing. If you discover any new tidbits, please let me know, and I'll add them to those comments. That effort was to tide us over until the official docs arrive that @Rick-Anderson is finishing up now.

Side-note to your comment about accounts: For Data Protection to work in a webfarm scenario (I need it for Antiforgery), keys must be written to a central repository. My effort to use Azure Files for this looked promising ... until I ran into the age old problem of the app running under an account that didn't have access to file shares! Impersonation nightmares ... remember those??!! No worries ... I built an Azure Table Storage key repository, and @GrabYourPitchforks built an Azure Blob Storage key repository. I agree with you: The account isn't going to matter until the app has to do something in the OS that the account privileges won't permit.

luchen1021 commented 8 years ago

Beta 8 load resource assembly cause exception System.IO.FileNotFoundException. The resource assembly is defined in legacy .NET class library, not DNX class library. The same solution works for Beta 7 but fails when using Beta 8. Beta 8 Solution https://github.com/luchen1021/AspNet5Beta8Resource.git https://github.com/luchen1021/AspNet5Beta8Resource Beta 7 Solution https://github.com/luchen1021/AspNet5Beta7Resource.git https://github.com/luchen1021/AspNet5Beta7Resource

Change project reference to binary reference for Legacy Library and Legacy Resource Library. https://github.com/luchen1021/AspNet5Beta8ResourceBinaryReference.git https://github.com/luchen1021/AspNet5Beta8ResourceBinaryReference Running in Visual Studio 2015 with IISExpress still get the same exception as shown in top comment. Publish works fine in binary reference approach. After deploying the published output to IIS (not IIS express), it works fine without any exception.

Exception Detail: System.IO.FileNotFoundException: {"Could not find file 'AspNet5Beta8Resource.LegacyResources.resources'.":null} Data: {System.Collections.ListDictionaryInternal} FileName: null FusionLog: null HResult: -2147024894 HelpLink: null IPForWatsonBuckets: {1858045768} InnerException: null IsTransient: false Message: "Could not find file 'AspNet5Beta8Resource.LegacyResources.resources'." RemoteStackTrace: null Source: "mscorlib" StackTrace: " at System.Reflection.RuntimeAssembly.InternalGetSatelliteAssembly(String name, CultureInfo culture, Version version, Boolean throwOnFileNotFound, StackCrawlMark& stackMark) at System.Resources.ManifestBasedResourceGroveler.GetSatelliteAssembly(CultureInfo lookForCulture, StackCrawlMark& stackMark) at System.Resources.ManifestBasedResourceGroveler.GrovelForResourceSet(CultureInfo culture, Dictionary`2 localResourceSets, Boolean tryParents, Boolean createIfNotExists, StackCrawlMark& stackMark) at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo requestedCulture, Boolean createIfNotExists, Boolean tryParents, StackCrawlMark& stackMark) at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents) at System.Resources.ResourceManager.GetString(String name, CultureInfo culture) at AspNet5Beta8Resource.LegacyResources.Properties.Resources.get_Title() in D:\Project\GitHub\AspNe t5Beta8Resource\AspNet5Beta8Resource.LegacyResources\Properties\Resources.Designer.cs:line 68 at AspNet5Beta8Resource.LegacyLibrary.LegacyClass.GetTitle() in D:\Project\GitHub\AspNet5Beta8Resource\AspNet5Beta8Resource.LegacyLibrary\LegacyClass.cs:line 14 at AspNet5Beta8Resource.DnxWebHost.Controllers.ValuesController.Get() in D:\Project\GitHub\AspNet5Beta8Resource\AspNet5Beta8Resource.DnxWebHost\Controllers\ValuesController.cs:line 21" TargetSite: {System.Reflection.RuntimeAssembly InternalGetSatelliteAssembly(System.String, System.Globalization.CultureInfo, System.Version, Boolean, System.Threading.StackCrawlMark ByRef)} WatsonBuckets: null _HResult: -2147024894 _className: null _data: {System.Collections.ListDictionaryInternal} _dynamicMethods: null _exceptionMethod: {System.Reflection.RuntimeAssembly InternalGetSatelliteAssembly(System.String, System.Globalization.CultureInfo, System.Version, Boolean, System.Threading.StackCrawlMark ByRef)} _exceptionMethodString: null _fileName: null _fusionLog: null _helpURL: null _innerException: null _ipForWatsonBuckets: {1858045768} _maybeFullPath: null _message: "Could not find file 'AspNet5Beta8Resource.LegacyResources.resources'." _remoteStackIndex: 0 _remoteStackTraceString: null _safeSerializationManager: {System.Runtime.Serialization.SafeSerializationManager} _source: "mscorlib" _stackTrace: {sbyte[192]} _stackTraceString: null _watsonBuckets: null _xcode: -532462766

_xptrs: {0}

Tratcher commented 8 years ago

@luchen1021 I'm pretty sure that is unrelated to this topic, open a new issue in Home or DNX.

luchen1021 commented 8 years ago

I already opened a issue in home, will open one in DNX. It only happens when debugging the solution in Visual Studio 2015 IDE with IIS Express host. The IIS host with published output works fine.

aspnet / Hosting