Project-based Roslyn generators for C# (no CLI)?

[atrauzzi]

Is your feature request related to a problem? Please describe the problem.

When working with kiota, any time I make a modification to the input OpenAPI definition requires that I run the command to regenerate the SDK.

Client library/SDK language

Csharp

Describe the solution you'd like

It would be interesting to see kiota support generating source code within the project based on some properties in my .csproj.

Additional context

This would make creating an SDK even more seamless for developers. All they'd have to do is set up the correct configuration in their projects, compile and publish as nuget. 💥

It also eliminates one dependency -- at least for C# developers. Although source generation is huge in the JVM space as well. I've used some pretty neat GraphQL source generators in the past and it was a joy.

[baywet]

Hi @atrauzzi
Thank you for using kiota and for reaching out.

This is something we have already explored a couple of years ago as a deep integration with the dotnet client tooling. See #3815 for more context.

As it stands now, it's unlikely we'll make a source generator a "first party" option. But there are existing community projects and should you decide to build one, kiota ships as a library as well

Let us know if you have any additional comments or questions.

[atrauzzi]

Hmm. I'd only say that deferring this is almost guaranteed to be a miscalculation.

I'll try to speak briefly as to why, but first, none of this is intended to ignore the quality of kiotas output! As the creator of the other ticket you linked even says, it's pretty good. I also really like the pluggability.

The reason I say "miscalculation" is because when (not if) someone does make an incremental generator, kiota will be abandoned en masse. At least if historic FOSS migration patterns are anything to go by. 😆
(That's ignoring the fact that there's a lot of established convention to use other OpenAPI generators too.)

I don't know how such an inevitability aligns with the mandate this library has, but it does beg a bit of an existential question. Both from a maintainer and an adopter perspective.

Anyway. I mean this in the most boring way I can get away with online. Assuming you accept this rationale, you should be doing the exact opposite and dedicating all your resources towards this missing functionality rather than trying to ignore it.

[baywet]

Thank you for the additional information.

Have you tried the community project I have linked?

[atrauzzi]

I hadn't, but only because there's a note that it's "currently not working" in the notes and of course I'd - as would anyone - be wary of taking on a package that hasn't been touched for two years.

I am however trying to set things up such that I can provide kiota with an HttpClient instance provided by dapr. It's proving difficult as kiota seems to require several HttpMessageHandlers to be registered, and that API has a very confusing lifecycle.

Still trying to sort out what goes where and when. 😵
(Happy for any tips! For example, are the HttpClientMessageHandlers I'm reading about here necessary for kiota to function?)