Die Arena Cinemas in Sihlcity, Zürich, wurden am 26. August 2025 erneut zum Zentrum für Entwickler, Architekten und Technologie-Enthusiasten. Cudos war als Sponsor mit dabei und wir haben die Teilnehmerinnen und Teilnehmer mit über 300 erfrischenden Cudos-Apfelschorlen versorgt.

Die unabhängige Technologie-Konferenz bot eine einzigartige Gelegenheit, die neuesten Trends und Innovationen zu Themen wie .NET, .NET Core, C#, ASP.NET Core, Azure und mehr zu entdecken. Namhafte Speaker teilten ihr umfangreiches Fachwissen und ermöglichten interessante Einblicke in die Microsoft-Softwareentwicklung. Neben den Vorträgen bot der .NET Day Switzerland auch zahlreiche Gelegenheiten für regen Austausch und Networking mit Gleichgesinnten.

Auch in diesem Jahr waren Entwickler von Cudos vor Ort. Um das Beste aus der Konferenz herauszuholen, besuchten sie verschiedene Sessions. Stefan und Matthias haben ihre persönlichen Highlights für euch zusammengestellt.

Stefans Highlights

Zum zweiten Mal durfte ich am .NET Day Switzerland teilnehmen. Wie schon im vergangenen Jahr hat mich die Themenvielfalt beeindruckt, von Performanceoptimierung über Sicherheit in Webanwendungen bis hin zur effizienten Entwicklung mit KI. Auch der Austausch mit anderen Entwicklerinnen und Entwicklern ist immer sehr spannend. Im Folgenden habe ich zwei meiner persönlichen Highlights zusammengefasst.

How We Build an Open-Source Cross-Platform Framework in .NET

Martin Zikmund hat in seinem Vortrag über den Komilationsvorgang im Uno-Platform-Projekt berichtet. Er erklärte zuerst, wie die modernen SDK-Stil-.csproj-Dateien so umgewandelt werden, sodass msbuild diese wie das alte Format versteht. Legacy .csproj-Dateien hatten viele GUIDs, ähnlich wie heute .sln-Dateien, und insbesondere einen Eintrag für jede Source-Datei im Projekt. Diese werden von der gewählten SDK wieder nachgefüllt.

Anschliessend zeigte Martin, wie Uno eine eigene SDK benutzt, die in diesem Zwischenformat plattformspezifische Dateien aufgrund von Konventionen aus der Kompilation entfernt: So wird zum Beispiel Clock.windows.cs nicht mitkompiliert, wenn Linux, Android, MacOS, iOS oder WASM angezielt sind. Martin hat auch vorgeschlagen, dass diese Technik benutzt werden kann, um Debug- und Release-Builds zu unterscheiden.

Er ist zudem kurz auf Source-Generators eingegangen und hat gezeigt, dass diese sehr flexible Möglichkeiten zum Erstellen von plattformspezifischem Code bieten.

.Net Core Testing: pushing the limits

Guillaume Saint Etienne hat seinen Beitrag mit der wohlbekannten Testpyramide eröffnet und sich dann der Frage gewidmet, was überhaupt die «Units» in Unit-Tests sind. Wie so oft sei die Antwort, dass es auf die Situation ankommt. So ähnlich ist dies auch im Blog von Martin Fowler beschrieben. Von da hat er auch übernommen, dass er weniger zwischen Unit- und Integrations-Test die Grenze zieht, sondern eher zwischen abgeschiedenen und umgänglichen Tests (im englisch O-Ton: solitary, bzw. sociable) unterscheidet.

Mit der Benutzung vom Testing-Framework xUnit hat er schrittweise komplexere Tests-Szenarien erstellt und damit anschaulich gezeigt, wie xUnit mit Fixtures, async und Auf- sowie Abbaulogik funktioniert. Kulminiert ist das mit dem Testen einer Web-Applikation, die vom Framework erstellte Container benutzt und von einem Playwright-gesteuerten Browser angesprochen wurde.

Link zum Repository mit den Beispiel-Tests
Link zu den Slides

Persönliches Fazit

Auch dieses Jahr, fand ich die Vielfalt an Vorträgen und anderen Leuten, die mit .NET entwickeln, super. Es hat sich für mich einmal mehr gezeigt, dass .NET eine extrem flexible Plattform mit Lösungen für die verschiedensten Anforderungen ist.

Matthias’ Highlights

Zum zweiten Mal durfte ich am .NET Day Switzerland teilnehmen. Wie schon im vergangenen Jahr hat mich die Themenvielfalt beeindruckt – von Performanceoptimierung über Sicherheit in Webanwendungen bis hin zur effizienten Entwicklung mit KI. Auch der Austausch mit anderen Entwicklerinnen und Entwicklern war wieder sehr bereichernd. Im Folgenden habe ich zwei meiner persönlichen Highlights zusammengefasst.

Modern Web Applications Require Modern Security

Der Vortrag von Damien Bowden bot einen klaren, praxisnahen Leitfaden für moderne Authentifizierung und sichere APIs. Seine wichtigste Empfehlung: keine eigene Anmeldelogik entwickeln, sondern etablierte Identity Provider einsetzen. Wenn möglich, sollten Passkeys wie FIDO2 oder WebAuthn genutzt werden. Sie sind weit verbreitet, den Nutzenden vertraut und resistent gegen Phishing.

Für die Authentifizierung rät Bowden zu OIDC (OpenID Connect) und OAuth 2.1, wann immer möglich. Die gesamte Authentifizierungslogik sollte konsequent im Backend liegen. Nur das Backend verwaltet die JSON-Web-Tokens; das Frontend hält lediglich ein HttpOnly-Cookie, das ausschliesslich innerhalb derselben Origin gesendet wird. Damit sinkt das Risiko von Cross-Site-Scripting und Cross-Site-Request-Forgery erheblich. Besonders empfehlenswert sind DPoP-gebundene Token (Demonstrating Proof of Possession) , da gestohlene Tokens ohne den passenden kryptografischen Nachweis wertlos bleiben.

Für Logins eignet sich der OIDC Code Flow mit PKCE (Proof Key for Code Exchange), idealerweise mit Client Assertions statt Shared Secrets. Gängige Identity Provider wie Microsoft oder Google stellen hervorragende OAuth-Bibliotheken bereit, mit denen sich einfache Szenarien schnell umsetzen lassen. Wer mehrere Anbieter mit unterschiedlichen Verfahren integrieren will, sollte die Grundkonfiguration manuell vornehmen. Zur zusätzlichen Härtung empfiehlt sich OAuth PAR (Pushed Authorization Requests): Der Ablauf wird serverseitig gestartet, ohne sensible Daten im Browser preiszugeben.

Zum Abschluss ging es um den Schutz von APIs. Allein auf ein internes Netz zu setzen, reicht nicht mehr. Auch API Keys, Basic Auth oder Passwort Grants sind als alleinige Absicherung nicht empfehlenswert. Stattdessen sollte der Zugriff über Access Token erfolgen. Darüber hinaus zeigte Bowden, wie sich API-zu-API-Kommunikation mit Delegation Token und der OAuth 2.0 Token Exchange sicher gestalten lässt.

Turbocharged: Writing High-Performance C# and .NET Code

Steve Gordon lieferte eine präzise Anleitung, wie man Leistungsoptimierungen in .NET systematisch angeht. Sein Rat: nicht mit Bauchgefühl starten, sondern mit klaren Zielen und konsequentem Messen. Im Fokus stehen Ausführungszeiten, Durchsatz (z. B. Requests pro Sekunde) und Speicherallokationen, die über GC-Pausen die Performance direkt beeinflussen. Der bewährte Kreislauf lautet: Messen, gezielt optimieren, erneut messen. Konkret bedeutet das:

• Produktionsmetriken und Tracing einsetzen, um Hot Paths zu identifizieren
• CPU- und Speicher-Profiler wie Visual Studio, PerfView oder JetBrains-Tools nutzen, um Ursachen zu finden
• Mit reproduzierbaren Mikrobenchmarks unter realistischen Release-Bedingungen, etwa mit BenchmarkDotNet, Optimierungen überprüfen und Änderungen gezielt umsetzen

Schnelle, robuste Verbesserungen lassen sich häufig mit Span<T> und ReadOnlySpan<T> erzielen. Sie bieten typsichere und nahezu kostenfreie Sichten auf zusammenhängenden Speicher. Mit Slicing lassen sich in konstanter Zeit Teilbereiche abbilden – ohne Kopien. Spans sind ideal für String- und Byte-Verarbeitung, da sie keine unnötigen Duplikate erzeugen. Da Span ein ref struct ist und nur auf dem Stack existiert, eignet es sich nicht für asynchrone oder Heap-Szenarien. Dort kommt Memory<T> ins Spiel: funktional sehr ähnlich, aber Heap-fähig. Für allokationsarme String-Operationen sind String.Create, TryFormat und sourcegenerierte Regex besonders nützlich.

Für temporäre, häufig benötigte Puffer empfiehlt sich ArrayPool<T>, um sie zu mieten statt ständig neu zu erzeugen. Bei hohem Durchsatz in der Ein- und Ausgabe bietet System.IO.Pipelines eine effiziente, gepoolte Pufferverwaltung sowie asynchrones, kopierfreies Lesen und Schreiben.

Leitplanken für die Umsetzung:

• Nur die tatsächlichen Hot Paths optimieren, nicht «Nice-to-have»-Code
• Kopien vermeiden: Slicing statt Duplizieren; in asynchronen und Heap-Kontexten Memory<T> verwenden
• Puffer über ArrayPool<T> managen; bei Netzwerk- und Stream-I/O auf Pipelines setzen
• Änderungen klein und gezielt halten und jede Annahme mit Benchmarks belegen

Der Lohn dieser Disziplin sind weniger GC-Druck, stabilere Latenzen, höherer Durchsatz – und oft sogar geringere Infrastrukturkosten. Entscheidend ist, dass jede Verbesserung messbar bleibt und sich im Produktivbetrieb bestätigt.

Persönliches Fazit

Nach meinem zweiten Besuch beim .NET Day Switzerland kann ich sagen, dass ich jeweils neue und spannende Erkenntnisse mitnehme und meinen Horizont in der .NET-Welt erweitere. Manche Vorträge hätten aus meiner Sicht noch mehr in die Tiefe gehen können, was zum Teil aufgrund der begrenzten Zeit nicht möglich war. Insgesamt war es jedoch faszinierend zu sehen, wie sich .NET kontinuierlich weiterentwickelt, und ich freue mich darauf, das Gelernte in der Praxis anzuwenden.

Hier findest du den Bericht vom letztjährigen Event.