So I wanted to document a couple of interesting points that had not occurred to me about hosting ASP.NET Core application. The reason for the disconnect, I believe, is because I have only ever known a web world that was housed within a modern IIS context.
web.config
Your web.config file was the primary mechanism for your app to interact with IIS, with it we do things like define Forms Authentication, URL Rewriting, define Http Modules and so much more. However almost all of this has gone, your typical configuration now ends up in Startup.cs configured with Middleware. With this still being IIS though if you deploy from Visual Studio you will get a stripped down web.config for free and it typically looks like this:
So what are the important parts? The handler called AspNetCoreModule is the connection between your application and IIS, in fact I have noted before that if you look at task manager you will notice two process (w3wp.exe and dotnet.exe) where once there was one (w3wp.exe). Running outside of the IIS process is a significant architectural change and has significant repercussions that I am sure I will talk about in the future. Finally the aspNetCore element defines your assembly that will be run by dotnet.exe.
app_offline.htm
FTP deploying my asp.net core application was a genuine hassle for a long time because all you core dlls are in use and it does not provide a shadow copy. In order to push new files out to your server you really need deploy the app_offline.htm file first. I have been using IIS for a long time and I barely remember this, however, this file shuts your app down gracefully and once shutdown you get the chance to copy files. Even performing soft resets was not helpful. WebDeploy in Visual Studio essentially does this process for you automatically and then deletes the file when it is finished.
It took me a long time to realize what was happening, I hope this helps someone.
Comments are closed.