Tuesday, 7 April 2020

Writing to Event Log in .Net Core (Tested with .Net Core 3.1)

Writing to the Event Log in .Net Core requires first a Nuget package installation
Install-Package Microsoft.Extensions.Logging.EventLog -Version 3.1.2
Note that the correct version to install depends on the version of .Net Core you are running.The package above was tested OK with .Net Core. Then we need to add EventLog. In the Program class we can do this like so:
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Logging.EventLog;

namespace SomeAcme.SomeApi
    public class Program
        public static void Main(string[] args)

        public static IHostBuilder CreateHostBuilder(string[] args) =>
                .ConfigureLogging((hostingContext, logging) =>
                    logging.AddEventLog(new EventLogSettings()
                        **SourceName = "SomeApi",
                        LogName = "SomeApi",**
                        Filter = (x, y) => y >= LogLevel.Warning
                .ConfigureWebHostDefaults(webBuilder =>
And our appsettings.json file includes setup:
  "ConnectionStrings": {
    "DefaultConnection": "Server=.\\SQLEXPRESS;Database=SomeApi;Trusted_Connection=True;MultipleActiveResultSets=true"
  **"Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
  "AllowedHosts": "*"
We can inject the ILogger instance
using SomeAcme.SomeApi.SomeModels;
using SomeAcme.SomeApi.Services;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Logging;
using System.Collections.Generic;

namespace SomeAcme.SomeApi.Controllers
    public class SomeController : ControllerBase
        private readonly ISomeService _healthUnitService;
        private readonly ILogger _logger;

        public SomeController(ISomeService someService, ILogger logger)
            _someService= someService;
            _logger = logger;
        // GET: api/Some
        public IEnumerable GetAll()
            return _someService.GetAll();

More advanced use, add a global exception handler inside Configure method of Startup class in .Net Core:
        //Set up a global error handler for handling Unhandled exceptions in the API by logging it and giving a HTTP 500 Error with diagnostic information in Development and Staging
        app.UseExceptionHandler(errorApp =>
            errorApp.Run(async context =>
                context.Response.StatusCode = 500; // or another Status accordingly to Exception Type
                context.Response.ContentType = "application/json";

                var status = context.Features.Get();

                var error = context.Features.Get();
                if (error != null)
                    var ex = error.Error;
                    string exTitle = "Http 500 Internal Server Error in SomeAcme.SomeApi occured. The unhandled error is: ";
                    string exceptionString = !env.IsProduction() ? (new ExceptionModel
                        Message = exTitle + ex.Message,
                        InnerException = ex?.InnerException?.Message,
                        StackTrace = ex?.StackTrace,
                        OccuredAt = DateTime.Now,
                        QueryStringOfException = status?.OriginalQueryString,
                        RouteOfException = status?.OriginalPath
                    }).ToString() : new ExceptionModel()
                        Message = exTitle + ex.Message,
                        OccuredAt = DateTime.Now
                    catch (Exception err)
                    await context.Response.WriteAsync(exceptionString, Encoding.UTF8);

And finally a helper model to pack our exception information into.

using System;
using Newtonsoft.Json;

namespace SomeAcme.SomeApi.Models
    /// Exception model for generic useful information to be returned to client caller
    public class ExceptionModel
        public string Message { get; set; }
        public string InnerException { get; set; }
        public DateTime OccuredAt { get; set; }
        public string StackTrace { get; set; }
        public string RouteOfException { get; set; }
        public string QueryStringOfException { get; set; }

        public override string ToString()
            return JsonConvert.SerializeObject(this);

The tricky bit here is to get hold of a logger inside the Startup class. You can inject ILoggerFactory for this and just do :

_logger = loggerFactory.CreateLogger();

Where _logger is used in the global error handler above. Now back again to the question of how to write to the event log, look at the source code for SomeController above. We inject ILogger here. Just use that instance and it offers different methods for writing to your configured logs. Since we added in the Program class event log, this happens automatically. Before you test out the code above, run the following Powershell script as administrator to get your event log source:
New-EventLog -LogName SomeApi -SourceName SomeApi
What I like with this approach is that if we do everything correct, the exceptions pops up inside the SomeApi source nicely and not inside the application event log (clutter IMHO).

Saturday, 4 April 2020

Deploying an SQL Express database in Azure Devops pipeline with YAML and generating and updating the database with migrate scripts using EF Core Code First tools

Here a full example of how I achieved running Integration tests using Sql Express in Azure Devops. I had to use the YAML based pipelines so I could use simonauner's approach using Chocolatey to install Sql Express. Make note that I had to install EF Core tools since I use .Net Core 3.1 in this pipeline. Also note that I generate an EF Code First migration SQL file on the fly so that the rigged SQL Express instance is filled with contents. Deploy SQL Express instance in Azure Devops, install and generate and run EF Code first migration sql script to update database with schema and seed data using EF Code First tools.

# ASP.NET Core (.NET Framework)
# Build and test ASP.NET Core projects targeting the full .NET Framework.
# Add steps that publish symbols, save build artifacts, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core

- feature/testability

  vmImage: 'windows-latest'

  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

- script: choco install sql-server-express
- task: NuGetToolInstaller@1

- task: VisualStudioTestPlatformInstaller@1
  displayName: 'Visual Studio Test Platform Installer'
    versionSelector: latestStable

- task: NuGetCommand@2
    restoreSolution: '$(solution)'

- task: DotNetCoreCLI@2
  displayName: Build
    command: build
    projects: '**/*.csproj'
    arguments: '--configuration Debug' # Update this to match your need

- script: 'dotnet tool install --global dotnet-ef'
  displayName: 'Generate EF Code First Migrations SQL Script Update script'

- script: 'dotnet ef migrations script -i -o %BUILD_ARTIFACTSTAGINGDIRECTORY%\migrate.sql --project .\SomeAcme\SomeAcme.csproj'
  displayName: 'Generate EF Code First Migrations migrate.sql'

- script: 'sqlcmd -S .\SQLEXPRESS -Q "CREATE DATABASE [SomeAcmeDb]"'
  displayName: 'Create database SomeAcmeDb in Azure Devops SQL EXPRESS'

- script: 'sqlcmd -i %BUILD_ARTIFACTSTAGINGDIRECTORY%\migrate.sql -S .\SQLEXPRESS -d SomeAcmeDb'
  displayName: ' Run migrate.sql on SQL EXPRESS in Azure Devops'

# PowerShell
# Run a PowerShell script on Linux, macOS, or Windows
- task: PowerShell@2
    targetType: 'inline' # Optional. Options: filePath, inline
    #filePath: # Required when targetType == FilePath
    #arguments: # Optional
    script: 'gci -recurse -filter *.dll' # Required when targetType == Inline
    #errorActionPreference: 'stop' # Optional. Options: stop, continue, silentlyContinue
    #failOnStderr: false # Optional
    #ignoreLASTEXITCODE: false # Optional
    #pwsh: false # Optional
    #workingDirectory: # Optional

- task: VSTest@2
  displayName: 'VsTest - testAssemblies'
    testAssemblyVer2: |
    vsTestVersion: toolsInstaller
    testFiltercriteria: 'Category=IntegrationTest'
    runInParallel: false
    codeCoverageEnabled: false
    testRunTitle: 'XUnit tests SomeAcme solution integration test starting'
    failOnMinTestsNotRun: true
    rerunFailedTests: false

Mocking HttpClient in .Net core 3 with Moq

I worked with HttpClient today and needed to write some unit tests. Here is how I did it. First off, we need to define an HttpClientFactory interface like this:
    public interface IHttpClientFactory
        HttpClient CreateHttpClient();
Your API code must then not directly create an http client, but pass in a IHttpClientFactory instance, allowing for tailored functionality such as mocking / unit testing. A default implementation could be:
  public class DefaultHttpClientFactory : IHttpClientFactory
            public HttpClient CreateHttpClient()
                return new HttpClient();
And a mock implementation using Moq then looks like this:

using Moq;
using Moq.Protected;
using System.Net;
using System.Net.Http;
using System.Threading;
using System.Threading.Tasks;

namespace SomeAcme.SomeApi.Test
    public class MockHttpClientFactory : IHttpClientFactory
        private HttpResponseMessage _httpContentMessage;

        public HttpClient CreateHttpClient()
            return new HttpClient(CreateMockedHttpMessageHandler());

        private HttpMessageHandler CreateMockedHttpMessageHandler()
            var handlerMock = new Mock<HttpMessageHandler>(MockBehavior.Strict);
                // Setup the PROTECTED method to mock
                // prepare the expected response of the mocked http call

                // Setup the PROTECTED method to mock
                // prepare the expected response of the mocked http call
            return handlerMock.Object;

        /// <summary>
        /// Set up the desired http response of unit tests
        /// </summary>
        /// <param name="statusCode"></param>
        /// <param name="responseJson"></param>
        public void SetHttpResponseMessage(HttpStatusCode statusCode, string responseJson)
            _httpContentMessage = new HttpResponseMessage
                StatusCode = statusCode,
                Content = new StringContent(responseJson)



        private HttpResponseMessage SetupHttpResponseMessage()
            if (_httpContentMessage != null)
                return _httpContentMessage;
            return new HttpResponseMessage()
                StatusCode = HttpStatusCode.OK,
                Content = new StringContent("[{'id':1,'value':'1'}]")
            }; //return default dummy implementation for easy green testing of HttpClient..
The key is to implement a mocked HttpMessageHandler which is then injected into the real HttpClient class. And also expose a method SetupHttpResponseMessage() allowing unit tests to specify desired http status code and json payload in the response. This is a very basic approach of unit testing HttpClient, so you can get code coverage of your HttpClient and related code in the application layer where your use it. Make sure you now inject the MockHttpClientFactory into your code and initialize it in your testse setting the SetupHttpResponseMessage. Tests should go a green again despite you actually use the HttpClient (with a mocked HttpMessageHandler) !