Shawn, thank you for this amazing video. I was already familiar with the ISourceGenerator interface as well as with the MVVM Source Generators, but you managed to quickly introduce me to the IIncrementalGenerator interface and how to use it instead of the deprecated ISourceGenerator interface. This has been clear, concise and straight to the point with an easily understandable use case.
Hi Shawn, thanks for your videos. Would generating classes from a database schema be a use case for source generators? So, read the schema from a database and generate classes from it. Thanks!
I'm surprised the example you created compiled without specifying either the fully qualified name of the List or adding the using statement to the top of the generated file.
The not putting the name is a .NET 6 feature lol (2 years old) as for the using there’s a thing called global usings and List is a part of the standard global usings so maybe look up features more often or use newer versions instead of those old versions which lost support ages ago
@@patfre Global using statements are fine for an example (such as the example shown by Shawn) but I would not recommend it when building a library as the feature may not be enabled in the consumers project settings. I also find your "lost support ages ago" statement perplexing. Nothing is my original question "lost support ages ago". Last time I checked you can still specify a fully qualified name of a type. In fact libraries which generate code that I've used specify the fully qualified name of a type. It doesn't sound like English is your first language so maybe something just got lost in translation for you.
@@warrenbuckley3267 I am not saying you cannot I am saying it is a new thing where you don’t have to. Also using old versions is a security risk. Also the compiler has the usings file as it is a auto generated file by a source generator so if you upload it or give it to someone else it will still work so I don’t get your point it’s automatic so just use it you seam to the type who is really scared of change it seams
C# is the only supported output, which should not be surprising seeing as the source generator code is literally running within the C# compiler process. That said, source generators are arbitrary code and if you want your source generator to directly write files to disk nothing is going to stop you. Just don't expect those additional files to integrate smoothly into the build process. I should mention that the opposite process -- reading a non-C# project file in your source generator and using that to generate C# -- is a supported scenario.
Yeah, but you run into the issue of macros becoming C++ macros which can obuscate everything. The trick here is to allow for code generation during development not just at build time
@@swildermuth I think there is quite a difference. C++ and C# use strings to generate code. Julia is homoiconic that means the language is representable in itself - like lisp
![BRASIL vs. URUGUAY [1-1] | RESUMEN | ELIMINATORIAS SUDAMERICANAS | FECHA 12](http://i.ytimg.com/vi/-hWBAuxF1eY/mqdefault.jpg)
Shawn, thank you for this amazing video. I was already familiar with the ISourceGenerator interface as well as with the MVVM Source Generators, but you managed to quickly introduce me to the IIncrementalGenerator interface and how to use it instead of the deprecated ISourceGenerator interface. This has been clear, concise and straight to the point with an easily understandable use case.
This awesome, would love to see more video regarding some of new async constructs introduce recently in dotnet
You're a true role model for content creators.
Shawn you are the best 💖
Awesome summary Shawn.
This is gold!
Thank you great video
Great, very useful!!
Hi Shawn, thanks for your videos. Would generating classes from a database schema be a use case for source generators? So, read the schema from a database and generate classes from it. Thanks!
Is there a ready made library, that has the same interface as reflection (or as close as possible) for fetching info about assemblies, types, etc.?
Great video! But is there a link to the source code? Thanks!!!
I'm surprised the example you created compiled without specifying either the fully qualified name of the List or adding the using statement to the top of the generated file.
The not putting the name is a .NET 6 feature lol (2 years old) as for the using there’s a thing called global usings and List is a part of the standard global usings so maybe look up features more often or use newer versions instead of those old versions which lost support ages ago
@@patfre Global using statements are fine for an example (such as the example shown by Shawn) but I would not recommend it when building a library as the feature may not be enabled in the consumers project settings.
I also find your "lost support ages ago" statement perplexing. Nothing is my original question "lost support ages ago". Last time I checked you can still specify a fully qualified name of a type. In fact libraries which generate code that I've used specify the fully qualified name of a type.
It doesn't sound like English is your first language so maybe something just got lost in translation for you.
@@warrenbuckley3267 I am not saying you cannot I am saying it is a new thing where you don’t have to. Also using old versions is a security risk. Also the compiler has the usings file as it is a auto generated file by a source generator so if you upload it or give it to someone else it will still work so I don’t get your point it’s automatic so just use it you seam to the type who is really scared of change it seams
I assume we're not limited to generating C# code right? Could we also generate type serialization schemas or stuff like that?
C# is the only supported output, which should not be surprising seeing as the source generator code is literally running within the C# compiler process. That said, source generators are arbitrary code and if you want your source generator to directly write files to disk nothing is going to stop you. Just don't expect those additional files to integrate smoothly into the build process.
I should mention that the opposite process -- reading a non-C# project file in your source generator and using that to generate C# -- is a supported scenario.
@@GumbootMan well, that makes sense, still better than a extra post build step.
Uff cool feature in general but have you looked at macros in Julia Lang? These are way easier, safer and simpler to understand
Yeah, but you run into the issue of macros becoming C++ macros which can obuscate everything. The trick here is to allow for code generation during development not just at build time
@@swildermuth I think there is quite a difference. C++ and C# use strings to generate code. Julia is homoiconic that means the language is representable in itself - like lisp
Github link???
what are these generators for? what can they be useful for?
For anything, really. For example, to replace reflection or to generate boilerplate code.
If you want to use native AOT, you have to use source generators as reflection is not allowed since the trimming will not work.
best example is new boilerplate of Program.cs since .net6.0
You could write your entities instead of using T4 templates (.tt) for example.
I wrote one that generates interfaces and IOC registration code for my injected services.
🤔