Nobly.OnBaseRestApiClient 1.3.13

Modify and publish NoblyOnBaseRestApiClient

1. Check out OnBaseRestApi master branch and generate new client with NSwag.
2. Check out OnBaseRestApiClient master branch, create a new branch from it and replace \OnBaseRestApiClient\NoblyOnBaseRestApiClient\ApiClient.cs with the freshly generated ApiClient.cs.
3. Build NoblyOnBaseRestApiClient.
4. Increment version numbers in NoblyOnBaseRestApiClient.csproj (normally one minor version greater than greatest minor version on GitHub).
5. Update NoblyOnBaseRestApiClient ReadMe (this file), with the new version as title, with new features and other important changes in this version.
6. Commit the newly created NoblyOnBaseRestApiClient branch to GitHub and merge into master.
7. Create Git tag on the commit of NoblyOnBaseRestApiClient master branch with the version set in the .cproj file (e.g. git tag -a 1.3.12)
8. Publish NoblyOnBaseRestApiClient to a folder.
9. Publish generated NoblyOnBaseRestApiClient package generated in that folder to nuget (e.g. dotnet nuget push Nobly.OnBaseRestApiClient.1.3.12.nupkg -k xxxxxxxxxxxxxxxxxxxxxx -s https://api.nuget.org/v3/index.json) (Ask password, xxxxxxxxxxxxxxxxxxxxxx, for publishing to nuget of a colleague).

To generate a new ApiClient in NSwag:

1. Install NSwagStudio.
2. Double-click \OnBaseRestApiClient\NoblyOnBaseRestApiClient\generate client.nswag to open it in NSwagStudio.
3. Fire up OnBaseRestApi and go to its swagger page.
4. Copy the https://localhost:{port}/openapi/v1/openapi.json URL.
5. Paste this URL into Inputs->Specification URL and click Create local copy.
6. Click CTRL+S to save generate client.nswag file.
7. In Output->CSharpClient->Settings->Output file path, write the output path, e.g., C:\repro\OnBaseRestApiClient\NoblyOnBaseRestApiClient\ApiClient.cs.
8. Click Outputs->Generate Outputs for a preview, and then Generate Files in order to save the generated API client to file.

Important note:
Client methods are susceptible to change since NSwag will only include the HTTP method in client names when there is a name conflict, e.g., if there is a GET and a POST method with the same route.
So, if there is no signature conflict for a method and another endpoint is added with the same signature but a different HTTP method, the original client method name will change, i.e., it will subsequently include the HTTP method in its client method name.
E.g. if only a GET method exists for the endpoint Document, this would generate a DocumentAsync client method, but if a POST method with the same route were added, the DocumentAsync client method name would change to DocumentGetAsync.
This means that method signatures in a newly generated client should always be compared to the ones in the existing client to detect whether any client method signatures have changed.
Changed method signatures will need to be modified accordingly in any consuming code.

v.1.3.8:

• Method name ApiDocumentsNotesAsync changed to ApiDocumentsNotesGetAsync.
• Method name ApiDocumentsHistoryAsync changed to ApiDocumentsHistoryGetAsync.

v.1.3.9:

• Added method ApiWorkViewSqlObjectsWorkViewsAsync

v.1.3.12:

• Added method ApiWorkViewSqlObjectsSearchAsync
• Added method ApiWorkViewSqlObjectDeleteAsync
• Method ApiWorkViewSqlObjectsGetAsync was marked as obsolete
• Method ApiWorkViewSqlObjectsPostAsync was marked as obsolete