StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I noticed that using <a href="http://msdn.microsoft.com/en-us/library/aa347733.aspx" rel="nofollow noreferrer"><code>svcutil</code></a> instead of <code>Add Service Reference</code> in Visual Studio leads to shorter generation times, albeit sometimes the code generated is slightly different (more on that later).</p> <p>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 <code>svcutil</code> (without any option) and the generation took only about 2 minutes.</p> <p>I had to add some options to match the same characteristics configured in the service reference (<code>/enableDataBinding</code>, <code>/serializable</code>, <code>/namespace:*,myns</code>, <code>/syncOnly</code> and <code>collectionType:System.ComponentModel.BindingList'1</code>) 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.</p> <p>In my experience the two generation methods have some differences that I'd like to point out:</p> <ul> <li><p>Visual Studio generates <code>datasource</code> files (the one generated by Visual Studio when adding an object datasource to a Windows Forms project, see also <a href="https://stackoverflow.com/questions/1439364/what-are-the-wcf-service-reference-datasource-files">this SO thread</a>); <code>svcutil</code> 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 <code>datasource</code> files since they are not included in the assembly and they will be regenerated anyway.</p></li> <li><p>the <code>ConfigurationName</code> 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 <code>app.config</code>. This however can be managed easily by changing the <code>app.config</code> to match the new value or by (automatically) changing the <code>ConfigurationName</code> property in the generated proxy source.</p></li> <li><p><code>svcutil</code> does not decorate the <code>ExtensionData</code> property with the attribute <code>Browsable(false)</code> -- 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 <code>ExtensionData</code>. Like the previous hiccup, this can be handled by adding the attribute using a <code>sed</code>-like tool (for example, I used the PowerShell snippet contained in this <a href="https://stackoverflow.com/a/9682594/753737">answer</a>).</p></li> </ul>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload