Welcome to today’s post.
In today’s post I will discuss how to deploy changes to Web API applications from Visual Studio into Azure.
In previous posts I showed how to deploy ASP.NET .NET Core applications and Angular SPA applications to Azure App Service. In today’s post I will deploy a .NET Core Web API application to Azure using the Web publishing wizard within Visual Studio. Like normal web sites, web API applications are hosted and deployed to the same folder within a web server. The Azure App Service contains a subfolder folder \home\site\wwwroot where our application is deployed and hosted.
Once our application is deployed into the root folder of the Azure App Service, it keeps the same folder structure and configuration files that you have within the application’s project folder your local development environment. The only difference will be the settings within your configuration file that determine how your deployed application in the Azure App Service cloud environment integrates with other external services like cloud databases and other cloud services. These settings can be deployed with your project build configuration settings with a Production build context and the appSettings.production.json configuration file.
Following deployment, the API service will be accessible from an index.html landing page, and if we have configured Swagger for our API application, then the landing page will display the Swagger UI documentation displaying the application’s API service methods.
I will start off with an overview of a typical Web API application, then show how to deploy it into Azure.
A Typical Web API Application
A typical web API application is a non-user facing part of a system that consists of a library of methods. In ASP.NET Core, these web methods correspond to REST API calls to the web API. There are four common different verbs that are used to call a Web API method: SELECT, POST, PUT, and DELETE. These correspond to actions that allow us to select resources, post a resource, modify resource, or remove a resource. A resource can be data from a database or even a document.
A client web application that presents data to end-users does not have any references to server data on the browser it is running on, so it retrieves the data by first calling a web API service, then retrieves the results from the API response, which are in JSON format. Maps the JSON response to an object, such as a List, then outputs that to a page rendered as HTML.
Let me give a quick review of what a web API method looks like.
In the example below we have a HTTP GET API method within our API controller.
[HttpGet("api/[controller]/AllBooks")]
public async Task<List<BookViewModel>> AllBooks()
{
List<BookViewModel> bvm = new List<BookViewModel>();
var books = await _db.Books.ToListAsync();
return books;
}
After building and deploying our API to our localhost or even to IIS Express, we test it using POSTMAN:
The local IIS URL of our API HTTP GET method is:
http://localhost/BookLoan.Catalog.API/api/Book/AllBooksFollowing this test, we proceed to configure our API project to include an additional publishing profile to Azure App Service.
Generation of an Azure Web Application Publishing Profile
In our project, right-click and select Publish..
After selecting New Profile.. the following screen will show where we select App Service as our publishing target:
Choose Select Existing.
Select Advanced ….
You are asked to enter your Azure credentials.
Sign-in to Azure.
Select (or search for) the App Service from your subscription and resource group.
The publish summary page now shows.
In the publish summary page select Configure.
Validate the SCM connection to Azure is valid.
In the publish summary page select Settings.
Enter the Azure SQL database connection that your Web API will be using.
To obtain the connection string open the Azure SQL resource in the portal and obtain the value as shown:
The Azure SQL Server database connection is of the form:
Server=tcp:[database server name].database.windows.net,1433;Initial Catalog=[database name]; Persist Security Info=False;User ID=[user id]; Password=[pwd]; MultipleActiveResultSets=False; Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;Note: The connection string will NOT include the password, which you will need to provide.
Next save the setting and publish.
Publishing the Application to Azure
We next click on the Publish button.
After publishing completes the API will be shown within the Swagger UI with the API method we discussed earlier:
If our API controller or either of our API methods has the [Authorize] attribute then we will see a padlock security icon to its right. For more details on securing web API methods refer to one of my previous posts on JWT authentication.
As the above example uses an existing Azure App Service, you will need to create one before deployment. In most deployments you would deploy to a known App Service so that you could later remove the application resource from a script or reference the application in another system or part of the same project. If you had selected a new App Service with a generated name, then you could still remove the resource from within its Resource Group. Use of generated resource names would be typically used within an automated testing environment, where the automated deployments can be torn down cleanly after tests are completed. In situations where you are experimenting with Azure, then locating and removal of the resource after evaluation is essential to avoid unnecessary usage charges.
For details on how to create an App Service for a Web API within Azure, refer to my post Deploying Projects from GitHub Repo into Azure App Services.
As we have seen, there are a few different ways (and even more ways) to deploy our .NET Core Web API into Azure:
- Using the Web publishing wizard within Visual Studio
- Using deployment from a local Git repository
- Using a Docket image from a Docker Hub repository
Despite the deployment from Visual Studio to Azure being manual, the important observation here is that this process can be automated in the future. We could setup a scheduled deployment or a triggered deployment from a continuous build and integration tool, such as Azure DevOps that would execute a re-build of the solution, then deploy it to the destination. There is already a built-in continuous build process called Kudu, within Azure App Services that performs triggered builds of web applications that are linked to GitHub repositories. Once code is committed from the GitHub repository for an Azure Web Application, the Kudu process in Azure deploys the source and content changes to the web site and restarts the site. I explained how this works in a previous post where I showed how a Web API project was deployed following a commit from Visual Studio of code versioned within a GitHub repository.
The manual process in deployment is the first step that we take when we establish the parameters and artifacts that we require in the deployment. Once we have determined these, we can then proceed to configure an automated deployment that includes the configuration files and associated deployment parameters.
That’s all for this post.
I hope you found this post useful and informative.
Andrew Halil is a blogger, author and software developer with expertise of many areas in the information technology industry including full-stack web and native cloud based development, test driven development and Devops.
