Feature request: Generate code for C# based off new HttpClient in .NET Core

[calloncampbell]

I see there is a feature to generate code for a particular request for C# using RestSharp. It would be nice if there was another option for C# based off the HttpClient in .NET Core.

[Sergio0694]

@dpaulino This looks like something I could help you with 😄 Would be pretty easy to add this (and other codegens) with that mustache approach I told you about.

[dpaulino]

@Sergio0694 that would be much appreciated. I've publicized a repo that contains the ICodeGenerator interface that Nightingale uses. Please feel free to create a pull request to add new implementations. https://github.com/jenius-apps/nightingale-core/tree/master/Nightingale.Core/CodeGenerators

Ideally, it would be great to have the folder structure look like this:

CodeGenerators
  `--- ICodeGenerator.cs
  `--- CSharpCodeGenerator.cs
  `--- etc

[Sergio0694]

So, I've started laying out some groundwork in my codegen branch.

For now I've setup an easy to expand layout, where new code generators, templates and tests can easily be added - they just need to follow the same naming convention as the existing codegen methods and tests. I've also added a sample implementation (work in progress) of a single request using refit, with related test. It's nowhere near complete, but it's a start.

@dpaulino we might consider either modifying the existing classes to add some "codegen friendly" properties, or introducing new dedicated types that take a WorkspaceRequest or WorkspaceCollection instance as input and prepare the data for the codegen pass, either would work, so let me know which one you prefer. By "codegen friendly" properties I mean stuff like:

• Easy access to useful values like the actual REST method in use (couldn't find it)
• Additional properties like a bool to indicate whether an item in a given collection is the first/last, which can be used for proper formatting of collection of values (eg. adding a comma between parameters in a method) Also, all these available properties should be listen in a public and easy to read schema, so that users will be able to easily see the available data in case they want to write their own templates. Because of this, we should make the available data as informative and flexible as possible, even with redundant properties. We might also discover new required properties as we go about writing templates for other frameworks - I'm familiar with refit so far so for now I've focused on that one.

[dpaulino]

@Sergio0694 sorry for taking a long time to respond. If you're still interested in helping with this issue, I've improved the codegen setup in the core repo. There's now a dedicated project for codegen: https://github.com/jenius-apps/nightingale-core/tree/master/src/Nightingale.CodeGen.

Also, all of nightingale's new data models are open source now here: https://github.com/jenius-apps/nightingale-core/tree/master/src/Nightingale.Data. The old repo for models is now obsolete.

Feel free to make modifications to the models as you see fit, and I can review any proposals here or in a pr.

[dpaulino]

@Sergio0694 can you confirm if you're still able to help with this? No worries if you can't at the moment. I just want to double check because I can un-assign you