Bei der Entwicklung einer Webapplikation kommt es ständig vor, dass UI-Teile immer und immer wieder verwendet werden. Damit nicht immer Copy & Paste verwendet werden muss, können diese Teile in Komponenten zusammengefasst werden.
Jahrelang gab es kein Framework von Microsoft, mit dem es möglich war, webbasierte Cross Plattform Applikationen zu erstellen. Und dann kam Blazor WebAssembly. Im ersten Teil dieser Screencast-Serie wird erklärt, worum es sich bei Blazor WebAssembly handelt.
Mit der Veröffentlichung von .NET 6 hat Microsoft nicht nur neue Features und Performance-Verbesserungen umgesetzt, sondern uns auch ein neues Entwicklungsmodell für Web-APIs bereitgestellt.
Hinweis: Alle Code-Beispiele sind auf Github verfügbar!
Das Blazor Framework von Microsoft gibt es inzwischen in drei „Geschmacksrichtungen“. Die erste ist Blazor WebAssembly, die zweite Blazor Server, und zu guter Letzt gibt es noch Blazor Hybrid. In diesem Artikel wollen wir uns die zwei „echten“, also Browser-basierten, Web-Anwendungs-Szenarien WebAssembly und Server anschauen.
This article is the 3rd part of a series about Roslyn Source Generators & co. In the 1st article, of this series, we built an Incremental Source Generator to generate a new property Items of a Smart Enum. In the 2nd article, we added a Roslyn Analyzer and a Code Fix to prevent common mistake(s) and to help out the developers when using this Source Generator. All the code we have written so far was tested manually by executing the code and looking at the outcome. It is time to implement some automated tests to ensure the correct behavior.
This article is the second part of a series about Roslyn Source Generators & co. In the previous article we built an Incremental Source Generator that extends a custom class by creating and initializing the new property Items. This new property returns all items of a Smart Enum. Although the Source Generator is fully functional, I still don’t consider the current state as ‚finished‘. During implementation of the Source Generator, we made several assumptions, which means the developers must know the internals to use it properly. If the author of the Source Generator is the only consumer of this tool, then we can leave it as it is. If not, then it would be a bold decision to expect others to have the same knowledge as the author. In this case, I highly recommend adding a Roslyn Analyzer to guide the developers in the right direction.
The Roslyn Source Generators, which came with the .NET 5 SDK, are probably one of the best features in the last few years. They allow us to improve the way we share code today by generating it on-the-fly during development instead of shipping fix set of components, helpers and base classes relying heavily on Reflection. With .NET 6 SDK, Microsoft gave us Incremental Roslyn Source Generators for more efficient and resource-saving implementation of Source Generators.
Logdateien zu schreiben erscheint auf den ersten Blick trivial. Auf den zweiten Blick auch noch. Und irgendwann sitzt man dann doch da, und debugged seinen eigenen Logging-Code, während man in den dazugehörenden Logdateien die erwarteten und erhofften Informationen zum Fehler einfach nicht findet. Damit Ihnen das nicht passiert, habe ich hier ein paar Ideen, Stolperfallen, Anregungen und Best Practices zum Thema Logging in .NET zusammengeschrieben.
Mit der Einführung von async/await in C# 5 (2012) wurde das asynchrone Programmieren auf Basis von Tasks deutlich einfacher. Nebenläufigkeit ist allerdings grundsätzlich kein einfaches Thema, und wenn die Reihenfolge der Ausführung nicht mehr rein sequenziell ist, passieren schlimme Dinge können.
Thinking and even recommending a monolithic architecture these days seems antiquated. While a microservices architecture clearly has its benefits, it also comes with drawbacks. Sometimes these drawbacks can be more significant than the benefits and might hinder your development, time-to-market, or your ability to maintain your application.
