tags:

views:

521

answers:

2

Hi All,

I have a self hosted TCP based WCF service. I am now building a project that consumes that service, but there seems to be at least two ways of adding a service reference to a project and the both produce wildly different proxies. First I used the "Add service reference" from the project menu, but this generated quite a few files and even some XML schemas of the core .Net types. Then I tried the SvcUtil which only produced two files, one proxy and one config file that holds the service reference and binding parameters, this is much better but...

In both cases the VS tools seem to reproduce type definitions even though I have provided a reference to the assembly containing the service and all the types it uses. For example, some of my service methods return generic collections of Entity classes. All the Entity classes are defined within an assembly that I have directly referenced from the consuming project so why redefine those types again?

I would be grateful if some body could offer some advice on consuming WCF services that return Entity types and any best practices they follow.

Thanks.

James

+2  A: 

We have found that the add service reference creates alot of unneeded code that gets in the way more than it helps.

We have gone over to a manual way of setting it up, there is an introduction to this method here:

http://perseus.franklins.net/dnrtvplayer/player.aspx?ShowNum=0103

Shiraz Bhaiji
Yes - but again - that *ONLY* ever works in a scenario where you control *BOTH* ends of the communication, and use .NET and WCF on both ends. If that's the case - excellent way of doing it! But just remember - this is a very limited scenario in the "real world".
marc_s
Thanks really good video, anyone developing WCF services should watch this first, the VS tolls are terrible.
James
+1  A: 

Yes, in your concrete case this may seem like duplication - but consider this: WCF is also designed to be interoperable, and in MOST scenarios, especially if you have a non-.NET client calling your code, you won't have the assembly with the contract and the interfaces available.

So there's really nothing BUT creating a full proxy, that contains all that information, in order to work in all possible circumstances.

Now if you really want to avoid duplication of data contracts etc., you can compile those into their own assembly, and then use the /r:(assembly name) switch when calling svcutil to tell it to re-use the code and contracts in that assembly.

Marc

marc_s