There are a couple situations where one might use svcutil.exe in command prompt vs. Add Service Reference in Visual Studio.
At least a couple.
I don't know who (or why) made a decision not to support namespace-less proxy generation in Visual Studio. It's a fact that if you make a service reference, you have to specify a nested namespace.
On the other end, there is an option to make the proxy class either public or internal, which enables one to hide it from the outside world.
That's a design flaw. There are numerous cases, where you would not want to create another [1] namespace, because you are designing an object model that needs to be clean.
[1] This is only limited to local type system namespace declarations - it does not matter what you are sending over the wire.
Consider the following namespace and class hierarchy that uses a service proxy (MyNamespace.Service class uses it):
Suppose that the Service class uses a WCF service, which synchronizes articles and comments with another system. If you use Add Web Reference, there is no way to hide the generated service namespace. One would probably define MyNamespace.MyServiceProxy as a namespace and declared a using statement in MyNamespace.MyService scope with:
using MyNamespace.MyServiceProxy;
This results in a dirty object model - your clients will see your internals and that shouldn't be an option.
Your class hierarchy now has another namespace, called MyNamespace.ServiceProxy, which is actually only used inside the MyNamespace.Service class.
What one can do is insist that the generated classes are marked internal, hiding the classes from the outside world, but still leaving an empty namespace visible for instantiating assemblies.
Leaving only the namespace visible, with no public classes in it is pure cowardness.
Not good.
Since there is no internal namespace modifier in .NET, you have no other way of hiding your namespace, even if you demand internal classes to be generated by the Add Service Reference dialog.
So, svcutil.exe to the rescue:
svcutil.exe <metadata endpoint>
/namespace:*, MyNamespace
/internal
/out:ServiceProxyClass.cs
The /namespace option allows you to map between XML and CLR namespace declarations. The preceding examples maps all (therefore *) existing XML namespaces in service metadata to MyNamespace CLR namespace.
The example will generate a service proxy class, mark it internal and put it into the desired namespace.
Your object model will look like this:
Currently, this is the only way to hide the internals of service communication with a proxy and still being able to keep your object model clean.
Note that this is useful when you want to wrap an existing service proxy or hide a certain already supported service implementation detail in your object model. Since your client code does not need to have access to complete service proxy (or you want to enhance it), it shouldn't be a problem to hide it completely.
Considering options during proxy generation, per method access modifiers would be beneficial too.