Dein VB.NET Programm automatisch bei Systemstart starten

Hast Du Deine nächste tolle Anwendung entwickelt, Welche Du nun via VB.NET in den Autostart packen möchtest? Im heutigen Beitrag schauen wir uns genau das und mehr, wie z. B. das Erstellen von Verknüpfungen via der „WshShell“ an. Bleib also dran, es wird ziemlich interessant 😉!

💡 Hinweis: Wenn Du es eilig hast, kannst Du auch direkt zum Code weiter unten scrollen, bzw. das Inhaltsverzeichnis für das Springen zu verschiedenen Eckpunkten verwenden. Auch wenn der Beitrag seinen Fokus auf VB.NET hat, sind alle Code-Beispiele natürlich auch für C# verfügbar! Springe für den kompletten Code, oder für dessen Verwendungsbeispiele nach unten.

Wie Du vielleicht weißt hatte ich auch schonmal ein Video zum Thema gemacht – vor unfassbaren 11 Jahren, oh man, ich werde alt.. Ein Abonnent hatte mich darauf aufmerksam gemacht, dass es in die Jahre gekommen ist und er sich ein Update wünscht. Dies war mir Befehl und nun sind wir hier 🤓!

Wenn Du moderne Anwendungen entwickeln möchtest – Welche dann passenderweise in den Autostart können –, solltest Du Dir unbedingt diese beiden Beiträge anschauen:

• Der ultimative INotifyPropertyChanged Guide – für C# & VB.NET
• Der ultimative WPF DataGrid MVVM Guide – C# & VB.NET

Als Video ansehen – „VB.NET Autostart von Programmen“

Wenn Du es eiliger, bzw. eventuell keine Lust auf Text hast, kannst Du natürlich auch gerne zum Videoformat greifen und Dich berieseln lassen. Nutze auch im Video gerne die Kapitel, um zu den Stellen von besonderem Interesse zu springen.

Wie startet man Software überhaupt via Autostart?

Bevor wir uns an die VB.NET-spezifische Thematik wagen, ist es ggf. vorerst ganz sinnvoll, sich mit dieser Frage auseinanderzusetzen: Wie starte ich ein Programm überhaupt bei Systemstart? Grundsätzlich ist die Antwort darauf ziemlich einfach, denn Windows bietet eigentlich alle Bordmittel, Die man als Administrator oder auch Entwickler, braucht.

Dazu gibt es den sogenannten Autostart-Ordner, Welcher ungefähr so wie gleich folgend aussieht. Bei mir ist – zugegebenermaßen – nicht viel dort zu sehen, denn ich versuche den immer „clean“ zu halten.

Vorgehensweise

Um ein Programm beim Start des Windows-Systems automatisch mit-starten zu lassen, muss man Dieses, bzw. eine Verknüpfung dazu in den Autostart-Ordner ablegen. Das Schöne ist hier wirklich die Möglichkeit der Verknüpfung, denn wer hat Lust, jedes Mal x Megabyte zu kopieren und eventuell dann doppelt zu haben. Ich persönlich hatte bei dieser Vorgehensweise auch nie Probleme, im Gegensatz zu einigen recherchierten Suchergebnissen auf Google. Kommentiere gerne, wenn auch Du auf derartige Probleme stößt, würde mich interessieren!

Vorsicht geboten

Wie erwähnt wird jedes Programm, bzw. jede Verknüpfung im genannten Ordner automatisch bei Systemstart gestartet. Das stattet uns Entwickler & Administratoren natürlich auch mit einer großen Bürde aus. Erstens – so finde ich – sollte man dem Nutzer bei Systemstart nicht direkt 20 GUIs an den Kopf schmeißen und zweitens sollte man ja auch noch an die Startzeit denken. Wer hat schon Lust, 5 Minuten länger zu warten, nur weil ein Programm bei Start schon viel Auslastung zieht!?

Welche Möglichkeiten habe ich beim Autostart?

Egal ob mit VB.NET (oder C#..), oder ohne, wir haben verschiedene Möglichkeiten, den Autostart zu verwenden. Einerseits können wir benutzerspezifische Startmöglichkeiten verwenden, oder auch global, also für alle Nutzer einen automatischen Programmstart anlegen. In diesem Beitrag gehe ich jedoch in erster Linie auf den benutzerspezifischen Autostart ein.

Wo, bzw. wie finde ich die Autostart-Ordner?

In erster Linie kommt das natürlich darauf an, für wen Du einen Autostart erstellen möchtest. Möchtest Du Dein Programm z. B. für den aktuellen Nutzer in den Autostart legen, dann kommt folgendes Verzeichnis in Frage. Beachte hierbei, dass Du den Platzhalter natürlich durch den jeweiligen Nutzernamen ersetzen müsstest:

C:\Users\<DeinNutzername>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Du kannst den Ordner auch vereinfacht finden, indem Du die Windows-Taste+R drückst, was den „Ausführen“-Dialog startet. Und im nächsten Schritt dann:

shell:startup

eingeben, was Dich dann in dem für Dich passenden Autostart-Ordner auskommen lässt. Cool, oder?

Globaler Autostart-Ordner

Möchtest Du hingegen den „globalen“ Ordner finden, kannst Du stattdessen in folgendem Verzeichnis

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

und mit diesem Befehl hier fündig werden (denke an Windows-Taste+R):

shell:common startup

Hier findest Du dann die Programme, Welche für alle Nutzer automatisch bei Systemstart gestartet werden sollen.

Wie sieht der VB.NET Autostart nun aus?

Um nun die oben erklärte Logik, bzw. Vorgehensweise mit VB.NET nachzubilden, müssen wir ja praktisch nichts Anderes tun. Wir müssen (via Code) eine Verknüpfung unserer Anwendung erschaffen und Diese nach Möglichkeit im Autostart-Ordner unserer Wahl unterbringen. Besonders die Erstellung einer Verknüpfung kann aber tricky sein, wenn man nicht weiß, wie.

Zusätzlich könnte man weitere Hilfsmittel schreiben, um z. B. überprüfen zu können, ob sich unsere Anwendung aktuell schon im Autostart befindet. Dies alles werden wir selbstverständlich nach Regeln der OOP (Objektorientierten Programmierung) in eine Klasse auslagern. So bleibt alles schön wiederverwendbar und portierbar.

Lege also im nächsten Schritt einen Ordner namens „Utils“ in Deinem Projekt an und erstelle dort drin eine „Autostart“-Klasse.

Mit VB.NET den Autostart-Ordner ermitteln

Bevor wir uns jedoch Gedanken über Dinge wie „Wie kann ich die Verknüpfung erstellen“, usw. machen, starten wir easy. Zuerst einmal müssen wir wissen, wie wir an den Autostart-Ordner kommen, ist ja schließlich Betriebssystem-Sache. Zufälligerweise benutzen wir eine optimale Sprache für dieses Betriebssystem vom selben Hersteller – kann ja dann nicht so schwer sein, richtig? Richtig!

Um an den Pfad zum Autostart-Ordner (auch Startup-Folder genannt) zu kommen, können wir vorgefertigte Funktionen nutzen. Die Methode unseres Vertrauens befindet sich in der „Environment“-Klasse und heißt „GetFolderPath“. Diese erwartet einen Wert der „SpecialFolder“-Enumeration aus selbiger Klasse.

Implementieren wir nun eine Art „Singleton“-, bzw. eine „Lazy“-Property (Eigenschaft), Welche uns den Autostart-Ordner serviert. So müssen wir der Environment nicht öfter als nötig auf die Nerven gehen – ergo, die Funktion nur einmalig aufrufen und den Rückgabewert zwischenspeichern:

        Private Shared _startupDirectory As String

        Public Shared ReadOnly Property StartupDirectory As String
            Get
                If String.IsNullOrWhiteSpace(_startupDirectory) Then
                    _startupDirectory = Environment.GetFolderPath(Environment.SpecialFolder.Startup)
                End If
                Return _startupDirectory
            End Get
        End Property

    private static string _startupDirectory;

    public static string StartupDirectory
    {
        get
        {
            if (string.IsNullOrWhiteSpace(_startupDirectory))
                _startupDirectory = Environment.GetFolderPath(Environment.SpecialFolder.Startup);
            return _startupDirectory;
        }
    }

Einen Eintrag in den Autostart mit VB.NET hinzufügen

Im nächsten Schritt schauen wir uns an, wie wir unsere VB.NET-Anwendung, bzw. eine Verknüpfung davon in den Autostart-Ordner gelegt bekommen. Dazu bauen wir uns eine kleine „AddEntry“ Methode, Welcher es egal ist, ob ein Pfad zu unserer Anwendung mitkommt, denn Diesen, kann Sie auch selbst ermitteln. So bleibt uns die Möglichkeit übrig, fremde Anwendungen, sowie die Eigene gemütlich hinzuzufügen:

        ''' <summary>
        ''' Adds an entry to the autostart folder for the given Application
        ''' </summary>
        ''' <param name="applicationFilePath">The given application filepath, or empty to create an autostart for the current executing .exe</param>
        Public Shared Sub AddEntry(Optional applicationFilePath As String = "")
            Dim noAppPathProvided = applicationFilePath = ""
            If noAppPathProvided Then
                DefaultToExecutingExe(applicationFilePath)
            End If
            CreateShortcut(applicationFilePath)
        End Sub

/// <summary>
/// Adds an entry to the autostart folder for the given Application
/// </summary>
/// <param name="applicationFilePath">The given application filepath, or empty to create an autostart for the currently executing .exe</param>
public static void AddEntry(string applicationFilePath = "")
{
    var noAppPathProvided = applicationFilePath == "";
    if (noAppPathProvided)
        DefaultToExecutingExe(applicationFilePath);
    CreateShortcut(applicationFilePath);
}

Wie Du hier schon sehen kannst, schauen wir (wie erwähnt), ob ein passender „applicationFilePath“ mitgeliefert wurde. Wenn nicht „Defaulten“ wir zur ausführenden Exe-Datei, also dem aktuellen Programm. So oder so erstellen wir am Ende der Methode eine Verknüpfung, was wir im nächsten Schritt besprechen werden.

Die ausgeführte .Exe-Datei erkennen

Nachdem wir die eigentliche Methode schon einmal im letzten Schritt vorbereitet haben, fehlen nun noch die 2 Sub-Routinen. In erster Linie schauen wir hier uns hier schnell die „DefaultToExecutingExe“-Methode an. Diese bekommt einen „ByRef“-Parameter übergeben – empfand ich hier irgendwie leichter lesbar – aber ist nur meine Meinung. Diese setzt dann den „applicationFilePath“ via „Process“-Klasse, bzw. mittels einer verschachtelten Sub-Eigenschaft des Prozesses. Diesen ermitteln wir mit der statischen „GetCurrentProcess“-Funktion der „Process“-Klasse. Hier gibt es ab .NET 6 auch eine neue Variante, allerdings habe ich hier Die genommen, Welche vermutlich am geläufigsten ist.

Unsere VB.NET Anwendung als Verknüpfung in den Autostart legen

Nun fehlt nur noch ein letztes Werkzeug, die Funktionalität, für unsere (und auch andere Anwendungen) eine Verknüpfung erzeugen zu können. Dies kann – wie oben bereits erwähnt – ein wenig tricky werden, wenn man nicht weiß, wie. Wir verwenden dazu das „WshShell“-Interface, Welches komischerweise instanziiert werden kann, Du glaubst mir nicht? Guck in den Code!

COM-Verweis hinzufügen

Bevor wir damit jedoch starten können, müssen wir zuerst noch den benötigten COM-Verweis auf das „Windows Script Host Object Model“ hinzufügen. Das kannst Du ganz einfach machen, indem Du einen Rechtsklick auf Dein Projekt durchführst und anschließend „Hinzufügen->COM-Verweis“ auswählst.

Danach erscheint dieses folgende Fenster, wo Du dann oben rechts dementsprechend z. B. nach „host“ suchen kannst, dann dürftest Du – siehe Bild – schnell fündig werden:

Ein instanziierbares Interface – what the f**?

Um ehrlich zu sein – wie ich nunmal bin.. – habe ich mich selbst damit auch nicht auseinandergesetzt, warum man diese Schnittstelle instanziieren kann (auch in C#). Und da ich COM-Dinge eigentlich nie benötige, ist mir das hier auch relativ egal, solange es funktioniert. Ich gehe mal ohne Recherche davon aus, dass das an der Deklaration des Interfaces liegt, dort sehen wir ein „CoClass“-Attribut.

Vermutlich wird „der Code“ dann sehen: „Ah, da ist ein CoClass Ding, also muss ich das wohl instaziieren“ – oder so ähnlich. EDIT: Habe kurz nachgeguckt, liegt wie vermutet an dem „CoClass“-Attribut – Erfahrung „strikes again“ 😉!

Eine Verknüpfung erstellen

Nachdem wir das Interface nun instanziieren können – ew, klingt immer noch ekelig, na egal – tun wir gleich genau das. Vorher erstellen wir noch ein „FileInfo“-Objekt, Welches uns bei der Arbeit mit Datei-Infos wie den Namen der Datei, usw. unterstützen wird. Und dann gehen wir schonmal hin und erstellen den letztendlichen Pfad der Verknüpfung mit String-Interpolation.

Hier verwenden wir ein weiteres kleines Helferlein, was – wie der Name schon sagt – den Dateinamen ohne Dateiendung für uns herausfiltert. Dazu übergeben wir der statischen „Path“-Klassen-Funktion „GetFileNameWithoutExtension“, den Namen des „FileInfo“-Objektes.

Im letzten Schritt erzeugen wir die Verknüpfung auf Objekt-Ebene und casten Sie in ein für unsere Zwecke passendes Interface – „IWshShortcut“. Anschließend kannst Du weitere Eigenschaften wie z. B. die Beschreibung und den Icon-Pfad angeben, dies lasse ich hier aber aus. Zuletzt kommen die beiden wichtigsten Schritte: Den Ziel-Pfad, also den Pfad zur eigentlichen Anwendung festzulegen und dann final auch „Save“ aufzurufen, damit die Verknüpfung tatsächlich erstellt wird.

Prüfen ob ein Autostart-Eintrag existiert

Nun haben wir die Funktionalität von oben vorliegen und würden direkt mit der Nächsten starten. Es wäre schließlich ganz nützlich, wenn man auch prüfen könnte, ob bereits eine Verknüpfung im Autostart ist. Dazu erstellen wir im nächsten Schritt eine „EntryExists“-Funktion, Welche dies über einen Boolean kommuniziert.

In den ersten Zeilen verfahren wir hier wir in der „AddEntry“-Methode, also bezogen auf die Pfad-Sache. Wenn kein Pfad angegeben wurde, nehmen wir den Pfad der aktuellen Exe-Datei, usw. Danach bauen wir uns den Pfad zur Verknüpfung (im Autostart-Ordner!) zusammen. Wenn eine derartige Datei (dort) existiert, dann haben wir das Programm bereits im Autostart – yay!

        Public Shared Function EntryExists(Optional applicationFilePath As String = "") As Boolean
            Dim noAppPathProvided = applicationFilePath = ""
            If noAppPathProvided Then
                DefaultToExecutingExe(applicationFilePath)
            End If
            Dim applicationFile = New FileInfo(applicationFilePath)
            Dim shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk")
            Return IO.File.Exists(shortcutPath)
        End Function

public static bool EntryExists(string applicationFilePath = "")
{
    var noAppPathProvided = applicationFilePath == "";
    if (noAppPathProvided)
        DefaultToExecutingExe(applicationFilePath);
    var applicationFile = new FileInfo(applicationFilePath);
    var shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk");
    return System.IO.File.Exists(shortcutPath);
}

Mit VB.NET den Autostart wieder entfernen

Im letzten Abschnitt dieses Beitrages werden wir uns ansehen, wie wir erzeugte Einträge auch wieder entfernen können. Dies kennt man natürlich bereits aus größeren Tools. Wir schreiben also eine „RemoveEntry“-Methode, Welche sehr ähnlich zu den Vorherigen funktioniert. Zuerst prüfen wir wieder die Pfad-Übergabe, danach erstellen wir der Einfachheit halber eine „FileInfo“ und danach generieren wir den Verknüpfungs-Pfad.

Wenn Dieser Pfad existent ist, wird er gelöscht, somit wird auch unser VB.NET Autostart entfernt. Beachte hierbei, dass ich bewusst kein Try-Catch drum gemacht habe. Ich möchte aktiv auf Fehler reagieren und diese separat und sauber verarbeiten können.

Kompletter Code

Hier findest Du den wichtigsten Code für diesen Beitrag. In diesem Beispiel handelt es sich um die kleine von mir gebaute Hilfs-Klasse. Diese vereinfacht Dir die Erstellung der Programm-Verknüpfung innerhalb des Autostart-Ordners via VB.NET (und C#!):

Imports System.IO
Imports IWshRuntimeLibrary

Namespace Utils

    Public Class Autostart

        Private Shared _startupDirectory As String

        Public Shared ReadOnly Property StartupDirectory As String
            Get
                If String.IsNullOrWhiteSpace(_startupDirectory) Then
                    _startupDirectory = Environment.GetFolderPath(Environment.SpecialFolder.Startup)
                End If
                Return _startupDirectory
            End Get
        End Property

        ''' <summary>
        ''' Adds an entry to the autostart folder for the given Application
        ''' </summary>
        ''' <param name="applicationFilePath">The given application filepath, or empty to create an autostart for the current executing .exe</param>
        Public Shared Sub AddEntry(Optional applicationFilePath As String = "")
            Dim noAppPathProvided = applicationFilePath = ""
            If noAppPathProvided Then
                DefaultToExecutingExe(applicationFilePath)
            End If
            CreateShortcut(applicationFilePath)
        End Sub

        Private Shared Sub DefaultToExecutingExe(ByRef applicationFilePath As String)
            applicationFilePath = Process.GetCurrentProcess().MainModule.FileName
        End Sub

        Private Shared Sub CreateShortcut(applicationFilePath As String)
            Dim applicationFile = New FileInfo(applicationFilePath)
            Dim shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk")
            Dim shell = New WshShell()
            Dim shortcut = CType(shell.CreateShortcut(shortcutPath), IWshShortcut)
            With shortcut
                ' .Description = ""
                ' .IconLocation = ""
                .TargetPath = applicationFile.FullName
                .Save()
            End With
        End Sub

        Public Shared Function EntryExists(Optional applicationFilePath As String = "") As Boolean
            Dim noAppPathProvided = applicationFilePath = ""
            If noAppPathProvided Then
                DefaultToExecutingExe(applicationFilePath)
            End If
            Dim applicationFile = New FileInfo(applicationFilePath)
            Dim shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk")
            Return IO.File.Exists(shortcutPath)
        End Function

        Public Shared Sub RemoveEntry(Optional applicationFilePath As String = "")
            Dim noAppPathProvided = applicationFilePath = ""
            If noAppPathProvided Then
                DefaultToExecutingExe(applicationFilePath)
            End If
            Dim applicationFile = New FileInfo(applicationFilePath)
            Dim shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk")
            IO.File.Delete(shortcutPath)
        End Sub

    End Class

End Namespace

using System.IO;
using IWshRuntimeLibrary;

namespace Utils
{
    public class Autostart
    {
        private static string _startupDirectory;

        public static string StartupDirectory
        {
            get
            {
                if (string.IsNullOrWhiteSpace(_startupDirectory))
                    _startupDirectory = Environment.GetFolderPath(Environment.SpecialFolder.Startup);
                return _startupDirectory;
            }
        }

        /// <summary>
        ///         ''' Adds an entry to the autostart folder for the given Application
        ///         ''' </summary>
        ///         ''' <param name="applicationFilePath">The given application filepath, or empty to create an autostart for the current executing .exe</param>
        public static void AddEntry(string applicationFilePath = "")
        {
            var noAppPathProvided = applicationFilePath == "";
            if (noAppPathProvided)
                DefaultToExecutingExe(ref applicationFilePath);
            CreateShortcut(applicationFilePath);
        }

        private static void DefaultToExecutingExe(ref string applicationFilePath)
        {
            applicationFilePath = Process.GetCurrentProcess().MainModule.FileName;
        }

        private static void CreateShortcut(string applicationFilePath)
        {
            var applicationFile = new FileInfo(applicationFilePath);
            var shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk");
            var shell = new WshShell();
            var shortcut = (IWshShortcut)shell.CreateShortcut(shortcutPath);
            {
                var withBlock = shortcut;
                // .Description = ""
                // .IconLocation = ""
                withBlock.TargetPath = applicationFile.FullName;
                withBlock.Save();
            }
        }

        public static bool EntryExists(string applicationFilePath = "")
        {
            var noAppPathProvided = applicationFilePath == "";
            if (noAppPathProvided)
                DefaultToExecutingExe(ref applicationFilePath);
            var applicationFile = new FileInfo(applicationFilePath);
            var shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk");
            return System.IO.File.Exists(shortcutPath);
        }

        public static void RemoveEntry(string applicationFilePath = "")
        {
            var noAppPathProvided = applicationFilePath == "";
            if (noAppPathProvided)
                DefaultToExecutingExe(ref applicationFilePath);
            var applicationFile = new FileInfo(applicationFilePath);
            var shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk");
            System.IO.File.Delete(shortcutPath);
        }
    }
}

Verwendung des Codes

Um den obigen Code verwenden zu können, kannst Du z. B. 2 Knöpfe und eine CheckBox in Deine Form setzen. Beim Start des Formulares wird die Checkbox je nachdem ob das VB.NET Programm im Autostart liegt gefüllt. Wenn Du dann auf die jeweiligen Buttons drückst, kannst Du das Programm wieder aus dem Autostart entfernen, bzw. natürlich auch hinzufügen. Die Namen sind denke ich selbsterklärend..

Imports AutoStartExampleVb.Utils

Public Class Form1

    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
        chbAutostartActivated.Checked = Autostart.EntryExists()
    End Sub

    Private Sub btnActivateAutostart_Click(sender As Object, e As EventArgs) Handles btnActivateAutostart.Click
        Autostart.AddEntry()
        chbAutostartActivated.Checked = True
    End Sub

    Private Sub btnDeactivateAutostart_Click(sender As Object, e As EventArgs) Handles btnDeactivateAutostart.Click
        Autostart.RemoveEntry()
        chbAutostartActivated.Checked = False
    End Sub

End Class

using System;
using AutoStartExampleVb.Utils;

public class Form1
{
    private void Form1_Load(object sender, EventArgs e)
    {
        chbAutostartActivated.Checked = Autostart.EntryExists();
    }

    private void btnActivateAutostart_Click(object sender, EventArgs e)
    {
        Autostart.AddEntry();
        chbAutostartActivated.Checked = true;
    }

    private void btnDeactivateAutostart_Click(object sender, EventArgs e)
    {
        Autostart.RemoveEntry();
        chbAutostartActivated.Checked = false;
    }
}

Downloads

Keine Lust alles zu kopieren und es manuell zusammen zu frickeln? Dann lade Dir hier einfach den Beispielcode herunter, Dieser beinhaltet die komplette und fertig testbare Projektmappe.

Der Beitrag VB.NET Autostart für Dein eigenes Programm erstellen – 2024 Version erschien zuerst auf Robert Skibbe.

ConfigureAwait(False) als Standard für erfahrene Entwickler

Erfahre im heutigen Beitrag, warum „ConfigureAwait“ der Standard für fortgeschrittene Entwickler sein sollte. Hierzu schauen wir uns natürlich auch Beispiele ohne die benannte – ich nenne Sie mal – „Konfigurations“-Methode an. Insbesondere fällt hier auch ins Gewicht, welche Hürden man als Anfänger dabei bewältigen muss. Schaue Dir hierzu auch gerne die Beispiele in VB.NET und C# an!

Was ist, bzw. wofür ist ConfigureAwait?

Ganz plump übersetzt und zusammengefasst: Die „ConfigureAwait“-Methode konfiguriert eine Task so, dass dessen Folgeanweisungen auf dem Thread des Synchronisations-Kontextes ausgeführt (oder nicht ausgeführt) werden. Für gewöhnlich steht diese Konfiguration auf „True“, daher „springt“ die Ausführung nach einer erwarteten Task immer wieder auf den Thread des Synchronisations-Kontextes zurück.

Als Video auf YouTube ansehen

Hast Du keine Lust auf Text? Dann besuche einfach mein passendes Video auf YouTube dazu. Ich habe mir größte Mühe gegeben, es einfach und verständlich zu erklären.

Wieso sollte ich nach Möglichkeit ConfigureAwait(False) verwenden?

Man sollte ConfigureAwait(False) nach Möglichkeit verwenden, damit man eventuellem, permanentem ContextSwitching aus dem Weg geht. Das sähe dann vereinfacht gesagt so aus: Hintergrund, Vordergrund, Hintergrund, Vordergrund,… Es wäre hingegen doch wesentlich schöner, wenn wir erst alles im Hintergrund erledigen und dann final im Vordergrund bleiben, oder?

Nun hast Du bereits erfahren, dass bei entsprechender Konfiguration (standardmäßig True) ein eventuelles, ständiges Hopping zwischen den Threads stattfindet. Stell Dir vor, Du würdest eine Web-Schnittstelle aufrufen, oder eine Datei einlesen. Dies machst Du für gewöhnlich am besten asynchron, damit die grafische Oberfläche dabei nicht hängt. Stell Dir nun 5 Aufgaben vor, Welche dieses „in den Hintergrund auslagern“ verwenden.

Es wäre doch blöd, wenn man nach jeder ausgeführten Aufgabe erst wieder zurückkommt, nur um dann wieder unnötig hin und her zu hüpfen.

Das ist ungefähr so, als würde ich Dir abwechselnd sagen „Geh‘ weg, komm‘ zurück, geh‘ weg…“. Spätestens nach dem zweiten Mal würdest Du mir vermutlich einen Vogel zeigen. Dies solltest Du bei der Konzeption / der Architektur Deiner Anwendungen auch im Kopf behalten. Leider kann der Computer uns hier nicht ebenfalls einen Vogel zeigen, denn Der macht letztendlich nur das, was Du Ihm durch Code sagst – KI und Co. jetzt mal weggelassen 😉.

Wie sieht der Code ohne ConfigureAwait-Konfiguration aus?

Damit wir die Vorgehensweise und den positiven Effekt hinter „ConfigureAwait“ noch besser verstehen können, schauen wir es uns Schritt für Schritt an. Im ersten Schritt, bauen wir einfach mal ein wenig Code, ohne großartig darüber nachzudenken (wie leider viele Anfänger/Junior-Developer). Bei diesem Code ist dies auch nicht weiter „problematisch“ – bis auf das ggf. fehlende Wissen dahinter.

Wirf also nun einen Blick auf folgenden, simplen Code, Welcher die statische „Delay“-Methode der Task-Klasse verwende. Packe einen Knopf und ein Label auf Deine Form und generiere den Klick-Handler für den Button. Da wir uns hier nur auf das Wesentliche konzentrieren gehe ich an dieser Stelle davon aus, dass Du Dich mit dem erstellen eines Button-Klick-Handlers auskennst.

Ein wenig mit Hilfe der Task warten

Hierbei ist es auch relativ egal, ob Du nun Winforms oder WPF verwendest. Achte nur darauf, dass Du die Methode mit „Async“ (VB.NET) / „async“ (C#) markierst. Schreibe nun folgenden Code hinein und schaue, wie sich die Anwendung bei einem Klick verhält:

Private Async Sub Button1_Click(sender As Object, e As EventArgs)
  ' vor dem Delay (der "erwarteten" Task)
  Await Task.Delay(1000)
  ' nach dem Delay (nach der "erwarteten" Task)
  Label1.Text = "Mein neuer Text!"
End Sub

private async void Button1_Click(object sender, EventArgs e)
{
  ' vor dem Delay (der "erwarteten" Task)
  await Task.Delay(1000)
  ' nach dem Delay (nach der "erwarteten" Task)
  Label1.Text = "Mein neuer Text!";
}

Erstmal alles in Ordnung, oder? Die Anwendung startet und wartet darauf, dass Du etwas machst. Wenn Du auf den Button klickst, wartet „die Anwendung“ eine Sekunde und der Text wird erfolgreich gesetzt. Hier ist wichtig zu verstehen, dass die Anwendung tatsächlich im Hintergrund wartet, ansonsten wäre Deine grafische Oberfläche währenddessen eingefroren.

Wie das Ganze non-async aussieht

Hierzu kannst Du auch einmal die „Thread.Sleep“-Variante nehmen, also ohne async und await, dann weißt Du was ich meine 🤓! Du startest die Anwendung wie vorher, klickst auf den Button und merkst dann ups, ich kann das Fenster weder bewegen, noch vergrößern/verkleinern und auch der Text ändert sich nicht? Die Wartezeit habe ich bewusst hochgestellt – damit es noch klarer sichtbar ist, denn z. B. das Label ändert sich erst nachdem die Zeit abgelaufen ist.

Private Sub Button1_Click(sender As Object, e As EventArgs)
  ' vor dem Sleep
  System.Threading.Thread.Sleep(5000)
  ' nach dem Sleep
  Label1.Text = "Mein neuer Text!"
End Sub

private void Button1_Click(object sender, EventArgs e)
{
  ' vor dem Sleep
  System.Threading.Thread.Sleep(5000)
  ' nach dem Sleep
  Label1.Text = "Mein neuer Text!";
}

Nun hast Du gesehen und ggf. verstanden, was es zumindest für Auswirkungen hat, wenn der Thread der grafischen Oberfläche „zu“ beschäftigt ist.

Ein Beispiel mit ConfigureAwait(False)

Ich kann Dich schon grummeln hören: „Ja wenn das so wichtig ist, wie sieht denn dann ein konfiguriertes Beispiel aus? Wenn True der Standardwert ist, wie sieht es dann beim – Deiner Meinung nach – richtigen False aus?“. Das ist eine gute Frage und Dieser widmen wir uns jetzt – schaue Dir den vorherigen Code nochmal, aber nun wie folgt an. Bedenke dabei, dass der Wert „True“ standardmäßig voreingestellt ist, wir aber nun explizit „False“ angeben:

Private Async Sub Button1_Click(sender As Object, e As EventArgs)
  ' vor dem Delay (der "erwarteten" Task)
  Await Task.Delay(1000) _ ' wegen der Leserlichkeit umgebrochen
    ConfigureAwait(False)
  ' nach dem Delay (nach der "erwarteten" Task)
  Label1.Text = "Mein neuer Text!"
End Sub

private async void Button1_Click(object sender, EventArgs e)
{
  // vor dem Delay (der "erwarteten" Task)
  await Task.Delay(1000) // wegen der Leserlichkeit umgebrochen
    .ConfigureAwait(false);
  // nach dem Delay (nach der "erwarteten" Task)
  Label1.Text = "Mein neuer Text!";
}

Huch, jetzt gibt es einen Fehler?

Nachdem Du den obigen Code ausgeführt hast, fragst Du Dich nun bestimmt: „Toll, jetzt habe ich’s genauso gemacht, wie Du sagtest, aber jetzt gibt es einen Fehler, warum? Wie soll mir das helfen?“. Ich kann Deine Aufregung als vermutlicher Anfänger (ggf. sogar Fortgeschrittener) erstmal verstehen. Ich erkläre Dir erstmal was passiert ist und warum wir diesen Fehler bekommen.

Wie oben bereits erwähnt, steht „ConfigureAwait“ praktisch standardmäßig auf „True“, also wenn wir es gar nicht angeben. Dies bewirkt, dass wir uns so gesehen vor der Ausführung der „Await“-beinhaltenden Zeile (im obigen Beispiel) auf dem Thread der grafischen Oberfläche befinden. Dies ist der „captured context“, also der abgefangene/gefangene Thread a la „Ah okay, also auf diesem Thread soll ich laufen?“.

Solange wir Änderungen an der grafischen Oberfläche vornehmen wollen, ist dies auch super, aber warum der Fehler kommt, hörst Du nun. Wenn wir nach dem „Await“ durch „ConfigureAwait(False)“ eben NICHT mehr auf den „captured context“ zurückkommen, dann können wir darin auch nicht arbeiten. Wir können die grafische Oberfläche also nun nicht mehr ändern. Wann und warum das sinnvoll sein kann, bzw. wie das genau aussieht, schauen wir uns im nächsten Abschnitt an.

Wann ist „False“ für ConfigureAwait sinnvoll?

Nachdem unser letzter Code-Umbau für Dich vermutlich eher etwas Negatives erzeugt hat, bringen wir nun Licht ins Dunkel, wann die Verwendung von „False“ sinnvoll ist. Eigentlich könnte man sagen, dass die Verwendung von „False“ als Default-Wert, seine starke Daseinsberechtigung hat, allerdings in manchen Fällen wie oben zu Problemen führt.

Schaue Dir für das nähere Verständnis einmal den folgenden Service isoliert an. Dieser macht Gebrauch von einer kostenlosen Web-Schnittstelle, Welche uns eine zufällige Aktivität für den Alltag vorschlägt – einen simplen String.

Imports System.Net.Http
Imports System.Text.Json

Public Class ActivityService

    Private _httpClient As HttpClient

    Private Const API_URL As String = "https://www.boredapi.com/api/activity"

    Sub New(httpClient As HttpClient)
        _httpClient = httpClient
    End Sub

    Public Async Function GetRandomActivityAsync() As Task(Of String)
        Dim response = Await _httpClient _
            .GetAsync(API_URL) _
            .ConfigureAwait(False)
        Dim contentStream = Await response.Content _
            .ReadAsStreamAsync() _
            .ConfigureAwait(False)
        Dim options = New JsonSerializerOptions() With {
            .PropertyNamingPolicy = JsonNamingPolicy.CamelCase
        }
        Dim jsonObject = Await JsonSerializer _
            .DeserializeAsync(Of ActivityResponse)(contentStream, options) _
            .ConfigureAwait(False)
        Return jsonObject.Activity
    End Function

End Class

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Globalization;
using System.IO;
using System.Linq;
using System.Reflection;
using System.Runtime.CompilerServices;
using System.Security;
using System.Text;
using System.Threading.Tasks;
using Microsoft.VisualBasic;
using System.Net.Http;
using System.Text.Json;

public class ActivityService
{
    private HttpClient _httpClient;

    private const string API_URL = "https://www.boredapi.com/api/activity";

    public ActivityService(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    public async Task<string> GetRandomActivityAsync()
    {
        var response = await _httpClient
           .GetAsync(API_URL)
           .ConfigureAwait(false);
        var contentStream = await response.Content
            .ReadAsStreamAsync()
            .ConfigureAwait(false);
        var options = new JsonSerializerOptions()
        {
            PropertyNamingPolicy = JsonNamingPolicy.CamelCase
        };
        var jsonObject = await JsonSerializer
            .DeserializeAsync<ActivityResponse>(contentStream, options)
            .ConfigureAwait(false);
        return jsonObject.Activity;
    }
}

In der Funktion (Welche eine Task zurückgibt!) „GetRandomActivityAsync“ siehst Du einige Verwendungen mit dem übergebenen Parameter-Wert „False“. Diese bewirken, dass wir nicht nach jedem „Await“ wieder zurück in den ursprünglich „gefangenen“ Kontext hüpfen. Dies ist natürlich wesentlich sauberer und vor allem effizienter!

Der Aufruf aus der Form aus könnte daher nun wie gleich folgend aussehen. Wir verwenden unseren Service und lassen die Ausführung anschließend wieder durch „ConfigureAwait(True)“ – was ja der Standardwert ist – zurück in den alten Thread hüpfen. Dabei handelt es sich um den Thread, in Welchem wir die grafische Oberfläche verändern können, nice!

Nun haben wir also den Service durch die Verwendung von „ConfigureAwait(False)“ an den entsprechenden Stellen effizienter und sauberer gestaltet. Trotzdem können wir den Form-Code nach wie vor so benutzen, wie wir es gewohnt sind.

' irgendwo weiter oben in der Klasse
Private _activityService As ActivityService

Sub New(activityService As ActivityService)
  ' per Dependency Injection injiziert..
   _activityService = activityService
End Sub

Private Async Sub Button1_Click(sender As Object, e As EventArgs)
  ' vor dem Delay (der "erwarteten" Task)
  Dim response = Await _activityService.GetRandomActivityAsync()
  ' nach dem Delay (nach der "erwarteten" Task)
  Label1.Text = "Mein neuer Text!"
End Sub

    // irgendwo weiter oben in der Klasse
    private ActivityService _activityService;

    public ActivityService(ActivityService activityService)
    {
        // per Dependency Injection injiziert..
        _activityService = activityService;
    }

    private async void Button1_Click(object sender, EventArgs e)
    {
        // vor dem Delay (der "erwarteten" Task)
        var response = await _activityService.GetRandomActivityAsync();
        // nach dem Delay (nach der "erwarteten" Task)
        Label1.Text = "Mein neuer Text!";
    }

Fazit

Wer als .NET-Entwickler einen saubereren und effizienteren Programmierstil im Bezug auf Tasks und Co. an den Tag legen möchte, sollte unbedingt „ConfigureAwait(False)“ an passenden Stellen nutzen. Da man vermutlich wesentlich häufiger eben nicht in den alten Synchronisations-Kontext wechseln muss, empfiehlt sich daher eher das Paradigma „False-first“. Dies kann jedoch besonders bei Anfängern zu Verwirrung führen – aber wie heißt es so schön: „Learning by doing“, gell!?

Weiterführende Links

• Dictionaries – ein kompletter VB.NET Guide mit Messungen
• Eine CSV-Preisliste mit VB.NET einlesen
• Bluetooth-Geräte mit C# auflisten (English)

Der Beitrag Was ist ConfigureAwait und warum sollte „False“ der Standard sein? erschien zuerst auf Robert Skibbe.