Удалите xml пространства имен из успокоительного ответа WCF

Можно удалить пространство имен XML путем установки параметра Пространства имен атрибута DataContract к пустой строке, как так:

[DataContract(Namespace = "")]
public class ResponseInfo
{
    // ...
}

я надеюсь, что это помогает...

Я предполагаю, что Вы пробуете вместо того, чтобы получить что-то вроде этого в начале Вашего xml:

<ResponseInfo 
   xmlns="http://schemas.datacontract.org/2004/07/ResponseInfo"
   xmlns:i="http://www.w3.org/2001/XMLSchema-instance" >

Вы хотите просто:

<ResponseInfo>

К сожалению, я не видел простой способ все же для удаления тех полей. Я гуглил для решений и большинства опций для удаления, оно требует создания Вашего собственного инспектора сообщения или Вашего собственного кодера.

Если Вы хотите изменить Xml, один из путей состоит в том, чтобы использовать XslTransform. У меня был подобный случай, куда я должен был удалить атрибуты xmlns из запроса Сообщения Xml.

В WCF можно 'прервать' сообщения XML перед движением, или прежде чем они будут обработаны на пути в путем реализации или IClientMessageInspector или IDispatchMessageInspector, в зависимости от того, нужно ли Вам это в клиенте или стороне сервера.

, Например, для разделения атрибутов пространства имен от исходящего сообщения XML до веб-сервиса я реализовал IClientMessageInspector, с помощью следующего кода:

#region IClientMessageInspector Members
    public void AfterReceiveReply(ref Message reply, object correlationState)
    {   
        //Console.WriteLine(reply.ToString());
    }

    private XslCompiledTransform xt = null;

    public object BeforeSendRequest(ref Message request, IClientChannel channel)
    {
        Console.WriteLine(request.ToString());
        if (!request.IsEmpty)
        {
            XmlReader bodyReader =
                request.GetReaderAtBodyContents().ReadSubtree();

            MemoryStream ms = new MemoryStream();
            XmlWriter xw = XmlWriter.Create(ms);

            if (xt == null)
            {
                xt = new XslCompiledTransform(true);
                xt.Load("StripXmlnsi.xslt");
            }
            xt.Transform(bodyReader, xw);

            ms.Flush();
            ms.Seek(0, SeekOrigin.Begin);

            bodyReader = XmlReader.Create(ms);

            Message changedMessage = Message.CreateMessage(request.Version, null, bodyReader);
            changedMessage.Headers.CopyHeadersFrom(request.Headers);
            changedMessage.Properties.CopyProperties(request.Properties);
            request = changedMessage;
        }
        return null;
    }
    #endregion

и используемый следующее преобразуйте:

    <?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="*">
    <!-- remove element prefix (if any) -->
    <xsl:element name="{local-name()}">
      <!-- process attributes -->
      <xsl:for-each select="@*">
        <!-- remove attribute prefix (if any) -->
        <xsl:attribute name="{local-name()}">
          <xsl:value-of select="." />
        </xsl:attribute>
      </xsl:for-each>
      <xsl:apply-templates />
    </xsl:element>
  </xsl:template>
</xsl:stylesheet>

Hope это полезно.

В моем УСПОКОИТЕЛЬНОМ сервисе WCF, который я записал до УСПОКОИТЕЛЬНОГО стартового набора WCF, что сделал следующее, которое дает мне хорошие, чистые результаты.

Первый, удостоверьтесь, что webHttp поведение конечной точки установлено:

  <endpointBehaviors>
    <behavior name="Web">
      <webHttp/>
    </behavior>
  </endpointBehaviors>

Ваша конечная точка должна выглядеть примерно так (минус контракт для простоты):

<endpoint address="" binding="webHttpBinding" behaviorConfiguration="Web" />

Мой контракт на обслуживание имеет эти контракты на операцию в нем:

    [WebGet(UriTemplate="tasks", ResponseFormat=WebMessageFormat.Xml )]
    [OperationContract]
    Task[] GetTasks();

    [WebGet(UriTemplate="tasks/{id}", ResponseFormat=WebMessageFormat.Xml)]
    [OperationContract]
    Task GetTask(string id);

сама реализация услуги не имеет ничего специального об этом. Можно попытаться изменить WebMessageFormat, но единственный другой объект в перечислении является "json".

Просто чтобы дать другую перспективу, если пространство имен уникально для вашего проекта, например:

http: / /mycompany.com/myapi/

Тогда это должно быть сохранено.

Такие пространства имен являются наилучшей практикой, они добавляют менее 1 строки стандартного шаблона к любым вызовам XPath (которые можно превратить в вспомогательный метод) и требуют около 15 строк вспомогательного кода для генерации карты префикса / URI, но Это ЕДИНСТВЕННЫЙ недостаток, и вы не всегда будете сталкиваться с ним.

В обмен вы получаете однозначные имена для каждого элемента, и это означает, что вы можете безнаказанно создавать пространства имен третьих сторон, например, теоретически вы можете возвращать XHTML напрямую, без кодирования на уровне приложения.

Другие всплывающие пространства имен вряд ли будут проблемой, так как они вряд ли будут использоваться с любым из тегов, определенных вами в вашем проекте. По факту, если они есть, то где-то есть ошибка. Вероятное объяснение их существования состоит в том, что фреймворк добавил их на тот случай, если необходимо добавить элемент где-то ниже места, где они объявлены, что может не быть местом, о котором вам нужно заботиться.

Другой упомянутый ответ http://www.w3.org/2001/XMLSchema-instance , который немного особенный, возможно, вы могли бы сказать, какие пространства имен были добавлены.