SOAP, using prefixes in tags <xx:tag>

I am bad with SOAP. A third party SOAP service gave me example code to use for their api. The code that they give (which I copied to my solution EXACTLY) does not spit out a required prefix before all the tags.

Right now, the code they give me causes m开发者_如何学JAVAe to make requests/responses that have no prefix to all the tags...

<tagName />

. How do I make all the tags look like...

<com:tagName />

Here is the attributes for my WebServicesClient

[System.CodeDom.Compiler.GeneratedCodeAttribute("wsdl", "2.0.50727.42")]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Web.Services.WebServiceBindingAttribute(Name = "catalogHttpBinding", Namespace = "http://com.etilize.spexlive")]
[System.Xml.Serialization.XmlIncludeAttribute(typeof(CategoryCollection))]
public partial class catalog : Microsoft.Web.Services3.WebServicesClientProtocol

First of all, you're using WSE, which is obsolete. Don't do that unless you have no other choices at all.

When I say "no other choices", I'm including "can't afford to quit the job".

Secondly, this is not a SOAP issue. It's basic XML. You need your elements to be in a particular namespace. Since it looks like you used the correct obsolete tool to generate your client, chances are that your elements are already in the correct namespace.

It may look wrong to you because you don't realize that, in XML, namespace prefixes don't matter - only the prefix is simply an alias for the namespace, and it's the namespace that matters. In particular, the following three examples are identical:

<a:ElementName xmlns:a="urn:foo"/>

<b:ElementName xmlns:b="urn:foo"/>

<ElementName xmlns="urn:foo"/>

If your vendor actually requires a particular prefix (not a particular namespace), then they are badly broken, are violating International standards, and should be publicly mocked as being incompetent. If every vendor implements their own version of the XML standards, then it won't be long before it's not a standard anymore, and we won't be able to depend on it. Since much of the power of XML comes from the fact that it's a standard, this will be unfortunate.