Cannot import wsdl:portType

[daniel]

I have a clean project + ServiceStack Hello Example (installed with
nuGet). After adding service through "Add Service Reference" in VS2010
I get following error:

Warning 4 Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension:
System.ServiceModel.Description.XmlSerializerMessageContractImporter
Error: There was a problem loading the XSD documents provided: a
reference to a schema element with name 'Hello' and namespace 'http://
schemas.servicestack.net/types' could not be resolved because the
element definition could not be found in the schema for
targetNamespace 'http://schemas.servicestack.net/types'. Please check
the XSD documents provided and try again.
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://
schemas.servicestack.net/types']/wsdl:portType[@name='IOneWay'] c:
\users\administrator\documents\visual studio 2010\Projects
\WindowsFormsApplication1\WindowsFormsApplication1\Service References
\ServiceReference1\Reference.svcmap 1 1 WindowsFormsApplication1

What does it mean?

[Demis Bellot]

Right,

You need to have all your DTO's in the same namespace. You can do this globally without adding the [DataContract(Namespace=)] for all your DTOs by adding this in your AssemblyInfo.cs (you need to do this once for each namespace your DTOs are in):

[assembly: ContractNamespace("http://schemas.servicestack.net/types", ClrNamespace = "My.Namespace.Where.My.DTOs.are")]

If you want you can specify your own namespace you will need to tell ServiceStack what it is, by adding this to your AppHost.Configure:

SetConfig(new EndpointHostConfig {

WsdlServiceNamespace = "http://my.custom.ns/types"

});

Personally I would avoid the code-gen step required when generating off the WSDL (which can become tedious/unproductive during development) and just use the strong-typed SOAP Service Clients: i.e. 

  - Soap11ServiceClient

  - Soap12ServiceClient 

Which use the same SOAP endpoints except it allows you to re-use the same strong type DTOs you use to define your services with, for a cleaner API.

Although if you're going this route then some of the other ServiceClient's may be more suitable for your use-case: 

   - JsonServiceClient - popular and fast

   - JsvServiceClient - fastest and most compact serialization format for .NET to .NET web services.

   - XmlServiceClient - ubiquitous, more interoperable, verifiable with XSD

Note they all implement IServiceClient and IRestClient interfaces so they're effectively a single line of code change to swap between the different formats/endpoints.

Personally I would advocate the use against SOAP for most use-cases which you have control of since its a slower, more fragile and verbose, over-architected and complex standard which is rightfully in sharp decline. I'd need a good reason to develop against that the SOAP endpoints. A while ago I wrote a brief summary about the different protocols/formats: http://www.servicestack.net/mythz_blog/?p=154

Hope this helps.

Cheers,

--
- Demis

http://twitter.com/demisbellot

http://www.servicestack.net/mythz_blog

[daniel]

Hello,

I already use JsonServiceClient, but I want also be compatibile with
"Add service reference", etc.

The problem is that everything is in one assembly and every DTO has
[DataContract(Namespace="http://schemas.servicestack.net/types")]

This is WSDL file: http://justpaste.it/c1v

Warning 4 Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension:
System.ServiceModel.Description.XmlSerializerMessageContractImporter
Error: There was a problem loading the XSD documents provided: a
reference to a schema element with name 'Hello' and namespace 'http://
schemas.servicestack.net/types' could not be resolved because the
element definition could not be found in the schema for
targetNamespace 'http://schemas.servicestack.net/types'. Please check
the XSD documents provided and try again.
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://
schemas.servicestack.net/types']/wsdl:portType[@name='IOneWay']

Cheers,
Daniel

[Demis Bellot]

I already use JsonServiceClient, but I want also be compatibile with "Add service reference", etc.

Awesome, that's the way to go :)

Ok, the problem with your WSDL is that it has a Services. prefix which is why it can't find the Hello type.

Do you have a weird setup? like is the Hello service is defined in an inner class or something? I've got a NuGet install which isn't omitting the Services. prefix. Note: I'm using the [assembly: ContractNamespace] to define the namespace.

<xs:schema xmlns:tns="http://schemas.servicestack.net/types" elementFormDefault="qualified" targetNamespace="http://schemas.servicestack.net/types" xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:complexType name="Services.Hello">

    <xs:sequence />

  </xs:complexType>

  <xs:element name="Services.Hello" nillable="true" type="tns:Services.Hello" />

  <xs:complexType name="Services.HelloResponse">

    <xs:sequence />

  </xs:complexType>

  <xs:element name="Services.HelloResponse" nillable="true" type="tns:Services.HelloResponse" />

</xs:schema>

</wsdl:types>

Cheers,

[daniel]

:) Thanks for suggestions.

I've moved DTO's to the same namespace as Hello Example (AppHost) from
NuGet and now it looks like this:

<xs:element name="AppHost.Hello" type="tns:AppHost.Hello"
nillable="true"/>

Do You have idea why does it append namespace for every DTO element? I
guess it shouldn't be that way.

I have no weird setup, just plain project + NuGet Install ServiceStack

On May 27, 11:40 am, Demis Bellot <demis.bel...@gmail.com> wrote:
> > I already use JsonServiceClient, but I want also be compatibile with "Add
> > service reference", etc.
>
> Awesome, that's the way to go :)
>

> Ok, the problem with your WSDL is that it has a *Services.* prefix which is

> why it can't find the Hello type.
>
> Do you have a weird setup? like is the Hello service is defined in an inner

> class or something? I've got a NuGet install which isn't omitting the *
> Services.* prefix. Note: I'm using the [assembly: ContractNamespace] to

> define the namespace.
>
> <xs:schema xmlns:tns="http://schemas.servicestack.net/types"
> elementFormDefault="qualified" targetNamespace="http://schemas.servicestack.net/types" xmlns:xs="http://www.w3.org/2001/XMLSchema">
>

>   <xs:complexType name="*Services.Hello*">

>
>     <xs:sequence />
>
>   </xs:complexType>
>

>   <xs:element name="*Services.Hello*" nillable="true"

[Demis Bellot]

Hi Dan,

That's still suggesting it's an inner class of AppHost?

<xs:element name="AppHost.Hello" type="tns:AppHost.Hello" nillable="true"/>

Do you have the latest version on NuGet v2.09? because when I added it to my project the DTOs where only under the projects default namespace on their own and not types defined in an inner class.

Cheers,

[daniel]

Ok, that was it. DTO's can't be defined in an inner class. But why?

Once again thank you for your time.

[Demis Bellot]

Ok, that was it. DTO's can't be defined in an inner class. But why?

Kool, glad you got it working. Not sure why, I guess .NET's XsdSchema doesn't like them.

Not really worth investigating as DTOs are first class types that shouldn't be defined inside other classes, i.e. there's no wire representation for an inner class.

Anyway glad you got it sorted.

Happy Hacking :)

Cheers,

On Fri, May 27, 2011 at 11:22 AM, daniel <nyk...@gmail.com> wrote:

Ok, that was it. DTO's can't be defined in an inner class. But why?

Once again thank you for your time.

[daniel]

Hehe ;) Thanks! Next target: Implementing Gzip requests compression
for JsonServiceClient (+ adding content-encoding header), If I get it
working I'll be official ServiceStack fan and lover :D

Cheers,
Daniel

On May 27, 12:32 pm, Demis Bellot <demis.bel...@gmail.com> wrote:
> > Ok, that was it. DTO's can't be defined in an inner class. But why?
>
> Kool, glad you got it working. Not sure why, I guess .NET's XsdSchema
> doesn't like them.
> Not really worth investigating as DTOs are first class types that shouldn't
> be defined inside other classes, i.e. there's no wire representation for an
> inner class.
>
> Anyway glad you got it sorted.
>
> Happy Hacking :)
>
> Cheers,
>