Unclear how to re-generate

[temelj]

I have successfully generated an API client using the Refitter menu option. This process generated the interface class, took a snapshot of the OpenAPI spec (the JSON), and created the Refitter configuration file.

The initial generation works perfectly. However, when I update the OpenAPI spec (the target service) and want to update my front-end web app to leverage the latest endpoints/changes, the “re-generate” process is unclear.

When I right-click on the JSON API spec, I see the following options:

• If I choose “Generate with Refitter,” neither the interface nor the JSON gets updated.

• If I choose “Run Custom Tool,” the interface gets updated, but the JSON remains unchanged.

It would be helpful to have a “Regenerate” menu option that updates both the JSON and CS files correctly, as this doesn’t seem to be the case currently.

[temelj]

I do apologise, right clicking on the *.refitter file gives the following:

Just need to check/verify that both the OpenAPI spec + interface implementation re-generate or not.

[christianhelle]

@temelj Thanks for taking the time to bring this up.

Custom Tools are executed when changes to the file are written to disk. They're designed for convenience and hide the code generation process a bit from the user. I went for this approach thinking that when there are no changes to the OpenAPI spec, there is no need to re-generate the file.

This turned out to be very wrong since the code generators used by this extension are updated upon every release and the generated output might differ every time

[temelj]

@christianhelle that was a very quick reply 😄 And thank you for the cool and very handy extension.

Your approach and assumptions make sense to me as well.
In my particular use case, the OpenAPI is updated and hosted externally to the consuming web application. The front-end application can consume multiple API services that expose their OpenAPI spec via a Swagger endpoint (.../swagger/v1/swagger.json).

So, if the front-end relies on one or more Web APIs that expose their OpenAPI spec, it makes sense in my use case that the updates to the OpenAPI occur at the service end, without requiring a developer to keep the OpenAPI spec in the web app in sync.

Based on the current approach, you first load the OpenAPI spec via the specification URL. However, after the initial load, you need to keep the OpenAPI spec in sync manually:

• make a change to the *.json file.
• custom tool kicks in and re-generates your desired *.cs file.

In addition to that "standard" workflow, you could have some sort of "update service" menu option.

I noticed that the *.refitter file points to the "internal" OpenAPI spec

 "openApiPath": "D:\\repos\\TestProj\\src\\WebApp\\ApiClients\\ExternalApiClient.json",

I changed this to point to the swagger.json and after right-clicking on the *.refitter file, re-generating actually gets the latest from the swagger endpoint instead of using the local (out-of-date) spec.

You could then set up the *.csproj file (openapi.json + *.cs) as a DependentUpon the refitter file.

There are a few options, but for now, I am happy to have this tool generate the Refit interface. It takes out manual labour, and I thank you for that! 😄

---

Regarding your second statement:

This turned out to be very wrong since the code generators used by this extension are updated upon every release and the generated output might differ every time.

I'm not sure if that's an issue, though. It would be perfectly fine (and expected) that upon a new release of the external tooling (Refit/NSwag), the *.cs file re-generates slightly differently, like the ordering of interfaces, for example. The resulting implementation and consuming code should not need to be changed unless there are known breaking changes.