none
WCF ServiceContract namespaces RRS feed

  • Question

  • Gentlefolk,

    I apologize if this question is in the wrong forum -- I could not find a WCF specific one, and since I am using C#, I figured that this one is probably the best one to go for.

    Suppose I have a WCF contract defined as follows:

    namespace MyCompany.MyProduct
    {
    	[ServiceContract]
    	public interface IMyContract
    
    	...
    }
    

    The contract IMyContract is already in the namespace MyCompany.MyProduct. However, I see from various sources that I should add a use the Namespace attribute to put the contract into another kind of namespace:

    namespace MyCompany.MyProduct
    {
    	[ServiceContract(Namespace = "http://MyCompany/MyProduct")]
    	public interface IMyContract
    
    	...
    }

    (I realize that the Namespace attribute value can be anything and does not need to reflect the C# namespace; I could have used Namespace = "qwertyuiop".

    Since I already have a C# namespace for the ServiceContract, what does the Namespace attribute on it add and why should I be in the habit of using it?

    Thanks in advance.

    Andrew Ch.

    Thursday, May 31, 2018 2:57 PM

Answers

  • That attribute is really designed for the XML that gets generated. Since SOAP is XML based and XML really likes namespaces then SOAP uses them to. In general you don't really need to worry about the namespace because a dummy one will be used. The purpose of this property on the attribute is to allow you to specify an actual XML namespace instead of the default one. Note that this particular attribute only impacts the SOAP definition itself. The service and data will still use the default namespace (you have to attribute them as well if you don't want that).

    The purpose of the XML namespace stuff is to separate elements/attributes when working with large XML sets. For a WCF service this isn't going to be an issue but some people like to specify company-specific namespaces anyway. This is really only common in public facing services. For private ones who cares.

    So, unless you're building a public service and you want the namespaces to clearly reference your company then you don't need the namespace information. While it is generally given as a URL, it isn't one. It just uniquely identifies the elements/attributes in the XML.


    Michael Taylor http://www.michaeltaylorp3.net

    Thursday, May 31, 2018 5:33 PM
    Moderator

All replies

  • Since I already have a C# namespace for the ServiceContract, what does the Namespace attribute on it add and why should I be in the habit of using it?

    I have never used it nor have I ever seen it used.

    But you can ask at the WCF forum.

    https://social.msdn.microsoft.com/Forums/vstudio/en-US/home?forum=wcf

    Thursday, May 31, 2018 5:24 PM
  • That attribute is really designed for the XML that gets generated. Since SOAP is XML based and XML really likes namespaces then SOAP uses them to. In general you don't really need to worry about the namespace because a dummy one will be used. The purpose of this property on the attribute is to allow you to specify an actual XML namespace instead of the default one. Note that this particular attribute only impacts the SOAP definition itself. The service and data will still use the default namespace (you have to attribute them as well if you don't want that).

    The purpose of the XML namespace stuff is to separate elements/attributes when working with large XML sets. For a WCF service this isn't going to be an issue but some people like to specify company-specific namespaces anyway. This is really only common in public facing services. For private ones who cares.

    So, unless you're building a public service and you want the namespaces to clearly reference your company then you don't need the namespace information. While it is generally given as a URL, it isn't one. It just uniquely identifies the elements/attributes in the XML.


    Michael Taylor http://www.michaeltaylorp3.net

    Thursday, May 31, 2018 5:33 PM
    Moderator
  • Michael Taylor,

    Thank you for taking the time to give an answer.

    Andrew.

    Friday, June 1, 2018 7:16 AM