Earlier this year, around //build — some NuGet packages shipped. One of which is named AutoClient. It relies on a source-generator, emitting interface implementations and DI hooks for REST API HTTP clients, check it out:
:dotnet: #dotnet :csharp: #csharp
🤓 #sourcegenerator
https://www.nuget.org/packages/Microsoft.Extensions.Http.AutoClient
#dotnet #csharp #sourcegenerator
Сегодня снова решил попробовать поконтрибьютить в open source: https://github.com/patrickklaeren/AutoRegisterInject/pull/3
Проект реализует автоматическую генерацию метода регистрации классов в DI контейнере за счет атрибутов. Сначала сам хотел такое написать, но когда увидел, что подобное уже есть, то решил попробовать помочь по мере сил.
#dotnet #opensource #codegenerators
https://it-irokez.ru/small-posts/294/
#dotnet #SourceGenerator
#dotnet #opensource #codegenerators #sourcegenerator
I'm working on a #dotnet #SourceGenerator (IIncrementalGenerator) and I need to not only look at the assembly referencing the SG, but also a referenced Assembly.
How can I best achieve this?
For better understanding: I have Project A, Project B and Project SG (IncrementalGenerator). Project A references Project B and Project SG. Project B has the classes where I want to generate based of.
Hat schon mal jemand darüber nachgedacht, dass #roslyn #sourcegenerator im Grunde genommen die bessere #aop ist? Klassische aspektorientierte Entwicklung versteckt sich im Hintergrund und injiziert meist Code auf IL-Level, während die Source Generatoren den Quellcode bereits während der Entwicklung generieren und innerhalb des Projektes auch sichtbar machen. Ergebnis: Du siehst genau, was passiert und brauchst Dich nicht zusätzlich auf die Dokumentation verlassen müssen. Ein tolles Beispiel ist das #nuget Paket CommunityToolkit.MVVM. Sehr zu empfehlen... achja: Habe ich erwähnt, dass ich dazu gerade einen #dotnetmaui #fachartikel schreibe?
#roslyn #sourcegenerator #aop #NuGet #dotnetmaui #Fachartikel