I noticed that using svcutil
instead of Add Service Reference
in Visual Studio leads to shorter generation times, albeit sometimes the code generated is slightly different (more on that later).
At work we have a WCF service composed of about 100 service operations and 100 service contracts and the proxy generation in Visual Studio 2012 starting from the WSDL exposed by the service takes about 7 minutes. I then tried to use svcutil
(without any option) and the generation took only about 2 minutes.
I had to add some options to match the same characteristics configured in the service reference (/enableDataBinding
, /serializable
, /namespace:*,myns
, /syncOnly
and collectionType:System.ComponentModel.BindingList'1
) and with this option the generation time raised to 3 and a half minutes. Overall the proxy generation is not order of magnitude faster but at least the generation time should be cut in half.
In my experience the two generation methods have some differences that I'd like to point out:
Visual Studio generates datasource
files (the one generated by Visual Studio when adding an object datasource to a Windows Forms project, see also this SO thread); svcutil
has no option for generating them. It shouldn't be a major problem, since the first time you need to databind to a contract the file should be generated by Visual Studio.
As an aside, if the proxy is compiled in a separate assembly, the referring project could not reuse the generated datasource
files since they are not included in the assembly and they will be regenerated anyway.
the ConfigurationName
property of the Service Contracts can be different, apparently because the two generation methods consider differently the target namespace in generating the attribute value. This is a problem in our case since we do not use the generated app.config
. This however can be managed easily by changing the app.config
to match the new value or by (automatically) changing the ConfigurationName
property in the generated proxy source.
svcutil
does not decorate the ExtensionData
property with the attribute Browsable(false)
-- this can be a problem if (like us) you use the data contracts as source for databinding in Windows Forms, since all grids now will acquire an additional column for ExtensionData
. Like the previous hiccup, this can be handled by adding the attribute using a sed
-like tool (for example, I used the PowerShell snippet contained in this answer).