Що означає ця помилка WCF: «Попередження користувацького інструменту: Не вдається імпортувати wsdl: portType»

Я створив проект бібліотеки служб WCF у своєму рішенні і маю посилання на сервіс на це. Я використовую послуги з бібліотеки класів, тому на додаток до бібліотеки класів у мене є посилання з мого проекту програми WPF. Послуги налаштовуються прямо вперед - змінюються лише для отримання асинхронних службових функцій.

Все працювало нормально - поки я не захотів оновити свої посилання на служби. Це не вдалося, тому я врешті відкотився і спробував, але навіть тоді не вдалося! Отже - оновлення посилань на сервіс не вдається, не вносячи в нього жодних змін. Чому ?!

Я отримую цю помилку:

Custom tool error: Failed to generate code for the service reference 
'MyServiceReference'.  Please check other error and warning messages for details.   

Попередження містить більше інформації:

Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: 
System.ServiceModel.Description.DataContractSerializerMessageContractImporter
Error: List of referenced types contains more than one type with data contract name 'Patient' in  
namespace 'http://schemas.datacontract.org/2004/07/MyApp.Model'. Need to exclude all but one of the 
following types. Only matching types can be valid references: 
"MyApp.Dashboard.MyServiceReference.Patient, Medski.Dashboard, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" (matching)
"MyApp.Model.Patient, MyApp.Model, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" (matching)
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:portType[@name='ISomeService']

Є також два подібних попередження:

Custom tool warning: 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://tempuri.org/']/wsdl:portType[@name='ISomeService']
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:binding[@name='WSHttpBinding_ISomeService']  

І те саме для:

Custom tool warning: Cannot import wsdl:port .. 

Я вважаю це все заплутаним .. У мене немає класу Patient на інформаційній панелі на стороні клієнта, за винятком того, який я отримав через посилання на службу. То що це означає? І чому це раптом видно? Пам’ятайте: я навіть нічого не міняв!

Тепер рішення цього було знайдено тут , але без пояснення того, що це означає. Тому; у "Налаштувати посилання на службу" для послуги я знімаю прапорець "Повторне використання типів у збірках, на які посилаються". Відновляючи зараз, все це працює без проблем. Але що я насправді змінив? Чи вплине це на мою заявку? І коли потрібно зняти це позначення? Я хочу повторно використовувати типи, для яких я налаштував DataContract, але не більше. Чи я все одно отримаю доступ до тих, хто не перевірив це?

Коли ви додаєте посилання на послугу, існує два способи обробки типів, які використовуються службою:

• Типи зберігаються у DLL, і на неї посилаються як клієнт, так і серверна програма.
• Типи відсутні в DLL, на яку посилається клієнт. У цьому випадку інструмент, який створює посилання на службу, створить типи у файлі references.cs.

Є багато речей, які можуть піти не так. Ми виявили, що якщо інструмент виходить з ладу, іноді швидше видалити посилання на службу та розпочати знову.

Ми перестали використовувати посилання на послуги. Для проектів, де ми контролюємо клієнта та послугу, ми використовуємо метод, описаний у цьому скрінкасті .

Я знайшов свою відповідь тут: http://www.lukepuplett.com/2010/07/note-to-self-don-let-wcf-svcutil-reuse.html

Коротко кажучи: Я відмітив Повторне використання типів у довідкових збірках у меню Додатково .

Я не знаю, чи це має значення, але я використовую не MVC, а веб-форми.

У мене також було це питання сьогодні. У мене знадобився цілий день, щоб знайти свою помилку. Сподіваюся, це допоможе.

Мій клас, який не вдалося імпортувати, має властивість типу cutom enum. Ця властивість позначена як DataMember, а Enum також позначена як DataContract. Поки що все добре. Я просто забув позначити кожного члена перерахування як EnumMember.

Тож я змінився

[DataContract]
public enum SortMethodType
{
    Default = 0,
    Popularity = 1,
    ReleaseDate = 2,
    PublishedDate = 3,
    TranslatedTitle = 4,
    OriginalTitle = 5,
    UserRating = 6,
    Duration = 7
}

До цього:

[DataContract]
public enum SortMethodType
{
    [EnumMember]
    Default = 0,
    [EnumMember]
    Popularity = 1,
    [EnumMember]
    ReleaseDate = 2,
    [EnumMember]
    PublishedDate = 3,
    [EnumMember]
    TranslatedTitle = 4,
    [EnumMember]
    OriginalTitle = 5,
    [EnumMember]
    UserRating = 6,
    [EnumMember]
    Duration = 7
}

І нарешті вдалося!

Перейдіть до Додаткові властивості, додаючи посилання та видаліть "System.Window.Browser" із контрольного списку. Це вирішує проблему.

це може здатися дивним, але я виправив це, видаливши посилання, закривши Visual Studio, знову відкривши його і, нарешті, знову додавши посилання.

Я думаю, що спеціальний інструмент потрібно було перезапустити або щось інше.

Я постійно стикаюся з цією помилкою, поки вона працює на іншій машині розробників. Незважаючи на те, що я є повним адміністратором скрізь у своїй віртуальній машині, я спробував закрити Visual Studio і повторно відкрити його за допомогою "Запуск від імені адміністратора", і це магічно спрацювало.

Удачі.

Я отримав попередження після оновлення мого рішення з Visual Studio (VS) 2010 до 2013 року та зміни .NET Framework кожного проекту з 4 на 4.5.1. Я закрив VS і знову відкрив, і попередження зникли.

Недоліком відключення `` типів повторного використання у збірках, на які посилаються '' є те, що це може спричинити проблеми з неоднозначними посиланнями. Це пов’язано із тим, що посилання на службу створює ці об’єкти знову у файлі посилання .cs, і ваш код, що реалізує службу, може посилатися на них із вихідного простору імен.

Коли такий сценарій відбувається, я вважаю корисним перевірити `` типи повторного використання у вказаних збірках, на які посилаються '', що дозволяє мені вибрати лише ті, що мають неоднозначні посилання, що швидко вирішує проблему таким чином.

Сподіваюся, це допомагає комусь іншому.

Мої інтерфейси служби WCF знаходяться в збірці, реалізація - в іншій, а посилання на службу - у ще одній збірці, окремо від клієнтів посилання на послугу. Я отримав повідомлення про помилку відразу після того, як застосував DataContract до переліку. Після того, як я застосував EnumMember до полів переліку, проблема вирішена.

Якщо ви сумніваєтеся, що у вашої служби не виникає проблем (таких як проблеми з переліченнями чи несеризуються класи, як згадано іншими), спробуйте створити новий проект з новим посиланням.

Я використовую Silverlight 5, і я кілька разів намагався видалити та відтворити посилання. reference.csФайл просто придумав повністю спустошити кожен раз , і це було буквально роками , так як я створив його так , намагаючись з'ясувати , що змінилося в службі була і мова.

Я помітив, що помилка містить посилання на 2.0.5.0. Зараз я навіть не знаю, чи це насправді стосується версії Silverlight, але це змусило мене подумати просто створити абсолютно новий проект, а потім раптом все запрацювало.

Попередження 2 Попередження спеціального інструменту: Не вдається імпортувати wsdl: portType Детально: під час запуску розширення імпорту WSDL було видано виняток: System.ServiceModel.Description.DataContractSerializerMessageContractImporter Помилка: Не вдалося завантажити файл або збірку 'System.Xml, версія = 2.0.5.0, Культура = нейтральна, PublicKeyToken = 7cec85d7bea7798e 'або одна із залежностей. Система не може знайти вказаний файл. XPath до помилки Джерело: // wsdl: визначення [@targetNamespace = ''] / wsdl: Тип порту [@ name = 'IShoppingCart']

Я переглядав свій проект і мав те саме питання. Виявилося, що це різні версії тієї самої DLL на WCF проти веб-сайту. Веб-сайт мав новішу версію DLL, і служба посилалася на стару версію DLL. Одного разу всі вони синхронізувались, і всі працювали добре.

Я зазнав ту ж помилку. Я боровся майже день, намагаючись з’ясувати, що пішло не так. Підказкою для мене стали попередження, які кидав В.С. Він намагався зробити якесь зіставлення з Yahoo.Yui.Compressor.dll, бібліотекою, яку я додав і видалив (оскільки вирішив не використовувати її) за пару днів до цього. Це було шокуючим, бо бібліотеки там не було, але якось вона намагалася посилатися на неї.

Нарешті, я відновлюю цю dll зі Сміття, і тоді я міг успішно оновити посилання на службу.

Для будь-кого тут у майбутньому у мене була однакова помилка, але спричинена проблемами версії, двома різними способами.

У мене є дві служби WCF та дві клієнтські програми, які спілкуються через посилання на сервіс. Я оновив пакет nuget з обох сторін і спробував оновити посилання на службу і отримав цю помилку.

Видалення не допомогло. Знімати прапорець біля "повторного використання збірок" не бажано, оскільки мені потрібно їх повторно використовувати - у цьому вся суть.

Зрештою, було два окремі питання:

1) Першим випуском, на мою думку, було питання кешування візуальної студії. Я прискіпливо переглянув усі посилання і не виявив жодних проблем, але він все одно повідомив, що не може знайти попередню версію файлу. Я видалив усі пакети nuget, перезапустив Visual Studio і перевстановив їх. Оновлення посилання на послугу спрацювало.

2) Друге питання було спричинене проблемою залежності. Я оновив пакет nuget з обох сторін, і все виявилося правильно, але немаркована залежність не синхронізувалась. Приклад:

Пакет Foo v1 посилання Bar v1. Можна оновити Foo і Bar до v2 самостійно, не оновлюючи посилання. Якщо ви встановите Foo і Bar v2, службовий довідковий інструмент просканує Foo v2, перегляньте посилання на Bar v1 і не вдасться виконати помилку, оскільки він не може знайти стару версію. Про це повідомляється правильно, лише якщо ви оновлюєте номери версій вашого dll для кожного пакета. Visual Studio та MSBuild не матимуть проблем зі створенням програми, але посилання на службу буде жахливо намагатися вирішити все.

Сподіваюся, це комусь допомагає.