We have several .Net webservices that we use a java client for. Each webservice has it's own namespace, but they all use a lot off common classes. When these are exposed as WSDLs, then generated into Java code, we get a lot of duplicates in Java of the same .Net classes.
Is there a way in .Net to define a set of WebService objects to be exported under a shared namespace (in XML)? Or can we when we use wsimport in Java to generate just one instance of each duplicate class?
From service side, one of the option could be to have specially crafted single WSDL describing all services. See this article for how to do it (applicable for asmx services).
On side note, for .NET clients, its quite simple to use wsdl tool with sharetypes options to have common types generated once and re-used among multiple service proxies. Hopefully, similar tools/options perhaps exist at java client side.
The -p option of wsimport allows you to override the namespace specified in the WSDL to a package that you specify. If you specify the same package for each WSDL you'll only end up with one instance of each class.
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 single self-contained (third party) WSDL file with say 10 operations. (server is not .net)
All operations have their own XML namespaces defined for operations, messages and all the underlying types.
Some of the underlying types in different operations have same names and sometimes same content or same structure (not always) as well but they are actually different as they are defined in different xml/xsd namespaces (so they are unique).
When I import this WSDL into my c# client project, I can give it one unique namespace in the VS porject and it generates the proxy/stub.
The problem is wherever the different operations have same (xml type) names for the underlying types then it generates the c# class names like: MyType1, MyType2...
Additionally the third party server, can update the service and so the WSDL is updated and the underlying types are generated again into .net classes like MyType1, MyType2... but this time, maybe previously generated MyType6 is generated as MyType7 and this breaks the client/consumer code.
What solution exists to address this problem?
We are thinking to customize the wscfblue code but it seem to be a cumbersome work and would require maintenance..
Environment:
-VS2013 Ultimate (Client)
-.net 4.5 (Client)
-Unknown technology (Server) -> generates WSDL and provides the endpoint.
You can generate the proxy using svcutil.exe and provide mappings from xml namespaces to CLR namespaces with /n. It also supports multiple mappings, which it sounds like you need.
Example: use svcutil to map multiple namespaces for generating wcf service proxies
I have 3 projects in my solution.
A common class library named ReportBuilderLib
A WPF application named ReportClient that contains a service reference to a 3rd project -
A WCF web service which contains web methods for my application to call upon.
Initially when setting up both the service and the application i added the common library to references on both projects so that i could use the classes i needed to in both.
It quickly cam clear that in the process of generating the code to use the web methods in my client application, it was automatically importing certain namespaces that i had used in service application.
This was throwing me conflicting reference warnings as they were effectively being imported from two separate resources.
I then removed the reference to the library in my report client, i could see that VS was only importing one out of the two namespaces my client requires. Both of which are returned by methods in my ServiceContract!
Having looked at the generated code for the client, it seems to be re-creating the classes i have included in the library and providing only the public properties for access.
Is it possible to use librarys like i am trying to with WCF. Or should i scrap the common library idea and simply create some data transfer classes on the service end?
You should be able to reference the common library on both ends, but it may be useful and less of a headache to implement data transfer classes like you suggested. Using special classes (or serialization like JSON) to send and receive data from the service would make it easier for you to re-use the service for multiple client projects.
Any time you decrease the coupling between layers of an application you make it easier to implement changes/upgrades in the future :)
I wish to use proxy objects in c#. I will probably implement the networking through Windows Communication Foundation. So far I've just made a very basic WCF service which works on different processes of on the same computer. I want the client class to be able to use the real object on the same process and use a proxy object to access the real object across the internet. Now I can manually make an interface for all the methods, I want to use across the internet, manually make a proxy class which calls a service foe each of those methods, and manually create each of those services on both the service host and service client.
However is the any way I can get WCF or any software to automatically create the interface and the proxy class?
It sounds like what you want to use is svcutil.exe, which is intended to read a service's metadata and create C# classes.
Documentation is here: http://msdn.microsoft.com/en-us/library/aa347733.aspx
and more specifically here: http://msdn.microsoft.com/en-us/library/aa751905.aspx
There are a broad (very broad!) range of options controlling the proxy classes that are generated. At its simplest
svcutil http://service/metadataEndpoint
will read the metadata and create C# classes in one go.
Alternatively, if you're using Visual Studio 2005 or above, right-click on a project, choose "Add service reference..." and follow the dialogs to generate client proxies. This allows you to easily customise the proxy classes.
Note that you will need to publish metadata of some kind for the utility to work. See here: http://msdn.microsoft.com/en-us/library/ms734765.aspx for details on enabling this.
I'm refactoring an existing C# .NET Web Service that is consumed by existing Delphi 2006 (non-.NET) clients. I don't want to rebuild/redeploy the clients. My goal is to keep the WSDL identical so that the proxy classes won't change.
I used a tool (Regionerate) to region and sort the methods/properties based on our current standards. This changed the tag ordering in the WSDL.
I can use an XML diff tool to compare the files and ignore ordering, but I'm not sure if this will affect the clients. Is order of web methods or (to-be-proxy) class properties relevant?
The order should be totally irrelevant, for the methods in the WSDL as well as for the properties in the classes.
The only way I can imagine how this would affect the clients would be if the clients didn't use standard libraries to consume the service, but did it by ways of some custom coded weirdness - and even then the implementer would have had to go some extra miles to introduce a dependency on the order ;)