Problems using 'Add Service Reference' with the ServiceStack.Examples Project

[Matt Honeycutt]

Hi Everyone,

I've encountered a problem with using the "Add Service Reference"
dialog within Visual Studio 2010 to add a reference to the services in
the example project (ServiceStack.Examples.Host.Web). The service
shows up in the dialog, and it appears to add it correctly, but the
resulting configuration that's added to my app.config file does not
have the right endpoint addresses. Here's exactly what I did:

1) Added a new Console project to the Examples solution.
2) Used the Add Service Reference command to add a reference to the
services at http://localhost:59436/ServiceStack/Soap12 (note: I
switched the Host.Web project to use webdev server and assigned it a
static port number of 59436). The service is added to the project.
3) Checking the App.config file, I see that the endpoint addresses are
not correct. They are http://localhost:59436/ServiceStack/SyncReply.svc
and http://localhost:59436/ServiceStack/AsyncOneWay.svc, neither of
which work. Using the generated SyncReplyClient throws an
EndpointNotFoundException.

From looking at how the generated clients are used in the other
Example projects, it seems that the endpoint URL should have been
"http://localhost:59436/servicestack/soap12". Indeed, changing the
endpoint address and the security mode to 'none' works, and I'm able
to call the service.

Any ideas on why it's generating the wrong endpoint address? I know
that using the 'Add Service Reference' path isn't the "best" way to
consume ServiceStack services, but the plan is for these services to
be exposed to other apps within our organization, some of which aren't
even going to be using .NET.

Thanks for making this framework. I'm really digging it!

[Matt Honeycutt]

Oh, and I'm using ServiceStack.Examples-v2.09. While I'm thinking
about it, there was also a compile error in the example,
EndpointHostConfig.WsdlServiceTypesNamespace doesn't appear to be
defined in the binaries that come with the Example.

On Apr 8, 1:12 pm, Matt Honeycutt <mbhoneyc...@gmail.com> wrote:
> Hi Everyone,
>
> I've encountered a problem with using the "Add Service Reference"
> dialog within Visual Studio 2010 to add a reference to the services in
> the example project (ServiceStack.Examples.Host.Web).  The service
> shows up in the dialog, and it appears to add it correctly, but the
> resulting configuration that's added to my app.config file does not
> have the right endpoint addresses.  Here's exactly what I did:
>
> 1) Added a new Console project to the Examples solution.
> 2) Used the Add Service Reference command to add a reference to the

> services athttp://localhost:59436/ServiceStack/Soap12(note: I

> switched the Host.Web project to use webdev server and assigned it a
> static port number of 59436). The service is added to the project.
> 3) Checking the App.config file, I see that the endpoint addresses are
> not correct.  They arehttp://localhost:59436/ServiceStack/SyncReply.svc

> andhttp://localhost:59436/ServiceStack/AsyncOneWay.svc, neither of

[Matt Honeycutt]

A little more info:

Looking at the WSDL that was returned, the endpoints are incorrect
there:

<wsdl:service name="SyncReply">
<wsdl:port name="WSHttpBinding_ISyncReply"
binding="svc:WSHttpBinding_ISyncReply">
<soap:address location="http://localhost:59436/ServiceStack/
SyncReply.svc" />
</wsdl:port>
</wsdl:service>
<wsdl:service name="AsyncOneWay">
<wsdl:port name="WSHttpBinding_IOneWay"
binding="svc:WSHttpBinding_IOneWay">
<soap:address location="http://localhost:59436/ServiceStack/
AsyncOneWay.svc" />
</wsdl:port>
</wsdl:service>

I also noticed that the WSDL is causing the binding type to be set to
'customBinding' instead of 'wsHttpBinding'. Sadly I don't know enough
about WCF to guess as to why that's happening.

For now, I was able to specify the correct configuration code in my
App.config file manually, and it works great. :)

[mythz]

Hi Matt,

The 'SyncReply.svc' and 'AsyncOneWay.svc' was the old way ServiceStack exposed the SOAP endpoints, although that's not needed anymore as the same urls that supplies the WSDLS e.g. /servicestack/soap11 and /servicestack/soap12 are now the SOAP 1.1/1.2 endpoints themselves as they're able to accept and process HTTP POST'ed SOAP requests. So even though they're deprecated they shouldn't be showing up, it may have something to do with running on the VS.NET WebDevServer but I will investigate further to find and fix the problem.

EndpointHostConfig.WsdlServiceTypesNamespace doesn't appear to b defined in the binaries that come with the Example. 

ServiceStack originally had 2 config properties to define the WSDL and XSD namespace but they have since been merged into 1 config entry in the latest version, so I will need to update the example project to reflect this.

The other thing to note with the SOAP endpoints is that you should have all your DTO types share the same single namespace (which should match the Config.WsdlServiceNamespace), this can easily be done by using the [assembly:ContractNamespace] attribute usually defined in the DTO project's AssemblyInfo.cs file, here is how this is done in the example project.

[assembly: ContractNamespace("http://schemas.servicestack.net/types",
	ClrNamespace = "ServiceStack.Examples.ServiceModel.Operations")]
[assembly: ContractNamespace("http://schemas.servicestack.net/types",
	ClrNamespace = "ServiceStack.Examples.ServiceModel.Types")]

https://github.com/ServiceStack/ServiceStack.Examples/blob/master/src/ServiceStack.Examples/ServiceStack.Examples.ServiceModel/Properties/AssemblyInfo.cs

I'm glad you've got your SOAP endpoints to work and we're aware that SOAP is an important endpoint in external enterprise integration web service scenarios point of view where political pressures are going to keep SOAP a living standard in the years to come which is why we maintain built-in support for it.

Having said that we believe SOAP is an unnecessary complex and bloated technology standard that generates friction and inhibits productivity when iteratively developing web services. It actually makes your services less accessible since your client effectively needs a SOAP client to access your service rather than just a url and a HTTP client (which every language has) which is all you need to access when accessing the service over REST urls and POX/POJ (Plain old XML/JSON formats). SOAP also violates the HTTP standard where all SOAP web service requests are HTTP POST's which should only be used to process destructive non-cacheable requests. Because of this, it effectively disables the inherent perf and caching benefits inherent in HTTP and inhibits it's ability to be routed and mediated by proxies. Anyway there's many other reasons (e.g. code-gen, versionability, perf, etc) that makes SOAP an anti-SOA technology that even Microsoft has come to realize with the development on their new REST web services framework that aims to take full advantage and work with (as opposed to against) HTTP: http://wcf.codeplex.com/wikipage?title=WCF%20HTTP

So for this and other reasons we recommend that you encourage the use of the other endpoints when possible and use the SOAP endpoints when needed. We hope that ServiceStack's ability to have your same service easily available on both REST and SOAP endpoints will help to facilitate developers into a better and more productive web services development model.

Regards,

Demis