tags:

views:

76

answers:

4

There is two way to create WCF proxy in client side

1. Generating proxy by adding Service Reference
2. By using ChannelFactory.CreateChannel method like this

ChannelFactory<IMyContract> factory = new ChannelFactory<IMyContract>();
IMyContract proxy1 = factory.CreateChannel();
proxy1.MyMethod();

Which is best approach to get proxy?

And as mentioned in this article we should call proxy method like this for correct error handling

IMyContract proxy1 = null; 
try
{
    proxy1 = factory.CreateChannel();
    proxy1.MyMethod();
    ((ICommunicationObject)proxy1).Close();
}
catch
{
   ((ICommunicationObject)proxy1).Abort();
}

Should we repeat this snippet for every proxy call? Or Is there generic way to create a wrapper class for closing and aborting proxies?

Is writing class like this ServiceExecution.Execute(proxy=>proxy.MyMethod()); which creates proxy, and closes or aborts it good way to do that?

+1  A: 

In first case when you use VS to add Service Reference it generates all the code for you including ServiceContrcats and DataContracts.

But when you use ChannelFactory you must have service contracts and etc on client side already.

Incognito
I know, but generated data contracts is not comfortable to use. Assume we have 2 services the first one returns datacontrat which should be passed to second one as parameter. in this case we should copy datacontract manually,because datacontract is exists in 2 different namespaces
ArsenMkrt
You can still edit the code generated by the VS. And you can have one separated DataContract.
Incognito
Your edit will lost after any service change and proxy regeneration isn't it?
ArsenMkrt
Yes it will be lost.
Incognito
+1  A: 

I suggest using approach 1.

I've found this blog with an example including source code that also explains how to properly handle the connection (closing, aborting, etc.). The blog also contains links for more details at MSDN.

John
Blog just explains how to do it in first approach, but says nothing advantages versus the second one.
ArsenMkrt
@ArsenMkrt: Yes, you are right. I added a link to a blog entry that provides more information about the approach that I suggested in my answer. :-)
John
A: 

Manually creating the service proxies from a running service might be a good alternative. The tool svcutil is what Visual Studio uses under the hood when adding a service reference. Using this, you can generate the proxy class in a common location, and then link to it in each project you require, and also gain better control over your proxy classes.

For example, to generate a proxy for a service called TestService running locally on port 8000, you would run the following in the Visual Studio command prompt, generating a proxy class TestServiceProxy.cs in the proxies directory.

cd "C:\src\proxies"
svcutil /noLogo /out:TestServiceProxy http://localhost:8000/TestService

There are some other useful parameters for the tool, for example:

Add /n:*,WcfServices.TestService will specify a namespace for the proxy class.

Add /config:TestServiceProxy.config and svcutil will generate a sample configuration file for using TestService including endpoints, bindings etc.

Add /r:"Common.dll" and the proxy class emitted by svcutil will not have definitions for types used by the service, but defined in the assembly Common.dll.

Use svcutil /? for more information.

Benp44
`/config`: it'll generate this anyway with a default name output.config.
Rup
Not all business cases are possible with svcutil configuration, for example, is it possible to generate datacontracts in different project, servicecontract in different, and the proxy in different? there is no I guess.
ArsenMkrt
A: 

Here is an MSDN post, that recomends not to use generated proxies in .Net 3 because it creates ChanelFactory each time, .Net 3.5 ChanelFactory is cached...

ArsenMkrt