CHAPTER 7
You’ve built your application with simple ASP.NET Core, or by using ASP.NET Core MVC for more complex sites, and the time has come to show it to the world. A few years ago, we were mostly interested in deploying to internal servers, but with the rise of cloud computing, now it's just as likely that we deploy to Azure.
Nevertheless, in this chapter we will discuss both experiences for local servers and for Azure.
ASP.NET Core, being based on OWIN, doesn't depend on the server, but it could in theory run on top of any server that supports it.
Normally, during development, an ASP.NET Core application runs hosted by a local web server, called Kestrel, that is configured within the Program.cs file that starts the application. Basically, each ASP.NET Core application is self-contained and could run without external web servers. But while being optimized for performance and being super-fast, Kestrel misses all the management options of a full-fledged web server like IIS.
Self-contained applications (and not just DLLs) require a different approach for hosting them inside IIS. Now, IIS is just a simple proxy that receives the requests from the client and forwards them to the ASP.NET Core application on Kestrel. It then sits and waits for processing to be completed, and finally, returns the response back to the originator of the request.
In order to host ASP.NET Core applications in IIS, we need to install a specific module that does the "reverse proxy" work and makes sure the application is running. This module is called AspNetCoreModule, and can be installed from the ASP.NET Core server hosting bundle.
If you want to try running ASP.NET Core via IIS on a development machine, there is nothing to do because the module is already installed as part of the SDK. If, on the other hand, you want to try it on a real server, the module has to be installed. Figure 6-1 shows the module listed inside the IIS manager application.

Figure 6-1: IIS Modules
With the module installed, the next step is creating a website. Since the module will just act as a proxy without running any .NET code, the website needs an application pool configured to run without any CLR, so the option No Managed Code must be selected, as shown in Figure 6-2.

Figure 6-2: IIS Application Pool Basic Configuration
The configuration of the AspNetCoreModule comes from the web.config file in the root of the folder.
Code Listing 6-1
<?xml version="1.0" encoding="utf-8"?> <configuration> <location path="." inheritInChildApplications="false"> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" /> </handlers> <aspNetCore processPath="dotnet" arguments=".\PublishingSample.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" /> </system.webServer> </location> </configuration> |
Publishing the application is easy using the dotnet command-line tool. Just use the publish command to build and generate a self-contained folder that can be easily copied to the location where the website is. Normally, the published application is saved to the ./bin/[configuration]/[framework]/publish folder, but the target location can also be changed with a command-line option.
Code Listing 6-2
dotnet publish --framework netcoreapp2.2 --output "c:\temp\PublishFolder" --configuration Release |
The publish operation also runs all the MSBuild targets and can, for example, run the bundling and minification of scripts and styles. It also automatically creates (or updates if one is specified) the web.config file with the right values for the project.
Now, all that’s left is copying the folder to where the website is configured. The ASP.NET Core site is running on IIS.
One thing that is missing in the dotnet publish command is the ability to publish to a remote server and perform incremental updates. An alternative publish method is the Publish dialog in Visual Studio.
Typically, a system administrator will provide a publishing profile that can be imported into the Publish dialog. When publishing, the application will be built and then pushed to the remote server via Web Deploy.
Instead of deploying on premises, you could use the cloud. And when we talk about the cloud, we cannot forget to mention Microsoft Azure, which is absolutely one of the most important cloud computing platforms available right now. It offers tons of services, supporting almost all possible user needs.
Whether our application needs to scale or not, Microsoft Azure could be a good solution to reduce the friction of server administration, configuration, hardware problems, backup, and so on.
If you prefer to use another cloud hosting service, like Amazon Web Services (AWS) or Google Cloud, you can, but usually they offer virtual machines. Deploying there is similar to doing it on a remote IIS that you manage.
Azure is different because it offers a service called App Service, which breaks down the barriers of configurations.
Deploying to Azure from Visual Studio is really easy, even if you have to create new resources.
From the Solution Explorer, right-click on the project name, and then select Publish.

Figure 6-3: Publish Web Application Using Visual Studio
Next, you can choose how to publish your application. You can choose from among various targets, both local and on Azure. When choosing Azure, you choose to create new resources or publish to some that have been created already.

Figure 6-4: Select Publishing Targets
If you choose Create New, in the next screen you can create an app service in which to host the web application. When running some tests, I recommend also creating a new resource group and a hosting plan, so that you don't interfere with any other apps you might already have on Azure. This way, once the test is complete, you can just delete the resource group, and everything will be deleted as well.

Figure 6-5: Create App Service
Now, click Create and wait for resources to be created on Azure. Once this is completed, you can publish to Azure.

Figure 6-6: Publish to Azure
At the end of the publishing procedure, Visual Studio will open the website with a browser, and if everything is fine, you should see your application running on Azure.
Publishing from Visual Studio is fine if you are just doing some tests, or for a one-off project. But if you are working on a project where you'll deploy multiple times, you might want to deploy via an automated process.
You could use the DevOps features of Azure, but you could also deploy directly from the command line by using the publish command.
First, you have to create a publishing profile as you would when deploying from within Visual Studio. Then, from the command line, you can type the following line (where WebProject.csproj is the name of your project and Azure is the name of your publishing profile):
dotnet publish WebProject.csproj /p:PublishProfile=Azure /p:Password=<passwordOmitted>
In this chapter, we discussed how easy it is to deploy ASP.NET Core applications on IIS on premises, and how it’s even easier to do it on Azure. No wonder everyone is now moving to the cloud.
Now that you’ve built an application with Visual Studio and deployed it for the world to see, the next chapter goes more in depth on how to build apps without Visual Studio.