Web service does not conform to WS-I Basic Profile v1.1

After converting a web service project, I get the following message when I am browsing the web page. The message appears after the listing of all the methods in the web service. The two methods that are listed have in common that they don't have any input parameter. Anyone that knows what the problem is?

"This web service does not conform to WS-I Basic Profile v1.1.
Please examine each of the normative statement violations below. Follow the recommendations to remedy it, or add setting to the <webServices> config section to turn off BP 1.1 conformance warnings for the entire vroot.

To turn off BP 1.1 conformance warnings for the entire vroot remove the 'BP1.1' value from the <conformanceWarnings> section of the configuration file of your application:

<configuration>
<system.web>
<webServices>
<conformanceWarnings>
<remove name='BasicProfile1_1'/>
</conformanceWarnings>
</webServices>
</system.web>
</configuration>

R2710: The operations in a wsdl:binding in a DESCRIPTION MUST result in wire signatures that are different from one another. An endpoint that supports multiple operations must unambiguously identify the operation being invoked based on the input message that it receives. This is only possible if all the operations specified in the wsdl:binding associated with an endpoint have a unique wire signature.
- Input message 'GetRootLevelsSoapIn' from namespace 'http://no.abb.com/NPims/Safety/ASRService' has no elements (empty wire signature)
- Input message 'GetAcEventDefsSoapIn' from namespace 'http://no.abb.com/NPims/Safety/ASRService' has no elements (empty wire signature)
Recommendation: The Profile defines the "wire signature" of an operation in a wsdl:binding to be the fully qualified name of the child element of the soap:Body of the SOAP input message it describes. For the case of an empty soap:Body this name is an empty string. In the case of rpc-literal binding, the operation name is used as a wrapper for the part accessors. In the document-literal case, since a wrapper with the operation name is not present, the message signatures must be correctly designed so that they meet this requirement."

Can you you post the WSDL for the service and/or the actual code (you can delete the bodies of all the methods, just need to see the "interface".

Here is the actual code for the two methods:

[WebMethod]
[Description("Get data for root levels.")]
[SoapDocumentMethod(ParameterStyle = SoapParameterStyle.Bare)]
[return : XmlElement("GetRootLevelsResponse")]
public GetRootLevelsResponse GetRootLevels()
{
...
}

[WebMethod]
[Description("Get data for specified AcEventDef.")]
[SoapDocumentMethod(ParameterStyle = SoapParameterStyle.Bare)]
[return : XmlElement("GetAcEventDefsResponse")]
public GetAcEventDefsResponse GetAcEventDefs()
{
...
}

Thanks,

You should probably read this carefully...

http://msdn2.microsoft.com/en-us/library/ms953974.aspx

Especially:

Quote:

---

When using a SoapDocumentMethodAttribute or SoapDocumentServiceAttribute there are certain restrictions if you set the ParameterStyle property to SoapParameterStyle.Bare. These restrictions are you must not have more then one parameter to your WebMethod, and no two WebMethods can have identical parameters. [R2210][R2710]

---

It looks like the context of "No Parameters" is being treated as "Identical". Can you (temporarily at least) add a nummy parameter to just ONE of them?

Thanks,

I added a dummy parameter, and then the error message disappeared for that method (another method with no input parameter appeared instead). I will read through the link you sent and see if I can find a solution to this.

The methods do seems to work ok even when I get this error messages.

Quote:

---

Originally Posted by beck

The methods do seems to work ok even when I get this error messages.

---

I would expect that under "normal" circumstances. However there are likely to be third party consumers from radically different vendors (eg an IBM mainframe accessing your service) which makes use of the "Basic Profile" in a strict conformance mode.

The importance of this depends on the usage scenario of your service.....