In bestimmten Projekten ist es notwendig, auch in der lokalen Entwicklungsumgebung HTTPS zu verwenden, zum Beispiel, wenn das Angular-Frontend mit einem ASP.NET Core Backend kommuniziert, das HTTPS voraussetzt, oder wenn Funktionen wie Secure Cookies, OAuth2 oder CORS mit "secure"-Kontext getestet werden sollen.

Visual Studio erleichtert dies, indem es beim ersten Start eines ASP.NET Core Projekts automatisch ein selbstsigniertes Entwicklungszertifikat erzeugt und es dem Zertifikatspeicher des aktuellen Benutzers als vertrauenswürdig hinzufügt. Dieses Zertifikat lässt sich auch für den Angular Development Server (ng serve) nutzen, um dort SSL zu aktivieren.

Voraussetzungen

• Windows 11
• PowerShell 7 oder höher installiert
• Ein ASP.NET Core Projekt wurde bereits mit Visual Studio gestartet (damit das Dev-Zertifikat erzeugt wurde)

Schritt 1: Entwicklungszertifikat exportieren

Damit das Angular CLI das Zertifikat nutzen kann, muss das Zertifikat als key.pem und cert.pem exportiert werden. Dies geschieht am einfachsten per PowerShell:

PowerShell-Skript: Exportiere ASP.NET Core Development-Zertifikat

$ErrorActionPreference = 'Stop';

# Zielpfade
$exportPath = 'C:\DEIN-PROJEKLT\certificates';
$keyPath = Join-Path $exportPath 'key.pem';
$certPath = Join-Path $exportPath 'cert.pem';

Write-Host 'Entwicklungszertifikat ermitteln';

# Thumbprint des Zertifikats abrufen
# Es handelt sich dabei um einen Fließtext
$certsCheckOutput = dotnet dev-certs https --check;

# Regex zum extrahieren des Fingerprint
$thumbrint = [regex] ': ([\w]+) -';
$certificateIdMatch = $thumbrint.Matches($certsCheckOutput);


if($certificateIdMatch.Groups.Length -eq 0) {
    Write-Error 'Entwicklungszertifikat-Fingerprint konnte nicht ermittelt werden';
    return 1;
}

Write-Host "Entwicklungszertifikat laden"

# Id des Zertifikates
$certificateId = $certificateIdMatch.Groups[1];

Write-Host "ID: $certificateId"

# Zertifikat abrufen
$cert = Get-ChildItem -Path Cert:\CurrentUser\My |
    Where-Object { $_.HasPrivateKey -and $_.Thumbprint -eq $certificateId } |
    Sort-Object NotAfter -Descending |
    Select-Object -First 1

if(!$cert) {
    Write-Error 'Es wurde kein Entwicklungszertifikat gefunden für $certificateId';
    return 1;
}

Write-Host "Zertifikat gefunden: $($cert.Subject)"

Write-Host 'Zertifikate erstellen'

# Privaten Key lesen
$RSACng = [System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAPrivateKey($cert);

# Zertifikate erstellen
$RSACng.ExportPkcs8PrivateKeyPem() | Set-Content -Path $keyPath -Encoding ascii
Write-Host "Zertifikat $keyPath wurde erstellt"

$cert.ExportCertificatePem() |  Set-Content -Path $certPath -Encoding ascii
Write-Host "Zertifikat $certPath wurde erstellt"

Schritt 2: Angular Dev Server mit SSL starten

Der Angular Dev Server kann mit den Parametern --ssl, --ssl-key und --ssl-cert gestartet werden.

ng serve  --ssl --ssl-key certificates/key.pem --ssl-cert certificates/cert.pem

FAQ

Was passiert, wenn ich kein Zertifikat sehe?
Starte ein beliebiges ASP.NET Core Projekt in Visual Studio, das HTTPS nutzt. Visual Studio erzeugt dann automatisch ein Entwicklungszertifikat.

Alternative kann der Befehl dotnet dev-certs https --trust ausgeführt werden.

In dem Artikel "ASP.NET Core 8: IExceptionHandler für APIs" wurde die Fehlerbehandlung durch Exception Handling präzisiert. Unter Entwicklern ist die Methode der Fehlerbehandlung ein intensiv diskutiertes Thema.

Es gibt drei Varianten der Fehlerbehandlung. Eine davon ist die Rückgabe von Null bei einem Funktionsaufruf, was nur angewendet werden sollte, wenn der Fehler klar definiert ist, wie zum Beispiel beim Laden eines Datensatzes aus der Datenbank (vorhanden/nicht vorhanden).

public Task<object?> GetCompanyAsync(Guid id) {
  return Repository.GetOrDefaultAsync(id);
}

Die zweite Methode ist das Auslösen von Ausnahmen (Exceptions). Auf vielen Plattformen wird davon abgeraten, Exceptions zu verwenden, insbesondere wenn sie dazu dienen, den Programmfluss zu steuern.

Zum Beispiel wird anstelle der Verwendung von File.Exists versucht, die Datei zu öffnen, und im Falle einer Ausnahme wird der Pfad zur Erstellung der Datei verfolgt.

Ein Punkt, den ich noch nicht geprüft habe, ist die Leistung. Es wird behauptet, dass das Auslösen von Ausnahmen zeitaufwendig ist.

public void CancleTicket(Ticket ticket) {
  if(ticket.state != 0) {
    throw new Exception("Ticket muss zum stornieren geöffnet sein.");
  }
}

Eine dritte Methode zur Fehlerbehandlung ist das Result-Pattern.

Result-Pattern

Das Result-Pattern gibt den Fehler als Rückgabewert weiter. Dazu sind zunächst grundlegende Klassen erforderlich.

public sealed record Error(string? Code, string Description)
{
  public static Error NotFound(object id) => new Error("404", $"Entity with Id {id} not found");
}

public class Result
{
    protected Result(bool isSuccess, Error? error)
    {
        if (isSuccess ^ error == null)
        {
            throw new ArgumentException("Invalid error", nameof(error));
        }

        IsSuccess = isSuccess;
        Error = error;
    }

    public bool IsSuccess { get; }

    public bool IsFailure => !IsSuccess;

    public Error? Error { get; }

    public static Result Success() => new(true, null);

    public static Result Failure(Error error) => new(false, error);
}

public class Result<TValue> : Result
{
    protected Result(TValue value, bool isSuccess, Error? error) : base(isSuccess, error)
    {
        Value = value;
    }

    public TValue Value { get; }

    public static Result Success(TValue result) => new Result<TValue>(result, true, null);

    public static Result Failure(TValue result, Error error) => new Result<TValue>(result, false, error);
}

Anschließend können die zuvor erwähnten Klassen eingesetzt werden.

public Result CancleTicket(Ticket ticket) {
  if(ticket.state != 0) {
    return Result.Failure(new Error(null, "Ticket muss zum stornieren geöffnet sein."));
  }
}

Für Asp.Net Core muss die genannte Implementierung angepasst werden. Bei Minimal APIs können Werte durch statische Methoden in Results (IResult) zurückgegeben werden, wodurch ein entsprechender HTTP-Statuscode generiert wird. Bei einer eigenen Implementierung müssen die Statuscodes manuell zugeordnet werden.

Bestehende Bibliotheken

Bei einfachen Implementierungsaufgaben, die nur wenige Stunden in Anspruch nehmen, bevorzuge ich es, diese selbst durchzuführen. Die Verwendung externer Bibliotheken kann das Risiko von Angriffen und Abhängigkeiten erhöhen. Dennoch möchte ich hier zwei Bibliotheken erwähnen.

• DomainResult
• FluentResults

Seit der ersten Version von .NET Core bin ich dabei und habe die Verbesserungen während der Entwicklung erlebt.

Derzeit plane ich eine neue Basis für mein System und überprüfe daher regelmäßig verschiedene Teilbereiche und deren Lösungen in den neueren .NET Core-Versionen. Eine dieser Verbesserungen ist das Exception Handling.

In diesem Beitrag unterscheide ich zwei Arten von Fehlern: Systemfehler und Logikfehler. Systemfehler umfassen unerreichbare Systeme wie Datenbanken, Caches oder externe Dienste sowie Programmierfehler. Logikfehler hingegen stehen im Zusammenhang mit der Geschäftslogik. Zum Beispiel, wenn ein Benutzer versucht, ein bereits storniertes Ticket zu stornieren, ohne die nötigen Berechtigungen zu haben.

Bei Systemfehlern sollten keine Details preisgegeben werden. Ist beispielsweise der SQL Server nicht erreichbar, sollte der Nutzer höchstens erfahren, dass es ein Datenbankproblem gibt, ohne weitere Einzelheiten. Die Weitergabe von Fehlermeldungen könnte sonst die Adresse des SQL-Servers, den Datenbanknamen und möglicherweise den Benutzernamen offenlegen, was ein Sicherheitsrisiko darstellt. Diese Daten müssen daher bereinigt werden.

Bei Logikfehlern sollte der Benutzer hingegen mehr Informationen erhalten. Wenn ein Benutzer versucht, ein storniertes Ticket zu stornieren, sollte ihm mitgeteilt werden, dass dies nicht möglich ist. Im Idealfall sollte auch die fehlende Berechtigung angezeigt werden.

Umsetzung

Das zuvor erwähnte anzeigen von Server-Details, einschließlich der SQL-Verbindungsdaten, müssen etwas präzisiert werden. Asp.Net Core unterscheidet zwischen drei Umgebungen: Development, Stage und Production. Das Verhalten der Anwendung variiert je nach Umgebung. Ist die Umgebung auf Production eingestellt, werden keinerlei Informationen angezeigt, nicht einmal der Text der Ausnahme.

Vor .Net Core 8

In ASP.NET Core vor Version 8 konnten Fehler mittels Middleware abgefangen werden. Dabei wurde eine Middleware mit einem Try-Catch-Block implementiert, wobei die Fehlerbehandlung im Catch-Teil erfolgte.

public class ExceptionHandlingMiddleware(RequestDelegate next)
{
    public async Task InvokeAsync(HttpContext context)
    {
        try
        {
            await next(context);
        }
        catch (Exception ex)
        {
            ILogger<ExceptionHandlingMiddleware> logger = context.RequestServices.GetRequiredService<ILogger<ExceptionHandlingMiddleware>>();

            logger.LogError(ex, "An unexpected error occurred");

            ProblemDetails problemDetails = new()
            {
                Status = StatusCodes.Status500InternalServerError,
                Type = ex.GetType().Name,
                Title = "An unexpected error occurred",
                Detail = ex.Message,
                Instance = $"{context.Request.Method} {context.Request.Path}"
            };

            context.Response.StatusCode =
                StatusCodes.Status500InternalServerError;

            await context.Response.WriteAsJsonAsync(problemDetails);
        }
    }
}

app.UseMiddleware<ExceptionHandlingMiddleware>();

IExceptionHandler

In Asp.Net Core 8 wurde mit dem IExceptionHandler eine neue Methode zur Fehlerbehandlung eingeführt.

public interface IExceptionHandler
{
    ValueTask<bool> TryHandleAsync(HttpContext httpContext, Exception exception, CancellationToken cancellationToken);
}

public class DefaultExceptionHandler(ILogger<DefaultExceptionHandler> logger) : IExceptionHandler
{
    public async ValueTask<bool> TryHandleAsync(HttpContext context, Exception exception, CancellationToken cancellationToken)
    {
        logger.LogError(exception, "An unexpected error occurred");

        await context.Response.WriteAsJsonAsync(new ProblemDetails
        {
            Status = StatusCodes.Status500InternalServerError,
            Type = exception.GetType().Name,
            Title = "An unexpected error occurred",
            Detail = exception.Message,
            Instance = $"{context.Request.Method} {context.Request.Path}"
        });

        return true;
    }
}

  builder.Services.AddExceptionHandler<DefaultExceptionHandler>();
  builder.Services.AddProblemDetails();

   app.UseExceptionHandler();

Verkettung (Chaining)

ExceptionHandler können miteinander verkettet werden, indem der Rückgabewert der Funktion genutzt wird: true bedeutet, dass der Fehler behandelt wurde, und false, dass der Fehler nicht behandelt wurde und ein anderer ExceptionHandler eingreifen muss.

Dies bietet den Vorteil, dass Bibliotheken eigene ExceptionHandler für ihre spezifischen Exceptions bereitstellen können.

Es kann vorkommen, dass neue nützliche Funktionen auftauchen und einem unbemerkt bleiben. In diesem Fall bin ich kürzlich auf den DNS-Record HTTPS gestoßen, der in RFC9460 beschrieben wird.

Jeder Webentwickler kennt das leidige Thema der Umleitung von HTTP auf HTTPS. Wenn ein Besucher die Domain eingibt, wie zum Beispiel carnucci.de, wird zuerst die Webseite über HTTP aufgerufen. Um auf HTTPS umzuleiten, muss der Webserver oder Proxy entsprechend konfiguriert sein. Das führt zu unnötigem Traffic und Wartezeit sowie einer Verschwendung von Ressourcen. Früher wurde dieses Problem mit Add-ons in den Browsern gelöst. Doch dazu musste jedes Add-on erst installiert werden, was die Angriffsfläche erhöht.

Nun kommt der neue DNS-Record HTTPS ins Spiel. Mit diesem Record kann angegeben werden, dass die Webseite über HTTPS erreichbar ist. Der Browser fragt den Record ab und verbindet sich direkt über HTTPS mit der Webseite. Die Umleitung von HTTP auf HTTPS auf dem Webserver wird dadurch überflüssig. Allerdings sollte man nach dem Eintrag des HTTPS-Records die Konfiguration nicht einfach löschen. Es kann noch einige Zeit dauern, bis alle Besucher einen Browser verwenden, der den HTTPS-Record unterstützt.

Die Frage ist nun, welche DNS-Server den neuen Record unterstützen. Es dürfte nur eine Frage der Zeit sein, bis alle Server den Eintrag unterstützen. Cloudflare setzt den Eintrag automatisch, sobald HTTP/2 und HTTP/3 für eine Zone aktiviert sind. Zu Windows Server habe ich leider keine Informationen gefunden, aber ich vermute, dass er erst in einer neueren Version unterstützt wird.

Einleitung

Im Rahmen meiner Seminararbeit "KI in der Pflege" für meinen Masterstudiengang in Wirtschaftsinformatik habe ich erneut mit ML.NET gearbeitet. Named Entity Recognition (NER) ist eine Komponente der natürlichen Sprachverarbeitung (NLP), die vordefinierte Objekte oder Schlüsselwörter in einem Text identifizieren kann. Diese Tokens umfassen Personennamen, Organisationen, Orte, medizinische Codes, Zeitangaben, Mengenangaben, Geldwerte und vieles mehr. Kurz gesagt ermöglicht NER die Extraktion von Informationen aus einem Text, was insbesondere dann nützlich ist, wenn Personen Freitexte eingeben und bestimmte Informationen für spezifische Zwecke benötigt werden.

Leider sind viele Anleitungen zur Entwicklung von KI-Anwendungen auf Python ausgerichtet. Obwohl PyTorch und TensorFlow leistungsstarke Tools und Frameworks für Python bieten, möchte Microsoft mit ML.NET .NET-Entwicklern die Möglichkeit geben, KI-Anwendungen zu entwickeln und dabei im gleichen Ökosystem zu bleiben. Auf diese Weise kann die KI in C# trainiert und unter anderem in ASP.NET Core verwendet werden.

Durch AutoML und das Model Builder UI wird die Entwicklung von KI-Modellen vereinfacht. Es stehen verschiedene Algorithmen und Einstellungen zur Verfügung. AutoML sucht automatisch den besten Algorithmus für eine spezifische Aufgabe. Der Model Builder stellt eine grafische Benutzeroberfläche (GUI) in Visual Studio bereit, um eine KI zu trainieren. Dort kann die Art der KI (Klassifizierung, Regression, Objekterkennung, NER usw.) ausgewählt werden, und anschließend können die Datenquelle und die Trainingseinstellungen festgelegt werden.

Anwendungsszenario

In unserem IT-Systemhaus in Dortmund ist ein Hauptbestandteil meiner Arbeit die Programmierung eines Ticketsystems. Unser Ziel ist es, die Probleme unserer Kunden so schnell wie möglich zu lösen. Um eine effiziente Organisation zu gewährleisten, erfassen wir alle Vorfälle in einem Ticketsystem. Kunden haben die Möglichkeit, eigene Tickets zu erstellen oder uns per E-Mail zu kontaktieren.

Die Nutzung von Named Entity Recognition (NER) könnte besonders bei der Verarbeitung von E-Mails von Vorteil sein. Durch NER könnten relevante Informationen wie Gerät, Ansprechpartner und Standort aus den E-Mails extrahiert werden, um daraus automatisch ein entsprechendes Ticket anzulegen.

NER

Es gibt leider kaum Anleitungen für NER in ML.NET. Auf der Microsoft-Dokumentationsseite wird lediglich knapp der Aufbau der benötigten Daten beschrieben, ansonsten finde ich dazu nichts.

Bei mir war der mitgelieferte ML.NET Model Builder nicht auf dem neuesten Stand, daher musste ich die aktuellste Version von der Website herunterladen.

Anschließend konnte ich NER (Szenario) zum Trainieren auswählen. Die Bedienung des Fensters wird ebenfalls dort beschrieben.

Nachdem NER ausgewählt wurde, müssen zwei Dateien angegeben werden: die Entity Key Map und die Trainingsdaten.

Die Entity Key Map ist eine Liste mit den Objekten/Labels.

Device
Person
Priority

Bei den Trainingsdaten handelt es sich um eine Liste von Sätzen und den oben genannten Objekten. Die erste Spalte repräsentiert den Satz, während die anderen Spalten die jeweiligen Objekte enthalten. Die Spalten sind durch Tabs getrennt. Ein vollständiges Beispiel kann aus dem offiziellen Repository von ML.NET auf GitHub entnommen werden.

Joseph hat Probleme mit dem Gerät dc-de-un-66. Die Anmeldung ist nicht mehr möglich. Es ist wichtig.	Person	0	0	0	0	0	0	Device	0	0	0	0	0	0	0	0	Priority
Chantal hat Probleme mit dem Gerät adfs-us-un-34. Die Anmeldung ist nicht mehr möglich. Es ist unwichtig.	Person	0	0	0	0	0	0	Device	0	0	0	0	0	0	0	0	Priority

Zuerst habe ich die Daten in Excel erstellt und als TXT-Datei mit Tab-Abständen gespeichert. Jedoch konnte der Model Builder die Datei nicht einlesen. Nachdem ich die Daten anschließend in Notepad erstellt habe, konnte sie erfolgreich eingelesen werden. Wenn Umlaute verwendet werden, muss die Datei als UTF-8 gespeichert sein.

In der Vorschauversion von ML.NET habe ich gesehen, dass auch das Zuweisen eines Labels zu einer Wortgruppe gelöst wurde. Eine Wortgruppe könnte beispielsweise "Max Mustermann" sein. Dabei handelt es sich um eine Person und der Name besteht aus zwei Wörtern. In der Entity Key Map werden "B_Person" und "Person" hinzugefügt. Im Entity Key Map erhält das erste Wort das Label "B_Person" und alle darauf folgenden Wörter, die zum selben Label gehören, das Label "Person".

Fazit

Bisher hatte ich immer gute Erfahrungen mit ML.NET und dem Model Builder gemacht, abgesehen von einigen kleineren Fehlern. Diesmal war es jedoch anders. Trotz mehrerer Versuche konnte ich kein positives Ergebnis erzielen. Ich habe es sowohl mit 20.000 generierten Zufallssätzen als auch mit den Test-Trainingsdaten von GitHub versucht. Leider ohne Erfolg.

Auf dem Bild ist deutlich zu erkennen, dass das Label falsch zugewiesen wird und das Label "Priorität" überhaupt nicht erkannt wird. Interessant ist, dass "Chantal" erkannt wird, aber "hat" das Label "Person" erhält. Zunächst dachte ich, dass es sich um einen Anzeigefehler im Model Builder handelt, aber das gleiche Ergebnis erhielt ich auch im Programmcode.

Meine Vermutung ist, dass das Tool sich noch in der Beta-Phase befindet und daher noch nicht einwandfrei funktioniert. Zudem wird nach meinen Informationen ein vortrainiertes Modell (BERT) verwendet. Es ist wahrscheinlich darauf ausgelegt, eher für die englische Sprache als für Deutsch zu funktionieren.

Ein alternativer Ansatz könnte darin bestehen, den NerTrainer direkt zu verwenden, ohne den Model Builder einzubeziehen. Möglicherweise liegt der Fehler dort und nicht am Algorithmus.

In bestimmten Situationen ist es notwendig, eine Assembly zu initialisieren. Beispielsweise, um statische Werte zuzuweisen, Überprüfungen durchzuführen oder Schriftarten zu laden. Ein Beispiel wäre der Aufruf von BsonClassMap.RegisterClassMap aus dem MongoDB SDK oder das Setzen des Werts für QuestPDF.Settings.License in QuestPDF. Um diese Initialisierung automatisch durchzuführen, kann das Attribut ModuleInitializer verwendet werden. Dieses Attribut kennzeichnet Methoden, die vor jedem anderen Code (z. B. Typinitialisierer oder statische Konstruktoren) in der gesamten Assembly ausgeführt werden. Es wurde mit C#9 eingeführt. Die Anforderungen an eine solche Initialisierungsmethode sind¹:

• Sie muss statisch sein.
• Sie darf keine Parameter haben.
• Sie muss void zurückgeben.
• Sie darf nicht generisch sein.
• Sie darf nicht in einer generischen Klasse enthalten sein.
• Sie muss aus der enthaltenden Assembly zugänglich sein (d. h. die Methode und ihre enthaltende Klasse müssen internal oder public sein).

Das Attribut ModuleInitializer ermöglicht es somit, Initialisierungsmethoden automatisch aufzurufen, ohne dass ein expliziter Aufruf erforderlich ist.

using System.Runtime.CompilerServices;
class Init
{
    [ModuleInitializer]
    internal static void Initialisierung()
    {
        // ...
    }
}

Nachteile

Die Verwendung von ModuleInitializer in C# bietet zwar Vorteile, aber es gibt auch einige Nachteile.

1. Nachvollziehbarkeit geht verloren:
   • Bei ModuleInitializer wird die Assembly initialisiert ohne direkten Aufruf, andere Entwickler können dies nicht direkt einsehen und somit übersehen.
   • Dies kann die Wartbarkeit und das Debugging erschweren, da es keine klare Stelle im Code gibt, an der die Initialisierung stattfindet.
   • Andere Entwickler könnten Schwierigkeiten haben, den Zusammenhang zwischen der automatischen Initialisierung und bestimmten Funktionalitäten zu erkennen.
2. Keine Parameter:
   • ModuleInitializer müssen parameterlos sein. Das bedeutet, dass keine Abhängigkeiten oder Konfigurationsoptionen über Parameter übergeben werden können.
   • Dependency Injection (DI) ist daher nicht möglich, da keine Parameter zur Verfügung stehen.
   • Wenn spezifische Konfigurationsoptionen für die Initialisierung benötigst werden, müssen alternative Ansätze in Betracht gezogen werden.

Es ist wichtig, diese Nachteile abzuwägen und zu entscheiden, ob die Verwendung von ModuleInitializer in deinem speziellen Fall sinnvoll ist. In einigen Situationen können sie dennoch eine praktische Lösung sein, um bestimmte Aufgaben automatisch auszuführen.

Einleitung

Dieser Artikel befasst sich mit der AOT (Ahead-Of-Time) Kompilierung einer .NET Core 8-Anwendung in Docker und deren Bereitstellung als fertiges Image.

Bevor wir uns der konkreten Implementierung der AOT-Kompilierung in Docker widmen, folgt eine kurze Einführung in AOT und Docker-Kompilierung.

AOT

Die AOT Kompilierung in C# ist eine Technik, die den Code vor der Laufzeit kompiliert. Dies kann zu einer verbesserten Leistung führen, da der Code nicht zur Laufzeit interpretiert oder just-in-time kompiliert werden muss.

In ASP.NET Core 8.0 wurde Unterstützung für native .NET-AOT-Kompilierung eingeführt1. Die Veröffentlichung und Bereitstellung einer nativen AOT-App bietet folgende Vorteile:

• Minimierter benötigter Speicherplatz auf dem Datenträger: Bei der Veröffentlichung mit nativer AOT-Kompilierung wird eine einzelne ausführbare Datei erstellt, die nur den Code aus externen Abhängigkeiten enthält, der zur Unterstützung des Programms erforderlich ist.
• Verkürzte Startzeit: Native AOT-Anwendungen können kürzere Startzeiten aufweisen.
• Reduzierter Speicherbedarf: Native AOT-Apps können je nach den von der App ausgeführten Aktionen einen geringeren Speicherbedarf aufweisen.

Es ist jedoch wichtig zu beachten, dass nicht alle ASP.NET Core-Features mit nativer AOT-Kompilierung kompatibel sind. Beispielsweise sind MVC, Blazor Server und SignalR nicht unterstützt

Kompilierung in Docker/Container

Bei der Kompilierung einer Anwendung in Docker wird ein neues Build-Image erstellt, zu dem der Quellcode hinzugefügt wird. Zudem werden alle Anwendungen und Dateien, die für die Kompilierung notwendig sind, ebenfalls hinzugefügt. Anschließend wird die Anwendung kompiliert.

Die Verwendung von Docker zum Kompilieren bietet den Vorteil der Reproduzierbarkeit und Skalierbarkeit. Das Image muss nur einmal in einem Dockerfile konfiguriert werden und kann dann immer wieder verwendet werden. Das Build-Image kann zunächst lokal auf dem eigenen Client getestet werden, bevor es für die Build-Pipeline freigegeben wird. Spezifische Einstellungen auf dem Build-Server entfallen. Bei einer neuen .Net Core-Version muss lediglich das Image angepasst werden. Es sind keine Installationen auf dem Build-Server erforderlich. Dadurch können neue Build-Server einfach integriert werden. Darüber hinaus steht nach dem Erstellen direkt ein Docker-Image zur Verfügung.

.Net Core AOT Kompilierung in Docker

Dieses Kapitel veranschaulicht beispielhaft, wie eine .dockerignore- und Dockerfile-Datei aussehen könnten. Es ist notwendig, diese Dateien entsprechend den Anforderungen Ihres eigenen Projekts anzupassen. Vorausgesetzt werden Kenntnisse in Docker und eine bestehende Installation. Theoretisch sollte auch Podman funktionieren.

Für eine umfassendere Auseinandersetzung mit Docker empfehle ich das Buch “Skalierbare Container-Infrastrukturen: Das Handbuch für Planung und Administration”, welches auch die Container-Orchestrierung mit Kubernetes und OpenShift behandelt.

.dockerignore

Die .dockerignore-Datei dient dazu, festzulegen, welche Dateien beim Kopieren mit dem Befehl Copy ignoriert werden sollen. Im untenstehenden Beispiel werden alle Dateien in den Ordnern ‘obj’ und ‘bin’ ignoriert. Durch die Reduzierung der Datenmenge kann die Erstellung des Build-Images beschleunigt werden.

**/obj/
**/bin/

Dockerfile

Zunächst wird das Runtime-Image definiert und ein Benutzer hinzugefügt. Die Anwendung befindet sich im Verzeichnis /app. Anschließend wird der Build mit der .NET SDK 8.0 erstellt. Dabei werden sowohl die Projektmappe als auch der Quellcode zum Image hinzugefügt. Danach wird die Anwendung kompiliert, in diesem Fall für Linux-x64. Für win-x64 (Windows) wäre ein Windows-Container erforderlich. Bei der Verwendung von Docker-Hub mit Windows WSL 2 wird stets ein Linux-Container erstellt.

Schließlich wird das eigentliche Image erstellt. Die kompilierte Anwendung wird in das Verzeichnis /app kopiert und das auszuführende Programm wird als Entrypoint festgelegt. Bei Linux hat die auszuführende Datei keine .exe-Endung. Die Labels sind optional.

Das Image kann mit dem Befehl docker build -t {ImageName} . ausgeführt werden.

# Runtime Image
FROM alpine:3.19.1 AS prepare
# libc6-compat wird zum ausführen benötigt
RUN apk add --no-cache libc6-compat
WORKDIR /app
RUN adduser -u 1000 --disabled-password --gecos "" appuser && chown -R appuser /app
USER appuser

# Build Image
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
# clang zlib1g-dev werden für AOT benötigt
RUN apt update && apt upgrade -y && apt install -y clang zlib1g-dev
WORKDIR /build
COPY ./Projektmappe.sln ./
COPY ./src ./src
RUN dotnet publish ./src/Projekt/Projekt.csproj -c Release -r linux-x64 -o /app

FROM prepare AS finalalpine

# Labels.
LABEL maintainer=""
LABEL org.label-schema.schema-version="1.0"
LABEL org.label-schema.name=""
LABEL org.label-schema.description=""
LABEL org.label-schema.version="1.0"

COPY --chown=appuser --from=build /app ./
ENTRYPOINT ["./Programm"]

Bei der Verwendung eines privaten Nuget-Repositorys müssen Sie Anmeldedaten angeben. Die genaue Vorgehensweise wird auf der entsprechenden GitHub-Seite erläutert.

dotnet-docker/documentation/scenarios/nuget-credentials.md at main · dotnet/dotnet-docker

Docker images for .NET and the .NET Tools. Contribute to dotnet/dotnet-docker development by creating an account on GitHub.

GitHubdotnet

Eine der Herausforderungen bei der Entwicklung von Angular-Webseiten ist die Reduzierung der Bundle-Größe. Dies ist entscheidend, um eine schnelle Ladezeit der Webseite für die Besucher zu gewährleisten. Eine Methode, dies zu erreichen, besteht darin, dass der Kompiler die Webseite in einzelne Javascript-Dateien kompiliert.

Mit der Einführung von Angular 17 wurde die @defer Anweisung hinzugefügt. Diese sieht wie folgt aus:

@defer {
  <large-component />
}

Diese Anweisung ermöglicht es, eine Standalone Komponente nachträglich zu laden. Dies ist besonders nützlich, wenn eine Komponente nicht sofort benötigt wird.

Dialog

Beim Öffnen eines Dialogs (einer Komponente) über MatDialog wird die zu öffnende Komponente direkt in der Javascript-Datei eingebettet. Dies ist nicht immer wünschenswert, insbesondere wenn der Dialog sehr selten geöffnet wird und daher kaum benötigt wird.

Es ist möglich, die Komponente erst beim Aufruf über import zu laden. Dadurch wird die eigentliche Javascript-Datei kleiner. Ein Beispiel dafür könnte wie folgt aussehen:

public openDialog() {
  import('./dialog.component').then(
        (x) => {
           this.matDialog.open(x.DialogComponent)
        },
  );
}

Falls die Komponente noch nicht geladen wurde, wird sie über die import-Anweisung vom Webserver nachgeladen. Anschließend öffnet MatDialog die Komponente. Es ist empfehlenswert, dass es sich bei der Komponente um eine Standalone-Komponente handelt

Durch die Verwendung dieser Techniken können Entwickler die Leistung ihrer Angular-Webseiten erheblich verbessern und so für ein besseres Benutzererlebnis sorgen. Es ist wichtig, stets auf dem neuesten Stand der Technologie zu bleiben und neue Funktionen und Techniken zu nutzen, sobald sie verfügbar sind.