Brad Wilson
Kirill Osenkov@bradwilson @xunit instead of Roslyn source generators you can have a regular MSBuild code generator that generates code during the build, and it can be any code and support C# and F# equally well. I often find that people use Roslyn source generators when all they want is any code generator.
Miha Markič@KirillOsenkov @bradwilson @xunit What would be the difference against Roslyn ones? (besides support for F#). A cons is probably not running during design time?
@mihamarkic @bradwilson @xunit yes, not running on every keystroke in the IDE and not having access to the compilation and syntax trees/documents/semantic models
@KirillOsenkov @bradwilson @xunit So, basically, here are raw .cs files and do what you want during build?
@mihamarkic @bradwilson @xunit sure, or any other inputs you need. Granted, Roslyn Source Generators are great when you need to understand the .cs files, but in many cases I've seen them abused to just generate .cs files out of say .xml or .json, without the need to understand .cs. If you want to generate C# you may not need source generators, but if you want to read or understand C# you probably need them (unless you host Roslyn yourself and pay the perf penalty of reading the project twice)
Mikayla H@KirillOsenkov @mihamarkic @bradwilson @xunit re. build time source generation without Roslyn generators, check out https://mhut.ch/journal/2015/06/30/build-time-code-generation-in-msbuild and https://mhut.ch/journal/2016/04/19/msbuild-code-generation-in-vs2015
Build Time Code Generation in MSBuild
Build-time code generation is a really powerful way to automate repetitive parts of your code. It can save time, reduce frustration, and eliminate a source of copy/paste bugs. This is something I’m familiar with due to my past work on MonoDevelop’s tooling for ASP.NET, T4 and Moonlight, and designing and/or implementing similar systems for Xamarin.iOS and Xamarin.Android. However, I haven’t seen any good documentation on it, so I decided to write an article to outline the basics.
@mhutch @KirillOsenkov @mihamarkic @xunit I think in my case I'm going to need Roslyn because I need to inspect the source to do the generation (the simplest explanation is: I need a list of all methods in the project that are decorated with an attribute, so that I can bypass the need to find them via reflection at runtime, in order to support NativeAOT). I'm certainly going to investigate every option, though!
@mhutch @KirillOsenkov @mihamarkic @xunit (this time posted from the correct account 😂)
Funny historical fact: Jim and I created xUnit.net while working on CodePlex, so we were obviously the first internal adopters, but the first team outside of us that adopted xUnit.net internally was... Roslyn!
@bradwilson @mhutch @mihamarkic @xunit or perhaps you can run a task after Csc and reflect over the output binary at build time, then serialize your findings. This way you can support F# too.
@bradwilson @mhutch @mihamarkic @xunit remember to save the assembly MVID so you know when to invalidate
@bradwilson @KirillOsenkov @mihamarkic @xunit
My post was targeted at generating source code based on files that are not source code, e.g. generate serialization wrappers for a json file or something. Doing it this way has similar perf and complexity as Roslyn generators, and if you use CodeDOM you can support every language with a CodeDOM provider.
@bradwilson @KirillOsenkov @mihamarkic @xunit
Generating code for your assembly *based on code in your assembly* is much more difficult. You can use a two pass compile and reflection, or parse the source code yourself, but both these options really hurt build perf and are difficult to get right.
Generators are by far the best way to handle this but are Roslyn only. AFAIK there is no good solution to this class of problem that supports all languages.
@bradwilson @KirillOsenkov @mihamarkic @xunit
FWIW, generators also only solve the problem of letting you inspect parsed/resolved code and inject source code text into the compilation. There isn't actually any mechanism for generating the source code text. Personally, I would use either preprocessed T4 templates or CodeDOM for the actual generation part of a generator.
@bradwilson @KirillOsenkov @mihamarkic @xunit
If I were to implement code-dependent generation logic for both Roslyn and non-Roslyn languages, I would have two-pass compile targets for non-Roslyn languages with a reflection-based generator task, and have a generator for Roslyn languages. These would convert the Roslyn/reflection data into a shared model, then use a shared implementation to process that data and generate code via CodeDOM.
Not elegant, but I can't think of anything better 😞