Why should I use Visual Studio service references over svcutil?

Question

So it seems like I have a couple of major options when getting WCF service proxy code into a project in Visual Studio:

1. Use Visual Studio's built-in tooling for Service References

2. Use a simple svcutil command, something like svcutil http://[my endpoint] /namespace:[my namespace] /noconfig (since I use some fairly standard bindings across projects), and drag the resulting file into my project (or upgrade in place).

To be clear, option 2 feels like the best one, albiet with no built-in tooling for updating. But the Service Reference dialog generates like a zillion files. Is there any obscure benefit to VS Service References that I'm missing?

Disafforest

They are basically the same thing. – Preempt

Visual Studio basically calls svcutil behind the scenes. Lots of programmers however are afraid of opening up a command prompt and running a command-line tool - that's why Visual Studio has the Add Service Reference dialog .... – Blue

Yeah I knew they were the same under the covers, but is it using some /awesome switch to generate all of those XSDs and other files to some benefit? – Disafforest

So this was originally all about why VS service references add all those other crazy files (disco and the like) but these answers and a little googling lead me to believe there isn't really a compelling benefit. So...we'll be sharing proxies and/or contracts around via NuGet – Disafforest

Possible duplicate of "Does Visual Studio 2008 Use SvcUtil.exe and if “No” is there any disadvantage to using svcutil?" #408717 – Fredi

I have an urgent problem related to this question. How do things work when using WF4 workflow service 'Add Service Reference'? Does svcutil really get invoked behind the scenes? I can't see how the XAMLX activities are generated by svcutil. I need to find out more because I am running into a bug with WF4 WF Service project Add Service Reference against 3rd party WSDL – Core

Answer 1

If you also own the service, I'd say don't use either one. Instead, break up your contracts, entities, and client proxies into different assemblies that you can use both on the service and the client.

Kinda like described in WCF The Manual Way... The Right Way.

Whiskey

I've heard this in lots of places, and I think it's even in an iDesign doc somewhere (and maybe is a separate question), but don't I then also need a heavyweight management strategy around downloading and updating those assemblies? I've done svn:externals and thought about NuGet for this, but other than ease-of-update (and svn:externals is almost too easy to sneak code into a build unexpectedly), I'm not sure what I buy other than slightly-more-DRY code. – Disafforest

If you own all the code, this should be no problem. You don't have to reference assemblies; you can reference the same projects the service references. Every time you build, your client will be updated as well. – Whiskey

Answer 2

Same reason why you build a .net project with VS and not calling the compiler by hand from command line. The I of IDE stands for Integrated, it does things for you so you do not need to do those things manually from many separated places and procedures.

There is usually a way to do many of those things by hand or with a text editor and command prompt but lets be productive :-)

Punt

Agreed on UI tooling v. command line. So are you saying usability is the only benefit? – Disafforest