I have a Client website, a WCF service and a library of domain objects (.cproj).
I want the client to use my library of domain objects directly, not the proxy generated version of the domain objects. Is there a simple way of doing this?
Include a reference to the dll in your client project. Then add a Service Reference. When you add the service reference there is an option to use the types in the dll and not create them in the references.cs.
Include the library project or DLL in your client project rather than creating a service reference. You can generate the service reference to create all the necessary WCF configurations to call the service, but just don't use the generated proxy or datatypes (e.g. the code in Reference.cs) - use the types in the included DLL directly. You may need to write a client yourself, but this is simple, and can be basically copied from the generated client in a service reference.
That said, sharing the datatypes directly between the client and service sort of breaks service-oriented architecture patterns. Now both your client and service are dependent on the same DLL, rather than the client just being dependent on a service.
Related
I'm trying to write an application which gets the WCF address and generated a DLL from it.
Then I can pass it to another team (dev team) and they can use the DLL to call WCF methods without knowing anything about WCF Address and config.
Dev team knows about method names/contracts, they just don't want to add reference to WCF services they use and prefer to have a dll and just call the method from DLL.
I have heard about svcutil which generates a class and a config file. How can I write an application that executes svcutil and compiles the generated files in a dll, all programmatically.
Thanks.
Create, Host(Self Hosting, IIS hosting) and Consume WCF servcie
you need to self host service and this self host dll you can give to your other team.,..
check for the selfhosting of the wcf service.,.. also check above article which may help you to achieve your task
I have a WCF deployed on IIS. Now by adding web reference of it i am using it on my app.
So I have two questions:
Is it the best method of consuming WCF.
If the answer of first question is yes then what is the role of svcutil.exc, I mean what is the use of creating wcf proxy class. and if the answer is "No" then why?
It is the easiest solution if you develop with visual studio and have access the remote WCF service.
If you are developing using another IDE, you might want to use SvcUtil to generate your proxies.
If you prefer to have a simple CS file containing the generated client, you might also choose to generate it using SvcUtil.
You may also completely ignore SvcUtil and the Service Reference wizard and use the ChannelFactory class to generate proxies dynamically.
You should use "Add Service Reference" in Visual Studio (not Add Web Reference) for WCF.
It is the easiest way - since you can do it right in Visual Studio. What it does under the covers is basically call svcutil.exe (or you can do that manually, from the command line yourself), and create a service proxy class for use on the client side.
The use of svcutil.exe is many fold - you can create a client proxy class from a running service (or from an existing WSDL/XSD file), you can verify services, you can export metadata from a service for clients to consume, and a great many more options. It's the "Swiss Army Knife" of WCF tools.
WCF uses a concept that all calls to your service must go through a client proxy - this is the place where the entire WCF runtime lives, and where all the WCF extensibility points are located. This proxy converts your call to a method on the client into a serialized message that gets sent across the network to the server for processing, and it also handles "unpacking" the response from the call back into classes and objects on your client side for your use.
Adding a service reference is the quickest and easiest way but not always the best way. If you want performance then using ChannelFactory<T> is the way to go. You should know different ways to create a client side proxy and customisations that you can do.
An excellent resource is WcfGuidanceForWpf. Don't let the WPF in it scare you as it is really an excellent guidance for general WCF as well.
We currently have a WCF Service which is beginning to reach it's limits performance wise.
We have decided to add another server which will host another instance of the WCF Service.
We have web applications which must communicate with a specific server based on context... e.g. If the web application is dealing with objects from ServiceInstance1 then requests must be directed to ServiceInstance1's EndPoint. If the web application is dealing with objects from ServiceInstance2 then requests must be directed to ServiceInstance2's EndPoint.
I initially thought that a "Intermediate Service" or "Service Manager" could be created, the web application's Service Reference would be updated from the individual Service Instance to the "Intermediate Service" or "Service Manager" and said service would act as a "Broker" to the various Service Instances.
How is this accomplished?
I have currently added a ServiceReference to each service from the Manager however it seems that once a Service is "Referenced" it's types becomes specific to the that of the ServiceReference e.g.
ServiceInstance1's type's are all {ServiceInstance1}.
ServiceInstance2's type's are all {ServiceInstance2}.
I need the types to be the same on the web application end, so this obviously seems like the wrong way to do it.
I would also like that when methods are called on the client generated from referencing the "Intermediate Service" or "Service Manager" that the correct Service Instance is invoked, e.g.
IServiceManager.GetProjectById( {GUID} ) ->
Comes Back to ServiceManager ->
Determines which host has the project and returns the ProjectObject from the correct ServiceInstance.
Where ProjectObject is a Type Defined in ServiceInstance1 and ServiceInstance2.
I think the original service needs to have some of the DLL's pulled out so they can be referenced from the web application side and ServiceManager and a GenericWCF Client can be made.
If I am right hooray for me If someone can point me in the right direction I would appreciate it. If I am wrong can someone please scold me and show me how this is properly done!
The way to solve your problem is to create shared assembly with types used by both services. Reference this assembly on the client consuming your services (manager) and when creating proxies by Add service reference mark Reuse types from referenced assemblies.
What you are building is very simple message router. In WCF 4.0 there is additional support for routing services so you should check those features before developing your own. For WCF 3.5 MSDN magazine contains articles about building message router - part 1, part 2.
Just to Answer this and close it I wound up utilizing the Routing Strategy in .Net 4.0 and custom client class which I modeled after the generated classes from the Proxy.
Before I had the custom client ready I used the auto generated client code and I derived a class from it which allow me to change which service it was connecting to. I determined which service via a property which was made available on all service objects which were serialized.
Long story short this is working 100% as expected including the ServiceManager which can even be bypassed on certain calls which we allow.
We even have the ability to move a project from server to server during run time!
Thanks to everyone who helped! (Especially myself for actually doing the work without being spoon fed)
The easiest way to accomplish what you're trying to do is to stop generating your proxies using the server-hosted URL of the service. Instead, generate your proxies from the *.xsd and *.wsdl locally, and merely change the URL of the endpoint. Alternatively, you can use ChannelFactory<T> to generate proxies on-the-fly, and reference your interface .dll on the client side.
Once you've done that, you can use any common webserver load balancing technique to balance the load between the servers.
Not to put too fine a point on it, but Visual Studio's "Service Reference" is not useful, and should not be used, for services you develop. It's useful only for services developed externally, whose URL and contracts are likely to NEVER change. I personally have never had occasion to use it. For your own services, you should probably be using ChannelFactory<T> or a class based on ClientBase<T> to work out the proxies.
I have a windows workflow foundation 4 service and a simple client.
When I add the service reference in the client visual studio doesn't generate a proxy class,
only the interface and types.
Anybody have any solution?
What should I do to work with the wf4 service properly? What kind of namespace and classes and contracts I need to use?
Thanks!
When the client project is a workflow project type setting a service reference works a bit different. Instead of generating the standard proxy classes it generates Send & ReceiveReply activities for use on a workflow. Very nice if you are building a workflow, not so when you want to call the service using regular code.
You can either use SvcUtil manually to generate your proxy classes or use the ChannelFactory with the generated interface to create the required proxy object. The last is usually the easier option.
Is it possible to add a service reference in visual studio, which generates the local proxy class to call the WCF service when using the netTcpBinding?
As I understood it, the service reference method requires a WSDL to be exposed by the service, which is only supported by the http bindings no?
Perhaps, could I add the service reference locally in development, but then switch the configuration to use nettcp at runtime in production?
The reason I am asking is because I am hosting in a windows service (server 2003, so no WAS, and can't use IIS). And we are unable to change the permissions to do the HTTP namespace reservation ... so we can't use the HTTP bindings. NetTcp works, but in this specific case the object graph we're passing back and forth involves objects generated in the service by an EDMX model ... so we can't share it in a contract assembly.
Thanks in advance!
Simply add a binding using mexTcpBinding.
Is it possible to add a service reference in visual studio,
which generates the local proxy class to call the
WCF service when using the netTcpBinding?
Yes, most definitely!
As I understood it, the service reference method requires a WSDL
to be exposed by the service, which is only supported by the http bindings no?
No, definitely not - WCF metadata (either its own specific format, or exposed as WSDL / XSD files) is definitely available for all SOAP-based calls - regardless of their transport.
Can you show us what you have, in terms of server-side config? Most likely, you're just missing a little config setting or something - if we see what you have, we might be able to pinpoint that and help you more!
All bindings are exposed though WSDL. If you add the NETTCP bindings svcutil will atuo generate the client correctly. I haven't used it in the ADD reference in VS as i have always preferred to generate the class with svcutil.