Метод WCF вызывается дважды - PullRequest
15 голосов
/ 19 апреля 2010

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

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

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

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

Спасибо!

Ответы [ 7 ]

12 голосов
/ 19 апреля 2010

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


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, который можно открыть с помощью Service Trace Viewer Tool , который предоставит вам подробную информацию о вызове и сообщении об ошибке.

6 голосов
/ 03 октября 2011

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

Оказалось, что анализ журнала 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; }
        }
    }
5 голосов
/ 07 ноября 2015

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

2 голосов
/ 03 марта 2016

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

1 голос
/ 22 марта 2016

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

1 голос
/ 04 июля 2014

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

0 голосов
/ 22 января 2019

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

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

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

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

...