Connect with us

Entwicklung & Code

Neu in .NET 9.0 [28]: Feature-Flags


Mit der neuen Annotation [FeatureSwitchDefinition] kann man Bezug auf eine vom Namen her selbst gewählte Projekteinstellung in der Projektdatei nehmen und für bedingte Kompilierung sorgen. Das bedeutet, dass beim Einsatz von Trimming/AOT der Programmcode für deaktivierte Features nicht übersetzt wird.


Der Dotnet-Doktor – Holger Schwichtenberg

Der Dotnet-Doktor – Holger Schwichtenberg

Dr. Holger Schwichtenberg ist technischer Leiter des Expertennetzwerks www.IT-Visions.de, das mit 53 renommierten Experten zahlreiche mittlere und große Unternehmen durch Beratungen und Schulungen sowie bei der Softwareentwicklung unterstützt. Durch seine Auftritte auf zahlreichen nationalen und internationalen Fachkonferenzen sowie mehr als 90 Fachbücher und mehr als 1500 Fachartikel gehört Holger Schwichtenberg zu den bekanntesten Experten für .NET und Webtechniken in Deutschland.


Online-Konferenz betterCode() 10.0 am 18. November 2025

Online-Konferenz betterCode() 10.0 am 18. November 2025

(Bild: coffeemill/123rf.com)

Das Programm steht fest: Auf der Online-Konferenz betterCode() .NET 10.0 am 18. November 2025 – ausgerichtet von iX und dpunkt.verlag in Kooperation mit IT-visions.de – präsentieren der Autor dieses Artikels, Dr. Holger Schwichtenberg, und weitere Experten die wichtigsten Neuerungen. Frühbuchertickets sind im Online-Shop erhältlich.

Im konkreten Beispiel funktioniert das so: Wenn der Feature-Switch "ColorPrinting.IsSupported" auf false steht, wird die Methode Print() beim Trimming entfernt, denn sie wird lediglich an einer Stelle aufgerufen, bedingt von der Eigenschaft IsSupported in der Klasse ColorPrinting.


using System.Diagnostics.CodeAnalysis;
using ITVisions;
 
namespace NET9_Console.FCL90
{
 public class ColorPrinting
 {
  [FeatureSwitchDefinition("ColorPrinting.IsSupported")] // liest Wert aus RuntimeHostConfigurationOption
  internal static bool IsSupported => AppContext.TryGetSwitch("ColorPrinting.IsSupported", out bool isEnabled) ? isEnabled : true;
 
  /// 
  /// Code, der ggf. bei Trimming/AOT entfernt wird, wenn ColorPrinting.IsSupported=false
  /// 
  internal static void Print(string s) 
  {
   CUI.Print(s, ConsoleColor.Yellow);
  }
 }
 
 /// 
 /// [FeatureSwitchDefinition] für Entfernen von Code bei Trimming/AOT
 /// 
 class FCL9_FeatureSwitches
 {
  public void Run()
  {
   CUI.Demo(nameof(FCL9_FeatureSwitches));
 
   Console.WriteLine("ColorPrinting.IsSupported=" + ColorPrinting.IsSupported);
 
   // Bedingung auf Feature Switch
   if (ColorPrinting.IsSupported)
   {
    // Dieser Aufruf und damit die ganze Methode Print() wird beim Trimming entfernt, wenn ColorPrinting.IsSupported=false
    ColorPrinting.Print("Ausgabe in Farbe");
   }
   else
   {
    CUI.Print("Keine Farbe");
   }
  }
 }
}


Folgendermaßen aktiviert man obiges Feature durch einen Eintrag in der Projektdatei. Jetzt wird die Methode Print() in der Klasse ColorPrinting beim Trimming nicht entfernt:



Screenshot mit farbiger Ausgabe

Screenshot mit farbiger Ausgabe

Wenn das Feature aktiviert ist, erscheint der Text farbig.

Folgendermaßen deaktiviert man obiges Feature durch einen Eintrag in der Projektdatei. Jetzt wird das Trimming die Methode Print() aus der Klasse ColorPrinting entfernen:



Screenshot mit nicht farbiger Ausgabe

Screenshot mit nicht farbiger Ausgabe

Wenn das Feature deaktiviert ist, erscheint der Text nicht farbig.


(rme)



Source link

Verwandte Themen:
Weiterlesen
Kommentar schreiben

Leave a Reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Entwicklung & Code

Mein Scrum ist kaputt #136: Doing Agile vs. Being Agile


Immer wieder sagen Teams in Unternehmen, dass sie jetzt agil arbeiten. Sie wollen nun mutig sein und in Iterationen arbeiten, eine offene Fehler- und Feedbackkultur leben, die Commitments einhalten und stärker fokussieren und ihre Kunden natürlich besser einbinden. Zu Beginn sind sie hoch motiviert, ihre Arbeitsweise und Projekte nach den agilen Werten und Prinzipien umzustellen. Allerdings stoßen die Teammitglieder schnell an die Grenzen des Agil-Seins.

Aber warum bleibt das Being Agile oft eine schöne Idee, während das Doing Agile im Alltag untergeht? Warum redet man so oft über Werte und Prinzipien, aber vergisst, wie man sie konkret umsetzt? Und warum läuft trotz agiler Transformation immer noch alles wie vorher? Ina Einemann hat Agile Coach Daniel Otten zu Gast. Zusammen gehen sie unter anderem auf diese Fragen ein.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externer Inhalt geladen.


Agile Leadership Conference 2025

Agile Leadership Conference 2025

(Bild: Katsiaryna/stock.adobe.com)

Das Programm der zweitägigen Agile Leadership Conference 2025 steht fest: Der Leadership Day (27.11.25) behandelt das Führen von Teams und Organisationen, während sich der Self Leadership Day (3.12.25) mit Selbstführung und dem aktiven Selbst als Führungskraft beschäftigt.


(mdo)



Source link

Weiterlesen

Entwicklung & Code

software-architektur.tv: Open-Source-Komponenten rechtssicher verwenden | heise online


Kaum ein Softwareprojekt kommt heute noch ohne Open-Source-Teile aus. Wie kann man solche Komponenten im Projekt rechtlich und technisch richtig einsetzen? Welche Auswirkungen haben Lizenzen mit einem Copyleft? Was gilt es in Bezug auf Compliance zu beachten? Gerade der EU Cyber Resilience Act bringt das Thema wieder auf die Agenda.

Prof. Dirk Riehle ist Professor für Open-Source-Software und diskutiert diese und andere Fragen in Eberhard Wolffs Videocast. Weitere Informationen über den heutigen Gast finden sich auf dessen Website.

Lisa Marie Schäfer malt dieses Mal keine Sketchnotes.

Livestream am 4. Juli

Die Ausstrahlung findet live am Freitag, 4. Juli 2025, von 13 bis 14 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat, Bluesky, Mastodon, Slack-Workspace oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zur Folge finden sich auf der Videocast-Seite.


(mai)



Source link

Weiterlesen

Entwicklung & Code

Event-Driven, Teil 2: Die Bausteine von Event-getriebener Architektur


Der erste Teil dieser Serie hat gezeigt, warum klassische Architekturen wie CRUD oder REST an ihre Grenzen stoßen – vor allem, wenn die Fachlichkeit komplexer wird. Doch was ist die Alternative?


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Event-getriebene Architekturen (Event-Driven Architecture, kurz EDA) orientieren sich nicht am Datenmodell, sondern an den Vorgängen in der Domäne. Sie setzen auf ein anderes Vokabular, andere Bausteine – und führen zu einem völlig anderen Systemaufbau. Dieser Teil betrachtet die wichtigsten Elemente im Überblick.

Commands: Anweisungen an das System

Ein Command ist eine Aufforderung, etwas zu tun. Es ist ein gerichteter, imperativer Aufruf wie beispielsweise „Verleihe dieses Buch“, „Melde diese Adresse um“ oder „Überweise diesen Betrag“. Commands kommen fast immer von außen, etwa aus einer Benutzeroberfläche, einem anderen System oder einem automatisierten Prozess.

Wichtig ist dabei zu beachten, dass ein Command an sich noch keine Garantie dafür ist, dass etwas geschieht – sondern nur der Versuch, etwas auszulösen. Ob ein Command gültig ist, entscheidet die Domäne: Das System prüft, ob das Command erlaubt ist und ob die fachlichen Bedingungen erfüllt sind.

Events: Was passiert ist

Events sind die Folge von Commands. Sie entstehen als Konsequenz aus den fachlichen Entscheidungen, die beim Verarbeiten des Commands getroffen wurden.

Ein Event beschreibt daher eine fachlich relevante Tatsache, die in der Vergangenheit liegt. Es ist nicht „Bitte mache X“, sondern „X ist geschehen“. Events sind neutral, beschreibend und oft dauerhaft gespeichert. Sie bilden die zentrale Informationsquelle im System.

Passende Beispiele (zu den zuvor genannten Commands) könnten sein: „Buch wurde verliehen“, „Adresse wurde umgemeldet“ oder „Betrag wurde überwiesen“.

Events sind nicht nur nützlich für das System selbst, sondern auch für andere Beteiligte: Sie können andere Prozesse anstoßen, Systeme informieren oder Änderungen in Datenprojektionen auslösen.

Event Streams: Die Geschichte einzelner Objekte

Ein Event Stream ist die zeitlich geordnete Liste aller Events zu einem bestimmten Kontext – etwa zu einer Benutzerin oder einem Benutzer, einem Konto oder einem Buch. Er enthält nur die Ereignisse, die für genau dieses Objekt relevant sind.

Aus einem solchen Stream lässt sich jederzeit der aktuelle Zustand eines Objekts rekonstruieren. Das macht Systeme sehr transparent und nachvollziehbar: Man sieht nicht nur den Status quo, sondern auch, wie es im Laufe der Zeit dazu kam.

Projections: Leseseiten des Systems

Projections dienen schließlich der dauerhaften Abbildung des aktuellen Zustands – sie beantworten Fragen wie: „Wer hat welches Buch ausgeliehen?“, „Wie hoch ist das aktuelle Guthaben?“ oder „Was ist der letzte bekannte Wohnsitz?“.

Sie basieren ausschließlich auf den Events: Aus der Historie dessen, was geschehen ist, wird der aktuelle Zustand berechnet. Dabei kann es viele verschiedene Projektionen gleichzeitig geben – je nachdem, welche Sichten gebraucht werden.

Projections sind oft speziell auf einzelne Anwendungsfälle zugeschnitten und können effizient für Lesezugriffe optimiert werden, unabhängig von der Schreiblogik.

Wie diese Bausteine zusammenspielen

Ein typischer Ablauf in einem Event-basierten System sieht dann wie folgt aus:

  • Eine Anwenderin oder ein Anwender löst ein Command aus (zum Beispiel über eine Interaktion im UI).
  • Das System prüft, ob das Command zulässig ist.
  • Ist er zulässig, werden ein oder mehrere Events erzeugt und gespeichert.
  • Diese Events fließen in Event Streams, aktualisieren Projections, werden gegebenenfalls über Message Queues veröffentlicht und von anderen Systemen konsumiert.

Im Ergebnis erhält man eine klare Trennung von der ursprünglichen Intention (Command) und dem anschließenden Ergebnis (Event), eine transparente Dokumentation der Vorgänge und ein System, das sowohl intern als auch extern nachvollziehbar bleibt.

Was kommt als Nächstes?

Im nächsten Teil wird es darum gehen, was ein Event aus fachlicher Sicht überhaupt ist – und warum es so wichtig ist, sich dabei nicht von technischen Details ablenken zu lassen. Denn Events sind keine Logeinträge – sie sind die Sprache der Fachlichkeit.


(mai)



Source link

Weiterlesen

Beliebt