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.
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 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 :)
There seem to be two ways to instantiate WCF service proxies described here. My question is why would one want to use the ChannelFactory to instantiate a WCF proxy and what are the benefits of this approach?
I've met people with a strong opinion on the second option but I cannot manage to understand a clear argumentation from them
If you are using assembly-sharing (which is, let's face it, hugely convenient if you own both ends of the pipe), then both ends already have a complete version if the interface etc. It seems redundant to run the svcutil tool (at command-prompt or via the IDE) just to get back a wrapper for what we already have. It also works very well when you want to code only to an interface, not to the wrapper class - and use some centralised code to get a channel to a particular interface at a given address. This is actually how I mainly use WCF.
The "client" approach works well for one-off services, or where it doesn't need to go through any central tooling. It also makes for very simple demos.
The first option uses configuration settings provided in the web.config / app.config files to instantiate a proxy, however in certain situations its not feasible to put these settings in that file, for example if your application needs to use a different binding (maybe HTTP vs Named Pipes) depending on the scenario, or possibly your application may not even have a .config file.
The second option gives a lot more flexibility when creating proxies to programatically specify the configuration to use for each proxy as you instantiate it.
To give a more concrete example, supposing you wish to use Named Pipes for communication if communicating with the local machine, and HTTP if communicating with a remote host:
if (UseNamedPipes())
{
EndpointAddress address = new EndpointAddress("net.pipe://localhost/Simple/BankService");
return ChannelFactory<IBank>.CreateChannel(new NetNamedPipeBinding(), address);
}
else
{
EndpointAddress address = new EndpointAddress("http://localhost:8000/Simple/BankService");
return ChannelFactory<IBank>.CreateChannel(new BasicHttpBinding(), address);
}
One of the specific cases would while developing any office add-in or visual studio add-in projects where you don't have the app.config file.
Also , lets say in an organisation where you want to standardise on certain bindings and certain endpoint security patterns. you would want to create an API which developers can easily use to create a proxy, in this case you would encapsulate all the binding information using channelfactory.
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.
I have an application which consumes both a WCF service and an ADO.NET Data Service. Types are shared between the server and client using a shared class library.
When I configure the service reference for the WCF service, I can choose to use the existing types in the class library to avoid creating duplicate types in the proxy classes.
But Visual Studio doesn't offer me the option to do that on the ADO.NET Data Service.
Is it possible for an ADO.NET Data Service to reuse existing types?
Great question.
Yes this is definitely possible.
I just put together a Tip that show you how to turn off default Code-Gen and reference an existing type instead, and showing how too tell the DataServiceCpntext how to do the mapping between the type expected on the wire and the type used on the client.
NOTE: that even though the Types might be the same inside the DataService and on the client it is still possible that the Data Service has been configured to expose the Server types in a different namespace, so this mapping may still be required.
Anyway I'm sure Tip 52 will help you get your scenario working.
Alex
Way i would do is instead of creating proxy through add service option.
Use DataServiceContext directly
then can use
Execute<TypeOfData> method