Метод WCF называется дважды

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

System.Net.WebException: базовое соединение было закрыто: произошла непредвиденная ошибка при получении.

И когда я отлаживаю веб-службу, я вижу, что этот конкретный метод вызывается дважды. Он выполняет оператор return в первый раз, когда ничего не происходит, но когда он выполняет его во второй раз, вышеупомянутое исключение бросается в настольном приложении.

Я нашел похожие сообщения раньше в stackoverflow, но они не решили мою проблему. Может кто-нибудь, пожалуйста, скажите мне, что здесь происходит?

Спасибо!

Ответы

Ответ 1

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

UPDATE:

Чтобы еще больше диагностировать проблему, я предлагаю вам активировать трассировку службы, поместив в конфигурационный файл следующее:

<system.diagnostics>
    <trace autoflush="true">
    </trace>
    <sources>
        <source name="System.ServiceModel"
                switchValue="Information, ActivityTracing"
                propagateActivity="true">
            <listeners>
                <add name="sdt"
                     type="System.Diagnostics.XmlWriterTraceListener"
                     initializeData="WcfDetailTrace.e2e" />
            </listeners>
        </source>
    </sources>
</system.diagnostics>

Это создаст файл трассировки WcfDetailTrace.e2e, который вы можете открыть с помощью Инструмента просмотра трассировки служб, который предоставит вам обширную информацию о вызова и сообщения об ошибке.

Ответ 2

Недавно у меня была эта проблема.

Оказалось, что анализ журнала WCF, написанный System.Diagnostics.XmlWriterTraceListener, вызвал проблему с контрактом данных, который я установил.

Я возвращаюсь Dictionary<int, object> (Боковое примечание: Да, я знаю, что это действительно плохо!, но я молод и нуждаюсь в деньгах). Я забыл включить атрибут [KnownType] в возвращаемое значение для DataContract:

    [DataContract]
    [KnownType(typeof(Dictionary<int, double>))]
    [KnownType(typeof(Dictionary<int, ChannelData>))]
    [KnownType(typeof(Dictionary<string, Dictionary<int, double>>))]
    public class MyCoolObject: ICoolObject
    {
[DataMember]
        public Dictionary<string, object> Results
        {
            get { return _results; }
            set { _results = value; }
        }
    }

Ответ 3

У меня тоже была эта проблема. Для меня это происходило, потому что у меня было свойство [DataMember] с get{}, но не set{}. После добавления set{} это поведение остановилось.

Ответ 4

У меня недавно была эта проблема, и оказалось, что я забыл отметить один из классов передачи данных с помощью [DataContract]

Ответ 5

Я столкнулся с этой же проблемой. Оказалось, что WCF не смог вернуть DateTime как JSON, поэтому мне пришлось сделать это Nullable<DateTime>.

Ответ 6

У меня также была эта проблема, и мое решение было похоже на Batgar's, но с завихрением. У меня был класс, у которого было свойство типа object. Мне пришлось добавлять атрибуты KnownType к классу для каждого типа объекта, который мог бы содержать объект. Я не мог заполнить KnownType на лету, поскольку класс не знал, что будет содержать этот объект.

Ответ 7

Я столкнулся с теми же симптомами, что и OP, но моей целью был веб-сервис Oracle, который я не могу контролировать. Вызовы WebService работали нормально из автономного тестового веб-приложения, но не из приложения .NET, которое требовало реализации.

Я не понимаю почему, но обновление targetFramework в web.config с 4.5 до 4.6.1 targetFramework проблему для моего приложения.

<httpRuntime targetFramework="4.5" requestValidationMode="4.5" executionTimeout="36000"/>

<httpRuntime targetFramework="4.6.1" requestValidationMode="4.5" executionTimeout="36000"/>