[ERROR] duplicate "message" entity: "IWcfRequestProcessor_ProcessRequests_InputMessage"

[REA_ANDREW]

I get the following error when generating a client for a particular
agatha service using both PHP and Java:

[ERROR] duplicate "message" entity:
"IWcfRequestProcessor_ProcessRequests_InputMessage"
line 1 of http://XXXXXXXXXXXXXXXXXXXXXXXX/Service.svc?wsdl

I am confused by this. The only reference to
IWcfRequestProcessor_ProcessRequests_InputMessage inside the wsdl is
the following:




<wsdl:message
name="IWcfRequestProcessor_ProcessRequests_InputMessage">
<wsdl:part name="parameters" element="tns:ProcessRequests" />
</wsdl:message>
<wsdl:message
name="IWcfRequestProcessor_ProcessRequests_OutputMessage">
<wsdl:part name="parameters"
element="tns:ProcessRequestsResponse" />
</wsdl:message>
<wsdl:message
name="IWcfRequestProcessor_ProcessOneWayRequests_InputMessage">
<wsdl:part name="parameters" element="tns:ProcessOneWayRequests" /
>
</wsdl:message>
<wsdl:portType name="IWcfRequestProcessor">
<wsdl:operation name="ProcessRequests">
<wsdl:input wsaw:Action="http://tempuri.org/IWcfRequestProcessor/
ProcessRequests"
message="tns:IWcfRequestProcessor_ProcessRequests_InputMessage" />
<wsdl:output wsaw:Action="http://tempuri.org/
IWcfRequestProcessor/ProcessRequestsResponse"
message="tns:IWcfRequestProcessor_ProcessRequests_OutputMessage" />
</wsdl:operation>
<wsdl:operation name="ProcessOneWayRequests">
<wsdl:input wsaw:Action="http://tempuri.org/IWcfRequestProcessor/
ProcessOneWayRequests"
message="tns:IWcfRequestProcessor_ProcessOneWayRequests_InputMessage" /
>
</wsdl:operation>
</wsdl:portType>

Does the tns: prefix not make it unique and if not, what would be the
cause for me getting this outputted in the wsdl?

Any help is appreciated:

Andrew

[Davy Brion]

i have no idea :s

do you happen to know whether it works when generating java/php clients for the example service layer? maybe it's something that we're doing wrong in our service contract...

[REA_ANDREW]

just tried it and I get no errors with the example service. Joy ....

Ah well, I will defo post the reason once I find out why. fingers
crossed that time is not too far away :-)

Cheers for now,

Andy

On Jul 2, 2:15 pm, Davy Brion <ral...@davybrion.com> wrote:
> i have no idea :s
>
> do you happen to know whether it works when generating java/php clients for
> the example service layer? maybe it's something that we're doing wrong in
> our service contract...
>
> On Fri, Jul 2, 2010 at 12:05 PM, REA_ANDREW

> <areaebusinesssyst...@gmail.com>wrote:

>
>
>
> > I get the following error when generating a client for a particular
> > agatha service using both PHP and Java:
>
> > [ERROR] duplicate "message" entity:
> > "IWcfRequestProcessor_ProcessRequests_InputMessage"

> >  line 1 ofhttp://XXXXXXXXXXXXXXXXXXXXXXXX/Service.svc?wsdl

[REA_ANDREW]

I have found the issue and it is related to non microsoft SOAP proxy
generators. I doubt all but certainly the main ones I have used i.e.
wsimport for Java and wsdl2php (a colleague used not me).

If you type in "duplicate "message" entity" into google, you only get
about 2 pages of results and some of the answers are not helpful. One
of the forums which I cam across was this one:

http://old.nabble.com/-Issue-841--New----ERROR--duplicate-%22message%22-entity:-%22PingRequest%22-td27931461.html

And reading down the posts I came across two interesting leads being:

1) FQDN
2) seRequestHeadersForMetadataAddress

Now the 2) is specific to .NET 4 and not available for earlier
releases, and is a common behaviour config for the
system.serviceModel. It sounds like this also would have solved my
issue. You will see an example inside that forum thread but anyway it
looks like this:

<commonBehaviors>
<serviceBehaviors>
<useRequestHeadersForMetadataAddress>
<defaultPorts>
<add port="443"
scheme="https"/>
</defaultPorts>
</useRequestHeadersForMetadataAddress>
</serviceBehaviors>
</commonBehaviors>

The one which lead me to solve my issue was 1) relating to FQDN (Fully
qualified domain name) . When I saw the definition of this I
immediately thought of something which I could not understand earlier
in the day. I am using IIS to test my services and as per usual I
would navigate to said service like :

http://localhost/Services/Service.svc

Cool, only when I get there, the address for the wsdl which appears in
the default .svc page from microsoft has the following address:

http://d8l10g4j.ad.xxxxxxxxxxxxxx.com/Services/Service.svc?wsdl

No, i had not given this much thought earlier and so in the wsimport
bat file I made I was trying the following addresses to generate it:

http://127.0.0.1/Services/Service.svc?wsdl
http://localhost/Services/Service.svc?wsdl
http://10.0.2.40/Services/Service.svc?wsdl

None of which worked, but which I thought should and would work. :-S
So as I say after I read the definition of the FQDN I thought I wonder
if I need to put in the url which is generated on the .svc page for
the wsdl and as it turns out, I did have to do that. Now I get the
proxy generating just fine.

Although I can get this to work, I am going to still try and find out
what is causing the url to resolve to FQDN as opposed the url which I
used to navigate to the service.

Anyway, thought I would post in case others get the same issue.

Cheers for now,

Andy

[Markus Brüderl]

In case anyone still has this problem, i could fix it this way:

Inside the c#-Webservice-Implementation-Class, add a  [ServiceBehavior(Namespace = "http://your-website/yourApp")]
Inside the web.config ensure that both service-endpoints for this service contain attribute bindingNamespace="http://your-website/yourApp"

In my case the problem was that the declared ServiceBehaviour-Namespace inside the implementation did not match the web.config attribute value.