Letzten Herbst saß ich bei einem Maschinenbauer, 120 Mitarbeitende, irgendwo zwischen Stuttgart und Ulm. Das interne Webportal für Servicetechniker — klassisches ASP.NET Core MVC, Razor Views, ein Dev der das vor drei Jahren hingestellt hat und inzwischen in Elternzeit ist. Der Nachfolger fragt mich: „Wir wollen auf jeder Seite die aktuelle App-Version und den Mandanten-Namen im HTML sichtbar machen, damit Support-Tickets eindeutig sind. Wie macht man sowas sauber, ohne überall ViewBag.Version reinzukleistern?"
Genau in diesem Moment hätte ich ihm diesen Artikel von Khalid Abuhakmeh zeigen können.
Was Khalid zeigt
Khalid, Developer Advocate bei JetBrains, erklärt ein Feature von ASP.NET Core, das ich selbst erst nachschlagen musste, als ich es zum ersten Mal brauchte: ITagHelperInitializer<T>. Das Interface erlaubt es, alle Instanzen eines bestimmten TagHelpers global zu initialisieren — bevor Razor sie rendert, bevor irgendein View-Code läuft.
Das Beispiel ist minimalistisch und klar: Ein MyTagHelper bekommt neben seinem HTML-gebundenen Attribut text auch eine Version-Property, die mit [HtmlAttributeNotBound] dekoriert ist. Ein MyTagHelperInitializer implementiert ITagHelperInitializer<MyTagHelper> und setzt beim Rendering auf jeder Seite automatisch den Versions-String. Registriert als Singleton in Program.cs, ein einziger Aufruf.
Das Ergebnis: Jedes <span text="..."> bekommt automatisch ein data-version="1.0.0" — ohne dass ein einzelner View davon wissen muss. Khalid weist auch darauf hin, dass man über den ViewContext Zugriff auf HttpContext hat, also auf User-Infos, Cookies, Request-Daten. Das ist tatsächlich mächtig.
Wie das im KMU landet
Zurück zu meinem Maschinenbauer. Das Pattern funktioniert dort. Aber ich habe beim Lesen des Artikels gemerkt, warum viele meiner Kunden solche Features nie einsetzen — nicht weil sie zu schwierig wären, sondern weil der Artikel zwei Dinge voraussetzt, die im Mittelstand oft nicht gegeben sind.
Erstens: Es braucht jemanden, der TagHelpers überhaupt kennt.
In Teams von 2-5 Devs, die eine Fachanwendung pflegen, ist der Wissensstand heterogen. Ich sehe regelmäßig Projekte, wo Custom TagHelpers komplett fehlen — nicht weil man sie bewusst abgelehnt hat, sondern weil der ursprüngliche Entwickler mit @Html.Raw(...) und Partial Views groß geworden ist und sich nie damit beschäftigt hat. Khalids Artikel ist für Leute geschrieben, die TagHelpers bereits nutzen und jetzt das nächste Level wollen. Das ist eine ehrliche Zielgruppe — aber im Mittelstand ist das oft die Minderheit.
Zweitens: Der Singleton-Hinweis ist wichtiger als er wirkt.
Khalid erwähnt es kurz und korrekt: „this type is registered as a Singleton, which means any data passed to it in the constructor is the data for the rest of the application's lifetime." Das klingt selbstverständlich, ist es aber nicht. Ich habe in einem Projekt gesehen, wie ein gut gemeinter Initializer Mandanten-Daten aus dem DI-Container gezogen hat — als Singleton. Ergebnis: Alle Nutzer sahen nach dem ersten Request die Daten des ersten Mandanten. Der Bug war subtil, weil er im Development nie auftrat — dort gab es nur einen Mandanten.
Wenn du ITagHelperInitializer mit request-spezifischen Daten füllen willst (Nutzername, Tenant-ID, Session-Werte), musst du das im Initialize-Aufruf über den ViewContext tun, nicht im Konstruktor. Der Konstruktor wird nur einmal ausgeführt. Das ist kein Fehler im Artikel — Khalid hat sogar explizit auf ViewContext hingewiesen. Aber für ein Team, das das Pattern zum ersten Mal sieht, ist die Reihenfolge im Artikel so, dass der Singleton-Weg zuerst kommt und der ViewContext-Weg als Ergänzung wirkt. In der Praxis ist es oft umgekehrt.
Drittens: Was im Artikel fehlt, weil es kein .NET-Problem ist.
Die wirkliche Frage in KMU-Projekten ist nicht „wie initialisiere ich TagHelpers global?", sondern: „Wer pflegt das, wenn der ursprüngliche Dev weg ist?" Ein Initializer, der im DI-Container registriert ist und magisch Properties setzt, ist für einen neuen Entwickler erstmal unsichtbar. Er sieht ein data-version im HTML, sucht im View — findet nichts. Sucht im TagHelper — findet keine Zuweisung. Sucht in Program.cs — findet sie, wenn er Glück hat und weiß, wonach er sucht.
Das ist keine Kritik an dem Pattern, sondern ein Argument dafür, es sparsam einzusetzen und an einer zentralen Stelle zu dokumentieren. Nicht als Kommentar im Code, sondern im CLAUDE.md, im ADR, im Confluence — wo auch immer dein Team seine architektonischen Entscheidungen ablegt.
Meine konkrete Empfehlung
Nutze ITagHelperInitializer für genau einen Anwendungsfall, der sich in KMU-Projekten immer wieder bewährt: App-Metadaten, die du im HTML brauchst und die sich nicht request-spezifisch ändern.
Das sind Dinge wie: - App-Version und Build-Nummer (für Support-Tickets) - Umgebungsname (Staging vs. Production, damit Mitarbeiter wissen, was sie gerade sehen) - Feature-Flags, die beim Start der Anwendung fixiert sind
Für alles, was sich pro Request oder pro User ändert, ist der ViewContext im Initialize-Aufruf der richtige Weg — aber dann empfehle ich, das explizit zu benennen und im Code einen kurzen Hinweis zu hinterlassen, warum das so gelöst wurde. Nicht für dich. Für den nächsten Entwickler in drei Jahren.
Und wenn dein Team noch keine Custom TagHelpers einsetzt: Das hier ist kein guter Einstieg. Fang mit einem einfachen TagHelper an, der etwas Sichtbares tut — ein Alert-Banner, eine Badge-Komponente. Wenn das sitzt, macht der Initializer-Mechanismus plötzlich Sinn.
Der vollständige Original-Beitrag von Khalid Abuhakmeh: Initialize ASP.NET Core TagHelpers with Shared Data
Hast du ein ASP.NET Core Projekt, bei dem du ähnliche Fragen hast — oder generell das Gefühl, dass technische Entscheidungen in deinem Team nicht sauber dokumentiert oder weitergegeben werden? Dann lass uns reden.
— Bernhard