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

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

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

Ответ 1

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

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

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

Ответ 2

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

В качестве улучшения здесь приведен краткий пример использования svcutil.

svcutil /t:code https://secure.myserver.com/services/MyService.svc /d:test /r:"C:\MyCode\MyAssembly\bin\debug\MyAssembly.dll"

Где:

/t: код генерирует код из заданного URL
/d: указать каталог для выхода
/r: указать ссылочную сборку

Ссылка на командную строку полного svcutil здесь: http://msdn.microsoft.com/en-us/library/aa347733.aspx

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

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

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

Если вы столкнулись с этой проблемой, и вы не используете общие типы в ваших контрактах с данными, и вы не используете IsReference = true, я рекомендую вам убедиться, что ваши общие типы на вашем клиенте и сервере точно совпадают. В противном случае вы, вероятно, столкнетесь с этой проблемой.

Ответ 3

Я целый день бил головой об этой точной проблеме. Я только что исправил это. Вот как...

Служба имела для запуска через SSL (т.е. на https://mydomain.com/MyService.svc)

Добавление ссылки службы на службу WCF на сервере разработки просто отлично.

Развертывание той же самой сборки службы WCF на реальном производственном сервере, затем переход к клиентскому приложению и настройка ссылки на службу для указания на живую службу не отображали ошибок, но приложение не создавало: Оказывается, что справочный файл Reference.cs был полностью пуст! Обновление ссылки на обслуживание не имело никакого значения. Очистка раствора не помогла. Перезапуск VS2010 не имел никакого значения. Создание нового пустого решения, запуск консольного проекта и добавление служебной ссылки на услугу live показали ту же проблему.

Я не думал, что это было из-за противоречивых типов или чего-то еще, но что, черт возьми, я переконфигурировал ссылку на службу WCF, сняв флажок "Типы повторного использования во всех ссылочных ассемблерах". Нет радости; Я положил галочку обратно.

Следующим шагом было попробовать svcutil в ссылочном URL-адресе, чтобы узнать, поможет ли это выявить проблему. Здесь команда:

svcutil /t:code https://mydomain.com/MyService.svc /d:D:\test

Это вызвало следующее:

Microsoft (R) Service Model Metadata Tool
[Microsoft (R) Windows (R) Communication Foundation, Version 4.0.30319.1]
Copyright (c) Microsoft Corporation.  All rights reserved.

Attempting to download metadata from 'https://mydomain.com/MyService.svc' using WS-Metadata Exchange or DISCO.
Error: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.DataContractSerializerMessageContractImporter
Error: Schema with target namespace 'http://mynamespace.com//' could not be found.
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://mynamespace.com//']/wsdl:portType[@name='IMyService']


Error: Cannot import wsdl:binding
Detail: There was an error importing a wsdl:portType that the wsdl:binding is dependent on.
XPath to wsdl:portType: //wsdl:definitions[@targetNamespace='http://mynamespace.com//']/wsdl:portType[@name='IMyService']
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:binding[@name='WSHttpBinding_IMyService']


Error: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is dependent on.
XPath to wsdl:binding: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:binding[@name='WSHttpBinding_IMyService']
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:service[@name='MyService']/wsdl:port[@name='WSHttpBinding_IMyService']


Generating files...
Warning: No code was generated.
If you were trying to generate a client, this could be because the metadata documents did not contain any valid contracts or services
or because all contracts/services were discovered to exist in /reference assemblies. Verify that you passed all the metadata documents to the tool.

Warning: If you would like to generate data contracts from schemas make sure to use the /dataContractOnly option.

Это меня полностью остановило. Несмотря на тяжелый поиск в googling и довольно перекрестный подход, и пересмотр карьеры в качестве водителя автобуса, я, наконец, подумал о том, почему он работал нормально в области разработки. Это может быть проблема конфигурации IIS?

Я удалялся одновременно как в ядро разработки, так и в режиме реального времени, и на каждом из них я запускал диспетчер IIS (работаю с IIS 7.5). Затем я просмотрел каждый параметр конфигурации в каждом окне, сравнивая значения на каждом сервере.

И есть проблема: в разделе "Настройки SSL" для сайта убедитесь, что установлен флажок "Требовать SSL", и установите флажок "Сертификаты клиентских сертификатов" для "Принять". Проблема исправлена!

Ответ 4

Если это произойдет, загляните в окно "Ошибки" и окно "Выход", чтобы узнать, есть ли сообщения об ошибках. Если это не помогает, попробуйте запустить svcutil.exe вручную и посмотрите, есть ли сообщения об ошибках.

Ответ 5

Я обнаружил, что это происходит обычно, когда я добавляю ссылку, удаляю ее, а затем снова добавляю службу с тем же именем. Конфликты типа вызваны тем, что старые файлы остаются где-то еще, что Visual Studio все еще видит. Все, что мне нужно сделать, чтобы исправить это, является чистым, прежде чем добавлять новую ссылку.

Удалите ссылку на службу, имеющую проблемы.
Нажмите на название проекта в Обозреватель решений, чтобы выделить проект.
Щелкните правой кнопкой мыши ссылку на проект.
В верхней части списка контекстов выберите элемент Очистить.
Добавьте ссылку на службу, как обычно.

Надеюсь, что это поможет.

Ответ 6

У меня была эта проблема с Silverlight 5, обновленным от предыдущей версии.

Даже повторное добавление служебной ссылки все равно дало мне пустой Reference.cs

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

Я никогда не выяснял, в чем проблема - но, возможно, что-то в файле .csproj не было обновлено или некоторые настройки поступили не так.

Ответ 7

Если вы недавно добавили коллекцию в свой проект, когда это произошло, проблема может быть вызвана двумя коллекциями, которые имеют тот же атрибут CollectionDataContract:

[CollectionDataContract(Name="AItems", ItemName="A")]
public class CollectionA : List<A> { }

[CollectionDataContract(Name="AItems", ItemName="A")]  // Wrong
public class CollectionB : List<B> { }

Я исправил ошибку, выполнив мой проект и убедившись, что каждый атрибут Имя и ItemName уникален:

[CollectionDataContract(Name="AItems", ItemName="A")]
public class CollectionA : List<A> { }

[CollectionDataContract(Name="BItems", ItemName="B")]  // Corrected
public class CollectionB : List<B> { }

Затем я обновил сервисную ссылку, и все снова работало.

Ответ 8

Моя проблема заключалась в том, что я оставил " mex" в конце моей ссылки веб-службы.

Вместо http://yeagertech.com/yeagerte/YeagerTechWcfService.YeagerTechWcfService.svc/mex"

Используйте http://yeagertech.com/yeagerte/YeagerTechWcfService.YeagerTechWcfService.svc"

Ответ 9

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

Тогда вам просто нужно угадать, что не так с этим кодом.

Конечно, некоторая обратная связь с ошибками в инструменте помогла бы.

Я пишу договор о веб-сервисе. У меня было перечисление заполнителя без членов. Это нормально. Но если я использую его в свойстве другого класса и повторно использую контрактную dll на клиенте, код-домен взрывается без сообщения об ошибке. Запуск svcutil.exe не помог, он просто не смог вывести файл cs без упоминания причины.

Ответ 10

Ниже приведено ниже, и это было решение, которое я принял (SvcUtils было полезно увидеть сообщение об ошибке. Однако ошибка, которую я получил, была wrapper type message cannot be projected as a data contract type since it has multiple namespaces. Смысл, я последовал этому примеру и узнал о wsdl.exe через этот пост.).

В моем случае простой запуск wsdl [my-asmx-service-address] сгенерировал без проблем файл .cs, который я включил в свой проект и предложил использовать эту службу.

Ответ 11

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

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

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

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

Используйте ту же 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-х:

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

Минусы:

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

Ответ 12

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

Итак, с помощью explorer я открыл папку проекта, ссылающуюся на службу и "Общий" -проект. Там я редактирую файл проекта 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

Ответ 13

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

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

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

Ответ 14

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

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

Ответ 15

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

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

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