This took us few hours to resolve – after few changes in the project, the “Update service reference” operation invoked from within the Visual Studio in a Silverlight application ends with no errors but the sole content of the created proxy class is just the preamble:
//------------------------------------------------------------------------------ // <auto-generated> // This code was generated by a tool. // Runtime Version:4.0.30319.1 // // Changes to this file may cause incorrect behavior and will be lost if // the code is regenerated. // </auto-generated> //------------------------------------------------------------------------------
No namespace, no class, no code, just the preamble.
It seems that there’s an issue somewhere between the slsvcutil.exe (the tool used to create Silverlight proxies) and Visual Studio. After hours lost on searching for the real issue, it finally turned out that the default service reference option, “Reuse types in … referenced assemblies”, forces Visual Studio to append a list of “/reference:<filepath>” to slsvcutil.exe (which is invoked by VS on create/update reference).
What happens next is slsvcutil.exe tries to load all listed assemblies and when an assembly references another assembly which cannot be resolved, the slsvcutil.exe ends with a nice error message “Could not load file or assembly …”.
However, when invoked from the Visual Studio, for some unknown reasons this error message is swallowed and you end up with no error message but no code generated for your proxy class.
1 comment:
This might explain the problem/solution in more detail:
http://marktinderholt.wordpress.com/2010/02/12/silverlight-wcf-service-reference-weirdness-solved-custom-tool-error-failed-to-generate-code-for-the-service-reference-%e2%80%98servicereference1%e2%80%99-please-check-other-error-and-warnin/#comment-109
Post a Comment