I want to see if it's possible to replace runtime reflection in @xunit v3 with #Roslyn source generators (for better performance and to support NativeAOT), but I think I've already hit the first blocking point: no support for #FSharp? Only #CSharp and #VB? #dotnet
@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.
@bradwilson@xunit hmm I don't know enough about your usage, and how you were planning to use Source Generators, just wanted to point out that in many cases where you don't really need to analyze the C# source you can get by without Roslyn. But in your case having access to the compilation and syntax trees might be required I think?
@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
@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)
@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!
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.
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.
Add comment