Эта ошибка вызвана тем, что используется NetDataContractSerializer (NetDCS), но эталонная сборка не является общей и не включена в клиент. Этот вопрос не об этом.
Этот вопрос касается предотвращения использования NetDataContractSerializer; или, по крайней мере, выяснить, почему он используется клиентом.
Почему клиент использует NetDCS, если я не настроил его для этого?
Согласно статьям/сообщениям, я обнаружил, что это является явным шагом; Я не включил это вручную для проекта или клиента WCF. Может ли машина/фреймворк переопределить меня?
Можно ли заставить клиента использовать обычный DataContractSerializer (DCS)?
Если да, могу ли я принудительно применить это для каждого типа или пространства имен? Базовые типы универсальной платформы уже находятся в сборке, на которую ссылаются; в идеале я мог бы разрешить эти проблемы с помощью NetDCS, но я бы отказался от NetDCS, чтобы решить эту проблему.
Если нет, доступны ли какие-либо более радикальные меры, такие как искажение ответа/ответа XML?
(Я в порядке, вручную добавляя любые необходимые распознаватели контрактов и работая с искаженными сгенерированными именами.)
Использование тестового клиента WCF (который всегда использует DCS?) работает нормально, что заставляет меня полагать, что текущая проблема связана с десериализацией NetDCS, которая возникает при использовании службы из проекта. Возможно, я неправильно понимаю, как работает тестовый клиент WCF.
Вот сообщение об ошибке (которое можно устранить, добавив эталонные сборки для NetDCS, но я не этого хочу), чтобы убедиться, что я правильно понимаю проблему. Я на 95% уверен, что это происходит при десериализации в клиенте.
Средство форматирования выдало исключение при попытке десериализовать сообщение.
'Использование типа '..' в качестве коллекции только для получения не поддерживается с NetDataContractSerializer. Попробуйте пометить тип атрибутом CollectionDataContractAttribute или SerializableAttribute или добавить к свойству установщик.
И сводка стека:
Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter)
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ref ProxyRpc rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService
Конфигурация клиента WCF является простой конфигурацией по умолчанию, и в ней нет кода, который изменяет поведение во время выполнения.
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_myServiceBinding" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="endPoint.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_myServiceBinding"
contract="MyServive.IMyServiceEndPoint" name="BasicHttpBinding_serviceEndPoint" />
</client>
</system.serviceModel>
Ссылка на службу создается в VS 2013, а проект нацелен на .NET 4. Проект со ссылкой на службу и тестовый проект являются простыми библиотеками классов, т.е. они не размещены в IIS.
