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!