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.

@@GumbootMan well, that makes sense, still better than a extra post build step.

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

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.