I have a Windows Service Solution and am trying to add a service reference to a Hermes(Opensource ebms message server) Web Service in VS2010.
I can find the Web Serv
http://uliasz.com/2011/06/wcf-custom-tool-error-failed-to-generate-code-for-the-service-reference/#comment-1647
Thanks to the article above.
In my case, i have this issue with my WPF project in VS.Net 2008. After going through this article, i was realizing that the assembly used in the web service is different version of assembly used on client.
It works just fine after updating the assembly on the client.
I have encountered this problem when upgrading a VS2010 WCF+Silverlight solution in VS2015 Professional. Besides automatically upgrading from Silverlight 4 to Silverlight 5, the service reference reuse checkbox value was changed and generation failed.
If you want to correct this without uncheking the assembly reuse checkbox this is what worked for me:
I had this problem when trying to update my service reference (The error only shows up when adding a service reference though) but didn't want to remove the assembly reuse checkbox.
What worked for me was the following:
Voila, now it actually updates and doesn't try to remove all of my generated code anymore.
I was almost ready to give up on the re-use types feature...
EDIT: Also make sure that the build config is AnyCPU or x86, since svcutil is buggy with x64.
To the downvoter: Sorry if it didn't work for you, I don't even know why it worked for me, but it did. I may have done something else that time that fixed the problem, but no way to know now.
Have to uncheck the Reuse types in all referenced assemblies from Configure service reference option
Check this for details
As stated above, there are a couple of different problems possible. What we found is that the .DLL for the WCF library had been added as a reference to the client project. This, in turn, created problems with resolving the objects and thus caused the files to be "emptied" by code generation steps. While unchecking the use "Reuse Types..." can seem like an answer, it creates extra definitions of object types, which are proxies to the real types, in a new name space, which then causes all kinds of "compatibility" issues with the use of those types. Only if you really want to "hide" a type should you check this option.
Hiding the type would be appropriate when you don't want a "DLL" type dependency to "leak" into a project that you are trying to keep segregated from another. If the DLL for the WCF library project creeps into the client project references, then you will have this problem with all kinds of strange side effects since the type definitions are also in the DLL.