Coding Azure 3: Creating an App Service for a Web Service

Your cloud-native app is going to need a Web Service. Here’s how to configure an App Service to hold that Web Service (and how to deploy it to the App Service from Visual Studio).

In my previous post, Coding Azure 2: Configuring an Azure SQL Database, I set up a cloud-native Azure SQL database and loaded it with some data. The next step in creating a three-tier microservice is to add a Web Service that will access that database. For a cloud-native solution, that Web Service will run inside an Azure App Service.

I should mention that the Azure team seems to use the two terms “App Service” and “Web App” interchangeably (or I can’t figure out the distinction). I’ll be using “App Service” except where the UI forces me to use “Web API.”

Creating the App Service

To start creating an App Service that will host a Web Service in Azure, surf to the Azure portal, type App Services in the search box in the middle of the top of the page, and click on App Services in the dropdown list to get to the App Services page. Then click on the + Create at the left end of the menu at the top of the page and select Web App to start the Create Web App wizard.

As usual, you’ll need to assign your App Service to a resource group and give it a name (the App Service’s name gets rolled into a URL so you can’t use spaces but, for an App Service, the UI will let you use uppercase letters—not that they make any difference). By default, the Wizard will automatically tack a random string at the end of the name to so the resulting URL is unique, but you can turn that off using the toggle switch right below your App Service’s name (I called my service warehouseappdb, for example, which turned out to be unique so I turned off the random string option).

The next group of settings will depend on what development platform you’re using and how you intend to deploy your application.

The first option (Code) lets you pick between loading the support stack for some development platform or a container (Container, which lets you, eventually, load a container holding the code for your Web Service and its support stack).

I don’t intend to load a container to this App Service, so I set the Code/Container radio button to Code. Picking the Code option displays the Runtime stack dropdown that lets you pick the support packages that will be loaded into my App Service. I picked .NET 8 because it matched the stack I’ll be using to create my Web Service.

If you pick the Container option, you won’t have to select a runtime stack. That will increase your costs (see below) and you’ll have to give up using remote debugging (which I’ll cover in an upcoming post). You’ll also have to configure your Visual Studio/Visual Studio Code project to generate your application in a container.

Regardless of which choice you made in the Code/Container option, you’ll need to pick your App Service’s operating system. Because I used the Code option, I picked Windows purely for practical purposes: While .NET runs on both Windows and Linux, I can’t enable remote debugging on an App Service that uses Linux unless I’m using .NET 6 or earlier. It also reflects the platform that I’m developing my Web Service on.

If you pick the Container option, then your operating system choice should be driven by the platform you’re developing on, but Visual Studio, at least, will let you develop on Windows and deploy to a Linux host.

I set the Region to the same region as the Azure SQL database I created in Part 2 to avoid any cross-region charges (Canada Central, in my case).

Following those selections are the ones that let you set how much processing power you’ll get (and, as a result, how much you’ll pay). Under Pricing Plan I clicked on Create New and, in the resulting, dialog, gave my plan a name.

Clicking Create New not only lets you set a name but also displays a dropdown list of available plans. For this sample application (and using the Code option), I selected the Free F1 plan which gives me 60 processing minutes a day to play with. In real life, you’ll want to pick something with more power. If you picked the Container option, the Free option isn’t available and you’ll have to pick from more powerful (and expensive) plans.

Picking the Free plan means that I can’t select Zone Redundancy (which will create failover copies of my App Service in another datacenter in the same region) or additional services that would automatically be deployed with my App Service. Those extra services include an Azure SQL database and a Redis cache (I’ll look at using a Redis cache later in this series). Picking Container will also let you select Zone redundancy which will copy your App Service to another data center in the same region enabling you to fallback to that copy if you have a data center failure.

On the other tabs:

• Container tab:

  • This will only appear if you selected the Container option earlier on. If you want to use an image from your own registry, select the appropriate source from the Image source (Azure Container Registry, Docker Hub or a private registry) and then pick your image from the registry.

• Deployment tab:

  • This will only appear if you picked the Code option. The free plan that I picked doesn’t support enabling Continuous deployment or integration with GitHub. If you’re keeping your source code in GitHub, you can enter your repo’s information here and review the workflow that will deploy your branch (I’m going to deploy my sample app straight from Visual Studio so I didn’t mind losing these options).

  • I left Basic authentication disabled just to simplify deploying from Visual Studio.

• Networking tab:

  • I left Enable public access set to On so that I can test my service just by surfing to it. You should too, to facilitate creating your app. In real life you’ll eventually want to disable this in your production environment so that the service can only be accessed from the application’s frontend.

  • The free service plan doesn’t let me Enable network injection, which would let me attach my service to a Virtual Network and take advantage of the security features of a VNet. I didn’t miss that because, in focusing on a cloud-native solution, I wanted to secure my app without using features that smacked of a physical data center.

• Monitoring + Secure Tab:

  • I disabled Application Insights because I didn’t want to incur any associated charges. In real life, you’ll probably (eventually) want to enable Application Insights in your development, test and production App Services, but only when you have a problem to track down.

  • I didn’t enable Microsoft Defender for the same reason that I didn’t enable Application Insight, but you should almost certainly enable it for your production App Service.

Deploying to Your App Service from Visual Studio

To deploy your Web Service from Visual Studio, you need to create a Publish profile (in a later post, I’ll cover how to deploy from Visual Studio Code). To start creating a Publish profile:

1. First, start Visual Studio and create a Visual Studio project (I used the ASP.NET Core Web API template, called my project WarehouseMgmtService, and—other than setting my Framework to .NET 8.0—took all the defaults on the Additional information page).

2. From Visual Studio’s Build menu, select Publish <project name> to display the Publish tab.

3. If this is your first profile from that dialog’s Target list, click on the Azure choice to select it. (If this isn’t your project’s first profile, then, from the menu across the top of the panel on the right, click on + Create tab and then select Azure from the Target list.)

4. Click the Next button at the bottom of the dialog to display the Specific Target tab.

5. On the Specific Target tab, you need to select a target that matches the App Service you created. In my case, because I selected the Code option when configuring my App Service, I selected the Azure App Service (Windows) target. (If you chose to use a container with your App Service, then you’ll want to select App Service Container for the platform—Windows or Linux—that you selected.)

6. Click the Next button to move to the App Service page.

7. On the App Service tab, you’ll need to drill down to which Azure App Service you want to deploy your Web Service to (the list is organized either by resource group or Web Apps and limited to services that match the template you selected on the previous tab). In my case, the App Service I want is my WarehouseMgmtService in my WarehouseMgmt resource group.

8. Click the Next button at the bottom of the dialog to go to the API Management page.

9. Right now, I’m not going to use API Management, so I checked the Skip this step checkbox at the bottom of the dialog.

10. Click the Finish button to create your Publish profile and the Close button to return to Visual Studio and display your profile.

If you want to start using API Management, then, before clicking the Finish button, you can either select an existing Web API resource from the list or click the + Create new button to create a Web API. (If you picked the Container option, you may get a message about increasing your admin privileges on your registry.)

Before you use the profile though, let’s recognize that you’ll be needing to debug your Web Service (nothing ever works the first time). To support that, modify your Publish profile to deploy a debug build: In your publish profile, click on the pencil icon beside the Configuration’s Release setting and, in the following dialog, set the Configuration dropdown list to Debug before clicking the Save button.

In the long run, you’ll probably want two publish profiles: One that deploys to a “development” App Service with a debug build and a second profile that deploys to a staging/testing App Service (or a deployment slot in a product App Service) with a release build.

Deploy Your Web Service

Now that you’ve created a Publish profile, you can use it: Back in Visual Studio, with your profile displayed, click that profile’s Publish button to deploy the skeleton of your Web Service to your App Service.

Your app will be deployed to your service and, if your App Service is running, Visual Studio will open a browser window and request the service at your App Service’s URL. That will generate an error page with an HTTP 404 error … which is sort of disappointing.

That initial error 404 occurs because the publish process requests the Web Service using the App Service’s base URL (https://<app service>.azurewebsites.net/) and the template’s base service is (currently) at https://<app service>.azurewebsites.net/weatherforecast. Change the URL to the default service specified in your Program.cs file and you should get back your default output.

Resetting an App Service

In general, you should find that, as you make modifications to your application, you can repeatedly deploy it into its App Service without a problem. However, it’s possible to make sufficient changes to render your App Service unusable (you’ll get the message “HTTP Error 500.30 - ASP.NET Core app failed to start”). It’s not easy but, for example, in an App Service using .NET App Services, replacing an ASP.NET Core app configured for Razor Pages to one configured for MVC/controllers-with-views will sometimes do it.

For an App Service running a .NET app, you can fix the problem by deleting all the files in the App Service:

1. In your App Service’s menu on the left, expand the Development Tools node.

2. Select the Console node to open a console window on the right, with the prompt set to C:\home\site\wwwroot.

3. Delete all the files in the folder with:

del *.* /s /q

4. Republish your app to the App Service.

Next Steps

In a later post in this series, I’ve got the steps for deploying to an App Service from Visual Studio Code (feel free to skip ahead once that’s published). In my next post, however, I’m going to cover how to create a Web Service that will be able to talk to my Azure SQL database. Keep coming back, as they say.