Ответ 1
Я понял проблему. Это закончилось тем, что путь к моему файлу конфигурации был неправильным. Ошибки для WCF иногда оказываются полезными.
У меня есть служба WCF, работающая нормально на моей локальной машине. Я положил его на серверы, и я получаю следующую ошибку:
Произошла ошибка при получении Ответ HTTP на http://xx.xx.x.xx:8200/Services/WCFClient.svc. Это может быть связано с обслуживанием привязка конечной точки, не использующая HTTP протокол. Это также может быть связано с Контекст HTTP-запроса прерывается сервера (возможно, из-за закрытие службы). См. Сервер журналы для более подробной информации.]
Я пошел на службу в URL-адрес, и он работает правильно. Все, что я делаю для функции, возвращает строку имени изображения, поэтому передаваемые данные не так уж много. Я проследил журнал, и он дает мне ту же информацию. Вот моя конфигурация клиента:
<binding name="basicHttpBinding_IWCFClient" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647"
messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
allowCookies="false">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
maxArrayLength="2147483647" maxBytesPerRead="2147483647"
maxNameTableCharCount="2147483647" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
<endpoint name="basicHttpBinding_IWCFClient"
address="http://localhost:4295/Services/WCFClient.svc"
binding="basicHttpBinding"
bindingConfiguration="basicHttpBinding_IWCFClient"
behaviorConfiguration="WCFGraphicManagementTool.Services.ClientBehavior"
contract="WCFClient.IWCFClient" />
Вот моя конфигурация сервера:
<service behaviorConfiguration="WCFGraphicManagementTool.Services.WCFClientBehavior"
name="WCFGraphicManagementTool.Services.WCFClient">
<endpoint name="basicHttpBinding_IWCFClient"
address=""
binding="basicHttpBinding"
contract="WCFGraphicManagementTool.Contracts.IWCFClient" />
<endpoint
address="mex"
binding="mexHttpBinding"
contract="IMetadataExchange" />
</service>
<behavior name="WCFGraphicManagementTool.Services.WCFClientBehavior">
<dataContractSerializer maxItemsInObjectGraph="2147483647" />
<serviceThrottling maxConcurrentCalls="120" maxConcurrentSessions="120"
maxConcurrentInstances="120" />
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
Будет ли это настройка на сервере, поскольку он работает на моей локальной машине?
Я понял проблему. Это закончилось тем, что путь к моему файлу конфигурации был неправильным. Ошибки для WCF иногда оказываются полезными.
У меня возникла такая проблема: "Это может быть связано с привязкой конечной точки службы, не использующей протокол HTTP", и служба WCF будет отключена (в машине разработки)
Я выяснил: в моем случае проблема была из-за Enums,
Я решил использовать этот
[DataContract]
[Flags]
public enum Fruits
{
[EnumMember]
APPLE = 1,
[EnumMember]
BALL = 2,
[EnumMember]
ORANGE = 3
}
Мне пришлось украсить мои Enums DataContract, Flags и всех членов перечисления с атрибутами EnumMember.
Я решил это после просмотра справки msdn:
Я думаю, что есть проблема сериализации, вы можете найти точную ошибку, просто нужно добавить код ниже в конфигурацию службы в разделе <configuration>
.
После создания конфигурационного обновления "App_tracelog.svclog"
будет создан файл, где существует ваша служба, просто нужно открыть файл .svclog
и найти красную линию цвета на левой боковой панели, которая является ошибкой, и посмотреть ее описание для получения дополнительной информации.
Надеюсь, это поможет найти вашу ошибку.
<system.diagnostics>
<sources>
<source name="System.ServiceModel.MessageLogging" switchValue="Warning, ActivityTracing">
<listeners>
<add name="ServiceModelTraceListener" />
</listeners>
</source>
<source name="System.ServiceModel" switchValue="Verbose,ActivityTracing">
<listeners>
<add name="ServiceModelTraceListener" />
</listeners>
</source>
<source name="System.Runtime.Serialization" switchValue="Verbose,ActivityTracing">
<listeners>
<add name="ServiceModelTraceListener" />
</listeners>
</source>
</sources>
<sharedListeners>
<add initializeData="App_tracelog.svclog" type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ServiceModelTraceListener" traceOutputOptions="Timestamp" />
</sharedListeners>
</system.diagnostics>
У меня была такая же ошибка, и проблема была в сериализации. Мне удалось найти реальную проблему с помощью Service Trace Viewer http://msdn.microsoft.com/en-us/library/ms732023.aspx и решить ее легко. Возможно, это поможет кому-то.
В моем случае ошибка была сгенерирована, потому что один из моих сложных типов имел свойство без установленного метода.
Сериализатор бросил и исключил из-за этого факта. Добавлены внутренние методы набора, и все работает нормально.
Лучший способ узнать, почему это происходит (на мой взгляд) - включить ведение журнала трассировки.
Я достиг этого, добавив следующий раздел в мой web.config:
<system.diagnostics>
<sources>
<source name="System.ServiceModel.MessageLogging" switchValue="Warning,ActivityTracing">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:\log\Traces.svclog" />
<add type="System.Diagnostics.DefaultTraceListener" name="Default" />
</listeners>
</source>
<source propagateActivity="true" name="System.ServiceModel" switchValue="Verbose,ActivityTracing">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:\log\Traces.svclog" />
<add type="System.Diagnostics.DefaultTraceListener" name="Default" />
</listeners>
</source>
</sources>
<trace autoflush="true" />
</system.diagnostics>
После установки я запустил свой клиент, получил исключение и проверил файл "Traces.svclog". Оттуда мне нужно было только найти исключение.
Решение с DataContract, флаги для Enums выглядят немного уродливо. В моем случае проблема была решена путем добавления в enum чего-то типа "NotSet = 0":
public enum Fruits
{
UNKNOWN = 0,
APPLE = 1,
BALL = 2,
ORANGE = 3
}
Я видел эту ошибку, вызванную круговой ссылкой в графе объектов. Включение указателя на родительский объект из дочернего элемента приведет к циклическому циклузатору и в конечном итоге превысит максимальный размер сообщения.
Моя проблема заключалась в том, что возвращаемый тип моей службы был строкой. Но я вернул строку типа xml:
<reponse><state>1</state><message>Operation was successfull</message</response>
поэтому была сброшена ошибка.
У меня была эта проблема, потому что я настроил службу WCF для возврата в System.Data.DataTable.
Он отлично работал на моей тестовой HTML-странице, но взорвался, когда я поместил это в свое приложение Windows Form.
Мне пришлось войти и сменить подпись Операционного контракта на обслуживание из DataTable на DataSet и соответственно вернуть данные.
Если у вас есть эта проблема, вы можете добавить дополнительный операционный контракт к своей службе, чтобы не беспокоиться о нарушении кода, который зависит от существующих служб.
Это может быть вызвано многими причинами; ниже приведены немногие из них:
Если ваши объекты контракта данных используют наследование, убедитесь, что все базовые классы имеют атрибуты DataContract и DataMember. Кроме того, вам необходимо, чтобы базовые классы определяли производные классы с помощью [KnownType (typeof (BaseClassType))] атрибут (подробнее читайте здесь об этом).
Убедитесь, что все свойства объекта контракта с данными имеют как свойства get, так и set.
Моя проблема заключалась в том, что между клиентом и сервером передавалось слишком много элементов. Мне пришлось изменить эти настройки в поведении с обеих сторон.
<dataContractSerializer maxItemsInObjectGraph="2147483646"/>
Для получения дополнительной информации об этой проблеме см. также: Существующее соединение было принудительно закрыто удаленным хостом - WCF
Моя проблема закончилась тем, что мои объекты передачи данных были слишком сложными. Начните с простых свойств, таких как public long Id { get; set; }
, и как только вы начнете работать, чем при необходимости добавьте дополнительные материалы.
Эта ошибка может быть из-за несоответствия контракта. Рассмотрим трехслойное приложение ниже...
UI Layer
|
Технологический слой
|
Уровень доступа к данным
- > Контракт между процессом и слоем пользовательского интерфейса имеет то же перечисление с отсутствующим (Onhold = 3). Enum: Start = 1, Stop = 2.
- > Контракт между доступом к данным и слоем процесса имеет перечисление Enum: Start = 1, Stop = 2, Onhold = 3.
В этом случае мы получим ту же ошибку в ответе уровня процесса.
Такая же ошибка возникает и при несоответствии контракта в многослойном приложении.
Это может быть несовместимо с вашей конкретной проблемой, но упомянутое сообщение об ошибке имеет много причин, один из них использует тип возврата для [OperationContract], который является абстрактным, интерфейсом или неизвестным клиенту WCF код.
Проверьте сообщение (и решение) ниже
Я думаю, что лучший способ решить эту проблему - следить за советом по ошибкам и, следовательно, искать журналы сервера. Чтобы включить журналы, я добавил
<system.diagnostics>
<sources>
<source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
<listeners>
<add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\TracesServ_ce.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
Затем вы переходите к c:\logs\TracesServ_ce.svclog, открываете его с помощью microsoft средство просмотра трассировки. И посмотрите, какая проблема на самом деле.
Я боролся с этим в течение нескольких дней и пробовал каждый ответ с этого поста и многих других и делился своим решением, потому что симптомы были одинаковыми, но проблема была другой.
Проблема заключалась в том, что пул приложений был настроен с ограничением памяти, и он просто перерабатывается через переменный период времени.
Надеюсь, это поможет кому-то еще!
Привет,
в моем случае
моя служба имеет функцию download Files
и эта ошибка появляется только при попытке загрузить Big Files
поэтому я нашел этот ответ для увеличения maxRequestLength
до нужного значения в web.config
Я знаю, что это странно, но проблема решена.
если вы не выполняете никаких операций по загрузке или загрузке, возможно, этот ответ не поможет вам
Также была проблема, и из-за того, что я забыл украсить мою модель атрибутами DataContract и DataMember
Для меня решения этой ошибки очень странные. Это проблема адреса порта EndpointAddress. В порту Visual studio адрес вашего файла (например, Service1.svc) и адрес порта вашего проекта wcf должен быть таким же, как вы указываете в EndpointAddress. Позвольте мне подробно описать это решение.
Существует два способа проверки адресов портов.
В вашем проекте WCF щелкните правой кнопкой мыши на ваш служебный файл (например, Service1.svc) → чем выберите Просмотреть в браузере сейчас в вашем браузере у вас есть URL-адрес, например http://localhost:61122/Service1.svc, поэтому теперь запишите свой адрес порта как 61122
Righ щелкните по проекту wcf → , чем выберите Свойства → перейдите на вкладку Веб-вкладка → Теперь в разделе Сервера → выберите Использовать сервер разработки Visual Studio → выберите Конкретный порт и укажите адрес порта, который мы ранее нашли в нашей службе Service1.svc. Это (61122).
Раньше у меня есть другой адрес порта. После правильного указания адреса порта, который я указал в EndpointAddress, моя проблема была решена.
Я надеюсь, что это может решить вашу проблему.
Чтобы исправить это, нам пришлось изменить идентификатор AppPool на учетную запись администратора.