Иногда при добавлении ссылки на службу WCF создается пустой файл reference.cs

Question

Иногда при добавлении ссылки на службу WCF создается пустой файл reference.cs, и я не могу ссылаться на службу где-либо в проекте.

Кто-нибудь сталкивался с этим?

Answer 1

В моем случае у меня было решение с проектом VB Web Forms, которое ссылалось на C # UserControl. И проект VB, и проект CS имели ссылку на службу для одной и той же службы. Ссылка появилась в разделе «Ссылки на услуги» в проекте VB и в группе «Подключенные службы» в проекте CS (framework).

Чтобы обновить ссылку на службу (т. Е. Чтобы файл Reference.vb не был пустым) в проекте веб-форм VB, мне нужно было УДАЛИТЬ ПРОЕКТ CS, затем обновить ссылку на службу VB, затем добавить CS проект обратно в решение.

Answer 2

При попытке решить эту проблему с помощью svcutil я получил ошибку, указанную в ответе dblood («ссылочный тип не может быть использован, поскольку он не соответствует импортированному DataContract»).

В моем случае основной причиной, по-видимому, был тип enum с атрибутом DataContract, но члены которого не были отмечены атрибутом EnumMember. Класс проблемы, на который указывает svcutil, имеет свойство с этим типом перечисления.

Это было бы лучше в качестве комментария к ответу dblood, но для этого недостаточно репов ...

Answer 3

Спасибо посту Джона Сондерса выше, который дал мне идею заглянуть в окно ошибок. Я весь день мешал в голове и смотрел в окно вывода на наличие ошибок.

В моем случае виновник был ISerializable. У меня есть класс DataContract со свойством DataMember типа Exception. Вы не можете иметь DataMember типа, который имеет ключевое слово ISerializable. В этом исключении есть ISerializable, как только я убрал его, все заработало как шарм.

Answer 4

Я столкнулся с подобной проблемой вчера во время разработки. Я узнал, что использую одно и то же пространство имен в 2 разных версиях контрактов.

У нас есть 2 варианта контрактов, например, версия 4 и версия 5. Я скопировал все контракты из версии 4 и переименовал все пространство имен из версии 4 в версию 5. При этом я забыл переименовать пространство имен с v4 на v5 в одном из файлов. Из-за конфликта пространства имен файл Reference.cs был пуст.

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

Answer 5

У меня также была проблема неработающих ссылок на сервисы при работе с ссылками на проект с обеих сторон (проект сервиса и проект, имеющий ссылку на сервис). Если .dll указанного проекта, например, называется «Contoso.Development.Common», но имя проекта просто сокращается до «Common», то ссылки на этот проект также называются просто «Common». Однако служба ожидает ссылку на «Contoso.Development.Common» для разрешения классов (если эта опция активирована в опциях ссылки на службу).

Итак, в проводнике я открыл папку проекта, ссылающуюся на сервис, и «Общий» -проект. Там я редактирую файл проекта VS (.csproj) с помощью блокнота. Найдите имя ссылочного проекта (в данном примере «Common.csproj»), и вы быстро найдете запись конфигурации, представляющую ссылку на проект.

Я изменил

<ProjectReference Include="..\Common\Common.csproj"> <Project>{C90AAD45-6857-4F83-BD1D-4772ED50D44C}</Project> <Name>Common</Name> </ProjectReference>

до

<ProjectReference Include="..\Common\Common.csproj"> <Project>{C90AAD45-6857-4F83-BD1D-4772ED50D44C}</Project> <Name>Contoso.Development.Common</Name> </ProjectReference>

Важно поменять имя ссылки на имя dll, на который ссылается проект в качестве вывода.

Затем переключитесь обратно на VS. Там вам будет предложено перезагрузить проект, так как он был изменен за пределами VS. Нажмите кнопку перезагрузки.

После этого добавление и обновление ссылки на службу работали так же, как и ожидалось.

Надеюсь, это поможет кому-то еще.

С уважением MH

Answer 6

Как указывает @dblood, основная проблема заключается в DataContractSerializer, который неправильно использует типы. Здесь уже есть несколько ответов, поэтому я начну с добавления плюсов и минусов по этому поводу:

• Флаг IsReference вызывает много проблем, но его удаление не всегда является ответом (особенно: в ситуациях с рекурсией).
• Основная проблема заключается в том, что контракт данных как-то не совпадает с именами типов, даже если они иногда (да? Да, вы правильно прочитали!). Очевидно, что сериализатор очень требователен, и очень трудно найти реальную проблему.
• Удаление «проверок ссылок» из «Настроить ссылку на службу» работает, но оставляет вам несколько реализаций. Тем не менее, я часто использую интерфейсы SOAP через библиотеки DLL. Кроме того, в большинстве известных мне SOA интерфейсы нескольких сервисов реализуют и расширяют одни и те же классы интерфейса. Снятие проверок «использование ссылочных типов» приводит к ситуации, когда вы просто не можете больше передавать объекты.

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

1. Создать отдельный интерфейс DLL. В эту DLL включите все DataContract и ServiceContract's; поместите ServiceContract на ваши интерфейсы.
2. Вывести реализацию сервера из интерфейса.

3. Используйте ту же DLL для создания клиента, используя ваш любимый метод. Например (IMyInterface является интерфейсом контракта на обслуживание):

   var httpBinding = new BasicHttpBinding();
   var identity = new DnsEndpointIdentity("");
   var address = new EndpointAddress(url, identity, new AddressHeaderCollection());
   var channel = new ChannelFactory<IMyInterface>(httpBinding, address);
   return channel.CreateChannel();
   

Другими словами: Не используйте функциональность «добавить ссылку на службу» , но вынудите WCF использовать (правильные) типы служб, минуя генерацию прокси. В конце концов, у вас уже есть эти классы.

Pro-х:

1. Вы пропустили процесс svcutil.exe, что означает, что у вас нет проблем с IsReference
2. Типы и имена DataContract корректны по определению; в конце концов, и сервер, и клиент используют одно и то же определение.
3. Если вы расширяете API или используете типы из другой DLL, (1) и (2) по-прежнему остаются в силе, поэтому у вас не возникнет никаких проблем.

Минусы:

1. Методы A-Sync - это боль, так как вы не генерируете прокси A-Sync. В результате я бы не рекомендовал делать это в приложениях Silverlight.