Logging to Application Insights in .NET 8.0 Azure Functions

[springcomp]

This PR adds a .NET8.0 lesson for logging to Application Insights.
It also adds a lesson for prerequisites to using .NET 8.0 for developing Azure Functions.

Addresses: #10

PR Checklist

• Prerequisites README.md is complete.
• Lesson README.md is complete.
• Source code is complete (one project with several exercises).
• Lesson Workspace is working (checked on Windows ✔️).
• Link to the lesson is added to tables in Root & Lessons READMEs.
• A CodeTour is available for each exercise in the lesson.
• The CodeTours are working in the lesson Workspace (check Win+macOS).
• A Build step is added to specific GitHub workflow (if applicable).
• GitHub issue is linked.

[marcduiker]

Thank you so much for adding a new lesson for .NET 8 @springcomp! It looks great. Can you add a GitHub workflow to build this lesson? It's similar to the .NET6 one

[springcomp]

Sure thing @marcduiker.

By the way, we have made extensive work in our office to understand exactly how logging works.
It turns out that we have found a few peculiarities that may be worthwhile to include in the lesson:

• appsettings.json is not found automatically on Linux App Services. Instead, we need to explicitely set the worker base path using code. Something like this (which will also work on Windows)

        var basePath = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
        config.SetBasePath(basePath!);
        config.AddJsonFile("appsettings.json", optional: true); // first read appsetting.json
        config.AddEnvironmentVariables(); // then override using App Settings or Environment Variables

Additionally, we found that overriding log levels using App Settings has limitations on Linux App Service Plans.
By default a logger category will be taken as the fully qualified name of the class, for instance, including the namespace.
The problem is that a category name with . (dot) character is not supported on Linux and the documented replacement with __ (double underscore) does not work either on such App Service Plans.

So our in-house recommendation is to use explicit logger categories without . (dot) in their names.

For instance, we forbid the following code:

    public class HelloWorldHttpTrigger
    {
        private readonly _logger ILogger;
        public HelloWorldHttpTrigger(ILogger<HelloWorldHttpTrigger> logger)
        {
            _logger = logger;
        }
        [Function("HelloWorldHttpTrigger")]
        public IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req,
            FunctionContext context
        )
        {
            var classLogger = context.GetLogger<HelloWorldHttpTrigger>();
            var funcLogger = context.GetLogger("An.Invalid.Name.With.Dot.Characters");
            …
        }

In contrast, we recommend the following code:

[Function("HelloWorldHttpTrigger")]
public IActionResult Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req,
    FunctionContext context
)
{
    ILogger _logger1 = context.GetLogger("HelloWorldHttpTrigger");
    ILogger _logger2 = context.GetLogger(nameof(HelloWorldHttpTrigger));
    _logger1.LogInformation("C# HTTP trigger function processed a request");
}

Finally, the official guidelines has two different syntax variants that I have not been able to explain away. In this lesson, I choose the IHostBuilder flavor.

Maybe some of these learnings need to make it to the lesson before we accept the pull request.

[springcomp]

FYI, the build is actually succeeding.
The failed check is due to an invalid link in the dotnet core 3.1 lesson on blobs.