VS2010 Updating Service Reference *crazy* Slow (like 5 minutes)

our team is starting to dread u开发者_如何学JAVApdating the service references in our solution because it's a 5+ minute investment. Everything is localhost inside Visual Studio's web server.

My question is - how can I debug what this problem is? It works fine once it is over, but the long delay is crazy. If I had a clue where to look, perhaps I could resolve this.

With VS2012, I ran into the same issue: it took me almost 10 minutes just to update one service reference. I just managed to fix this by re-adding the service in the following way:

• Delete the service reference.
• Right-click "Service References" and select "Add Service Reference".
• Click "Discover" (required in my case, might be different for others).
• Select the service that you want to add under "Services".
• Give the service a name (under "Namespace" at the bottom").
• Press "Advanced".
• Uncheck "Reuse types in referenced assemblies" and press "OK".
• Press "OK" to add the Service Reference.

For me, the reusage of types was the big issue: now that this is unchecked, new updates only take a few seconds. Since I couldn't find this solution anywhere else, I thought I'd just post it here in case others run into a similar issue.

More than likely the .suo files have gotten ridiculous due to constant refreshes. You can check this by examining the source. If this is the case, you can delete the .suo and update the reference. You might want to make a backup, just in case you forgot some other user settings you have.

The other option is the WSDL for the service has just gotten too damned large and you have to bite the bullet.

If you want to reduce the impact, get the service guys to nail down the contract by using a little known secret called planning. ;-) Honestly, poor planning is often the root cause for a lot of the issues that crop up in VS.

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).

I faced this same problem just now, and updating my service reference was taking around 10-15 minutes sometimes it failed to update. I was frustrated and finally I deleted the reference and then added it once again. And now everything is working fine.

So, I will suggest you to delete the reference and add it again and lets see what happens

Had a slow problem updating webreferences. I was crasy about the times. More than 1 hour.

Some co-worker told to to add my workspace path to exclude from Windows Defender and it solve my problem.