Deploy a .NET Core 8 application to Azure with Logging

I’ve been working with Microsoft Azure for a little while now, and I have found that setting up the logs weren’t trivial.

I had a similar experience with WordPress. In this article, I’ll demonstrate it’s actually easy with a .NET Core 8 web API.

Prerequisites

You’ll need:

• An account on Microsoft Azure. Personally, I have only a work account through my current employer at the time of this writing. So I had a few issues to have the resources to work together or to gain permissions to perform some actions. I’ll detail them as we go.
• Visual Studio 2022, at least, that’s what I used to make this guide. You’ll need to connect your account so you can deploy through the Publish feature within Visual Studio. This article won’t show how to set up a CI pipeline through Azure DevOps and deploy a Docker image. Please read my other guide on the topic where I deployed a Python web API to Microsoft Azure.
• An App Service Plan: if you don’t have any, there isn’t any challenge about this. You’ll create it along with the App Service later in the article.

Creating the web API

First, let’s create the application locally.

In Visual Studio, create a new project of type “ASP.NET Core Web Api” and provide the following details:

• Give it a name
• Select the target framework. Though .NET 9.0 is just out as I write this, I’ll prefer the current LTS version which .NET 8.0.
• Select no authentication type. We’ll deal with this through OpenIddict in a later article. Subscribe to know more when I release the article.
• Check the Configure for HTTPS option.
• Uncheck the Enable container support option.
• Decide if you want to use Swagger to document your web API with the Enable OpenAPI Support option*.* In the article, it’s off topic.
• Check Use controllers option.
• Leave the rest as it is.

By default, it will create an application with a WeatherForecast controller.

Check that it works through the right-click menu and Debug > Start new instance.

Create the App Service

Before we deploy, we need to create where the application will run.

Go to the Azure portal (https://portal.azure.com/) and using the main search bar at the top, type and select “App Services”.

On the loaded page, you’ll see all the existing App Services on your subscription or Resource Group.

Select Create and then Web App.

Under the Basics tab, you will need to input:

• The resource group.
• The name of the resource.
• The Publish type to Code.
• The Runtime stack to .NET 8 (LTS)
• The Operating system to Linux
• The Region (Note: I selected the same as the other resources, because I had an existing App Service Plan to avoid the creation (and costs) of a new one)
• The Linux plan. If you have an existing plan, Azure will list it for you. Otherwise, click Create new.

Under the Deployment tab, check the Basic authentication to Enable for Authentication settings.

Leave the tabs Database and Networking with the defaults. The database is created separately when we’ll prepare the OpenIddict integration. Subscribe to know more when I release the article.

Under the Application Insights, leave it as it’s because, even if it can be interesting, it isn’t how you tell Azure where the application logs will go.

Under the Tags tab, set the tags to organize your resource. You should have a strategy to sort and organize your resources. But that’s a topic for another article.

Finish with Review + create and confirm the resource creation.

Deploy the Application to Microsoft Azure

Now, let’s deploy the application to the newly created App Service.

Right-click on the project and select Publish.

You’ll need to create a publish profile, so click Add a publish profile.

On the modal,

• Select Azure as the Target.
• Select Azure App Service (Linux) as the Specific target
• Select the App Service you just created. You need to be connected in Visual Studio to the same account you used to create the resource in Azure. Otherwise, you won’t see it.
• Select Publish (generates pubxml file) as the Deployment type.

Close the modal and hit Publish.

After a couple of minutes, the application should be deployed to Azure. Use the Overview blade of the App Service on Azure to browse the Web API: it should be something like demoweb APInetcore8-fcg3bqdgbme3dchd.westeurope-01.azurewebsites.net. Add /weatherforecast to validate the API is working.

Enable the Application Logs to the FileSystem

On the Azure portal, browse your App Service resource and search for the App Service Logs blade.

Enable the Application logging to File System and set the Retention Period to 7 days.

Save the changes.

To check it’s working, search for the Advanced Tools blade and click Go.

In the new browser tab that opened, select the Bash tab to load an SSH client, also known as the Kudu.

Type the following command:

1

ls -l LogFiles

You should see a file named yyyy_mm_dd_[some_hash_value]_default_docker.log. This is where the logs you add in your application will go.

Regarding the LogStream

You may have come across YouTube video or articles that tells you that you can view the logs live in the LogStream. Maybe it was possible or is still possible in certain conditions. I find that it isn’t reliable. I’ve tried many things and it often remains stuck with the message “Connected!”…

Modify Program.cs to Add Your First Log

First, before your instantiate the builder, add the following lines:

1
2
3
4
5
6
7
8
9

using var loggerFactory = LoggerFactory.Create(loggingBuilder => loggingBuilder
    .SetMinimumLevel(LogLevel.Trace)
    .AddConsole());

ILogger logger = loggerFactory.CreateLogger<Program>();
logger.LogInformation("Program.cs logger ready :)");

logger.LogInformation("Program.cs > init builder...");
var builder = WebApplication.CreateBuilder(args);

This way, you can debug errors while your application starts.

Let me tell you how important it’s when it will come to debug the OpenIddict integration (well, for you, it might not if you follow exactly the same steps as I describe here).

To test this, hit Publish again and wait that the App Service restarts. In the log file, you should see the two lines of log near the end of the file:

1
2
3
4
5

cat LogFiles/yyy_mm_dd_[some_hash_value]_default_docker.log
# 2024-12-10T10:37:19.5210376Z info: Program[0]
# 2024-12-10T10:37:19.5211218Z       Program.cs logger ready :)
# 2024-12-10T10:37:19.5366643Z info: Program[0]
# 2024-12-10T10:37:19.5366935Z       Program.cs > init builder...

Modify WeatherForecastController.cs to Add a Log

In the controller file, use dependency injection to use the logger:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

        private readonly ILogger<WeatherForecastController> _logger;

        public WeatherForecastController(ILogger<WeatherForecastController> logger)
        {
            _logger = logger;
        }

        [HttpGet]
        public IEnumerable<WeatherForecast> Get()
        {
            _logger.LogInformation("Getting the forecast...");
            // Business logic...
        }

To test this, hit Publish again and wait that the App Service restarts. Request the /weatherforecast endpoint and check the logs as described above.

Conclusion

That’s it. I’ve longed so much to understand where those log files where. Somehow, the articles and vlogs on the Web show outdated information and this article is what you may be looking for.

Again, please subscribe to know more when I release the article about integrating OpenIddict to the application.

Credit: Photo by Craig Adderley on Pexels.