I have a Windows UWP client application that needs to call a REST API hosted by my ASP.NET service. To generate my client proxy I use the following Visual Studio option...
Right click project -> Add -> REST API Client...
I provide the URL of the swagger endpoint and it generates the expected client code. But the downside is it generates all the classes even though in my case I have a shared class library that has all the server side classes defined. This is a pain because the generated classes do not respect the inheritance of my class hierarchy and flattens everything into non-inherited classes.
Is it possible to get AutoRest to reuse an existing .NET library for classes instead of always generating new classes? This was an option when I used the WCF client proxy generator.
It seems like Add REST API client doesn't have advanced setting for reusing. But Add REST API client has two ways for loading metadata file, swagger URL and existing metadata file. By testing on my site, it should be able to update an existing metadata file and to remove or adjust the nodes that you don't want be generated. And then load the updated existing metadata when adding REST API client.
The classes generated may be determined by the metadata json file and the host value. You may also try to submit a request here to see if swagger team can keep the hierarchy when generating the meta file. Or you may need to manual create the proxy to reuse the libraries.
I think it would be fair to describe the "REST API Client" generation tool in Visual Studio as "spartan".
This answer may be too late to help you, or there may be reasons why you can't use a different tool, but in the hope of benefiting you and/or future readers I'll detail how I achieved generating a REST client in NSwagStudio which reuses my existing classes and enums. (NSwagStudio is free and open source, and I have no affiliation).
On the left hand pane, we select our input. Besides the expected Swagger feeds there are some interesting options such as "Web API via reflection" which "uses .NET reflection to analyze ASP.NET Web API or ASP.NET Core controllers" - this is the option I used but my screenshot shows the default Swagger input.
On the right hand pane, click "CSharp Client" and switch to the "CSharp Client" tab.
The magic bullet is to untick "Generate DTO types":
This will cause it to generate only the client, so you can reuse your existing DTOs.
You'll want to specify a namespace for the client, and optionally one or more namespaces which will be added to the generated C# file as using directives. For example, if you want your client to be in the namespace MyNamespace and your model classes are in SomeOtherNamespace you'd enter the following:
It's well worth having a play with the options. A few quick notes about some of the defaults and why I'm happy with them:
The HttpClient is injected and you control the lifecycle (which seems to me a good thing)
A BaseUrl property is defined. I haven't tested this yet but I'm hopeful from looking at the generated code that this will allow me to safely spin up multiple instances of the client class to talk to multiple servers which share the same API
The JsonSerializerSettings property is protected, but can be configured via the UpdateJsonSerializerSettings partial method
I've saved my settings from the File menu and added the .nswag file to source control, so that I can easily regenerate the client in future if necessary.
Related
We are transitioning a WCF based solution over to use gRPC.
We require both the Service and Client code generation that the Grpc.Tools package provides. However, we need the Clients to target .NET Standard 2.0 for comparability reasons.
Services need to call other services, so those projects need to be able to consume both the service stubs and the client stubs.
We also don't really want the service stubs to be exposed to consumers just wanting to use the gRPC clients.
This is proving a challenging requirement to satisfy.
Trial 1:
Have two projects, both importing the same proto files, each set to generate either the Server or Client.
Problem: A consuming project can't reference both server and client project due to the generated messages having duplicate namespaces.
The C# namespace is defined in the proto file itself.
Trial 2:
Separate the proto files out into messages and services. Have a models project which only generates the messages into code.
Have the client and service projects reference the models project, and import the services proto files to have them generate the stubs they need.
Problem: gRPC generates the stubs inside of a static class, which again has the same namespace in both projects so a consumer is unable to determine which version to use.
I now have two routes I can go down.
Option A:
In both the client and server projects, create classes which inherit from the gRPC generated ones so they can be exposed onto a different namespace.
For the services, this isn't so bad. The clients however have two constructors and a instance generation method which would need to be brought over to the child class.
Option B:
Create duplicate proto files for the service definitions, one having a namespace for the service stub and the other having the namespace for the client stub.
Both options have their downsides. Option A is probably the least bad as it doesn't require two files to be manually kept in sync.
Does anyone have any alternative recommendations?
Ideally there would be a way to alter the namespace defined in the proto files somehow when using Grpc.Tools, but reading the documentation, there doesn't seem to be a way to do that.
I have a web api that others are using, and one of our developers changed the name of the action method or method parameter. Now the client has a problem. Is there any solution that, before deploying to the production server, check whether there have been changes in the existing public api (not adding new api)?
I would highly recommend creating a Swagger OpenAPI Specification for your API if you're going to be sharing your API with other teams. A Swagger definition is a specification that describes how your API looks like in terms of actions, expected input, output, etcetera. You can use such a specification as a contract between the producer and all consumers of your API.
Then, you can use tools like Swagger CodeGen to generate clients and server implementations, as a guarantee that an implementation conforms to the contract. In your case, this would prevent a developer from breaking the API (unless they change the contract as well).
If you want to collaborate, I recommend placing (a copy of) your Swagger definitions in a separate GIT repo (e.g. my-awesome-contracts), give all the teams access to this repo and make any changes through pull requests. This serves two purposes:
It gives all the consumers of your API an early notice on any changes
you're planning to make.
It allows any consumers to actually give feedback on the proposed changes.
I have an asp.net/Blazor VS solution with three projects,
Shared
asp.net core apis
Blazor webassembly.
I created bunch of classes in Shared project and from the other two projects, made a reference to the Shared project. All is good so far.
Then I used Swagger UI to generated stubs for me so I can interact with the remote APIs. Swagger UI created the Service.cs and Contract.cs which is great. The problem is that Contract.cs has redefined the classes that I have declared in Shared projects under it's own namespace. Now I don't know which to use and which to import. If I use my own Shared classes, then I won't be able to use the APIs from swagger in Service.cs without casting. If I modify Contract.cs, then all my changes will be lost the next time I run Swagger UI.
This also resulted in having two DBContext - 1) the one I defined and 2) The one that swagger defined. Now every time I want to do something, I also have to use --context parameter on the command line to specify which DBContext to use.
The question is how can I use my own classes yet use swagger to make life easy in terms of talking to the remote APIs? What is the best practice here?
When you want to use Swagger (client side) then you shouldn't reference the Shared project. The swagger claases is what you get/want then.
But you don't need Swagger in Blazor. The opportunity to share DTO classes in Shared is one of the highlights of Blazor.
If you want some help with the boilerplate stuff on the Client then there are options like refit. See this blog about it.
I generated the client code from a for OData V4 service (Dynamics 365 metadata) using the OData V4 Client Code Generator project template (https://marketplace.visualstudio.com/items?itemName=bingl.ODatav4ClientCodeGenerator).
The code was generated fine and it compiles. Now the problem is that I simply cannot find a way to make a connection (or context) that can be used when querying data (OData linq queries for example).
All the examples I've read basically just "start right away" with having a Context or a Resource available, but none of them actually specify why or how it's there.
For example https://blogs.msdn.microsoft.com/odatateam/2014/03/11/tutorial-sample-how-to-use-odata-client-code-generator-to-generate-client-side-proxy-class/ shows how to generate the classes and then creates an instance of NorthwindEntities (or XxxxEntities) which, again, I don't have generated (I don't have anything named "Entities" in the generated code).
https://stoneridgesoftware.com/working-with-the-odata-endpoint-in-dynamics-365-for-operations/ just simply creates a new instance of Resources class, which I don't have (what is it?). I have nothing named Resources in the generated code.
Obviously it can't be this difficult so maybe I'm missing something.
EDIT: the generated class contains only classes Crmbaseentity, CrmbaseentitySingle, ExtensionMethods and then the entity classes themselves. There simply are no other classes.
Any ideas how to do this differently or any blog posts that I've missed?
The problem was that I used the code generation template from https://github.com/Microsoft/Dynamics-AX-Integration/tree/master/ServiceSamples/ODataUtility. When I added the OData service to the project as a "service refernce" and used the wizard, then the code was generated normally.
I still don't know the actual reason why the T4 template didn't work.
I have a Silverlight app I've been working on. This app relies on a custom class called Customer. Instances of this class are returned from my web service. I've need to add a method called CalculateLoyalty() to this class definition. I want CalculateLoyalty to be available on both the server and client-side (my Silverlight app).
Currently, I can use CalculateLoyalty just fine on the server. Unfortunately, the method doesn't seem to get passed across the wire. I have a hunch its some serialization thing. How do I add a method to my class definition on the server-side and ensure that it is available on the client-side?
Thank you!
When you generate a service reference, it only copies public properties and fields. You can share classes between your server and client and avoid using a service reference. I'm not going to go into detail with how to do this, but here are some related questions that explain what needs to be done.
Create WCF Client without auto generated proxy
Call synchronous WCF operation contract methods asynchronously on silverlight
Even if you do this, I have to recommend against putting logic on your DTOs. I'd recommend creating a LoyaltyCalculator class and passing a Customer to this. In fact, you can do this even if you use generate your client through the Add Service Reference option.
Your defult Silverlight solution will have 2 projects.
MyApp - This is your Silverlight project.
MyApp.Web - This is the host web project.
You don't need to do this, but I recommend adding 2 new projects.
MyApp.Shared - A .NET Class Library
MyApp.Shared.Silverlight - A Silverlight Class Library.
At this point, you will want to add a project reference to the appropriate class library to both your Silverlight project and your Web project.
Add class LoyaltyCalculator to MpApp.Shared, or MyApp.Web if you don't want to make the shared libraries. Go ahead and implement this class here.
Now in MyApp.Shared.Silverlight, or MyApp if you don't want to make the shared libraries, select Add -> Existing Item. Browse to and select LoyaltyCalculator.cs. Do Not Double Click It!!! Instead, click the little down / more arrow on the Add button. Now select Add As Link.
LoyaltyCalculator is now available to both your server and client and you only have to maintain one copy.
Methods are not serialized, only data (property/field values) are, so you must be using a different version of the .cs file on the server than you are on the client. Are you sharing the source code between your web service and silverlight projects?
If you are on .NET 4.5/VS2012, you may be able to create a "Portable class library" with your class in it that can be referenced from both your .NET and Silverlight projects.