.NET отказы WCF, генерирующие неправильные значения SOAP 1.1 faultcode

Вам нужно изменить URL из https://android.googleapis.com/gcm/send на https://fcm.googleapis.com/fcm/send и измените свою библиотеку приложений. этот учебник поможет вам https://firebase.google.com/docs/cloud-messaging/server#implementing-http-connection-server-protocol

9
задан Brent Arias 26 February 2014 в 21:28
поделиться

2 ответа

Это - мое текущее обходное решение:

    /// <summary>
    /// Replacement for the static methods on FaultCode to generate Sender and Receiver fault codes due
    /// to what seems like bugs in the implementation for basicHttpBinding (SOAP 1.1). wsHttpBinding 
    /// (SOAP 1.2) seems to work just fine.
    /// 
    /// The subCode parameter for FaultCode.CreateReceiverFaultCode and FaultCode.CreateSenderFaultCode
    /// seem to take over the main 'faultcode' value in the SOAP 1.1 response, whereas in SOAP 1.2 the
    /// subCode is correctly put under the 'Code->SubCode->Value' value in the XML response.
    /// 
    /// This workaround is to create the FaultCode with Sender/Receiver (SOAP 1.2 terms, but gets
    /// translated by WCF depending on the binding) and an agnostic namespace found by using reflector
    /// on the FaultCode class. When that NS is passed in WCF seems to be able to generate the proper
    /// response with SOAP 1.1 (Client/Server) and SOAP 1.2 (Sender/Receiver) fault codes automatically.
    /// 
    /// This means that it is not possible to create a FaultCode that works in both bindings with
    /// subcodes.
    /// </summary>
    /// <remarks>
    /// See http://stackoverflow.com/questions/65008/net-wcf-faults-generating-incorrect-soap-11-faultcode-values
    /// for more details.
    /// </remarks>
    public static class FaultCodeFactory
    {
        private const string _ns = "http://schemas.microsoft.com/ws/2005/05/envelope/none";

        /// <summary>
        /// Creates a sender fault code.
        /// </summary>
        /// <returns>A FaultCode object.</returns>
        /// <remarks>Does not support subcodes due to a WCF bug.</remarks>
        public static FaultCode CreateSenderFaultCode()
        {
            return new FaultCode("Sender", _ns);
        }

        /// <summary>
        /// Creates a receiver fault code.
        /// </summary>
        /// <returns>A FaultCode object.</returns>
        /// <remarks>Does not support subcodes due to a WCF bug.</remarks>
        public static FaultCode CreateReceiverFaultCode()
        {
            return new FaultCode("Receiver", _ns);
        }
    }

Печально я не вижу способ использовать подкоды, не повреждаясь или SOAP 1.1 или 1,2 клиента.

Если Вы используете Код. Подсинтаксис кода, можно создать SOAP 1.1 совместимые значения faultcode, но он повреждает SOAP 1.2.

При использовании надлежащей поддержки подкода в.NET (или с помощью статических методов FaultCode или с помощью одной из перегрузок), это повреждает SOAP 1.1, но работает в SOAP 1.2.

8
ответ дан 4 December 2019 в 13:51
поделиться

Ответ от Microsoft:

Как обсуждено в http://msdn.microsoft.com/en-us/library/ms789039.aspx, существует два метода, обрисованные в общих чертах в Мыле 1,1 спецификации для пользовательских кодов отказа:

(1) Используя "точечную" нотацию, как Вы описываете

(2) Определение совершенно новых кодов отказа

К сожалению, "точечной" нотации нужно избежать, поскольку это - использование, препятствуется в WS-I Основная спецификация Профиля. По существу это означает, что нет никакого реального эквивалента Мыла 1,2 отказов SubCode при использовании Мыла 1.1.

Так, при генерации отказов необходимо будет быть осведомлены о MessageVersion, определенном в привязке, и генерировать faultcodes соответственно.

Так как "отправитель" и "получатель" не являются действительными кодами отказа для Мыла 1.1, и нет никакого реального эквивалента подкода отказа, Вы не должны использовать методы CreateSenderFaultCode и CreateReceiverFaultCode при генерировании пользовательских кодов отказа для Мыла 1.1.

Вместо этого необходимо будет определить собственный faultcode, с помощью собственного пространства имен и имени:

FaultCode customFaultCode = новый FaultCode (localName, faultNamespace);

7
ответ дан 4 December 2019 в 13:51
поделиться
Другие вопросы по тегам:

Похожие вопросы: