Служба WCF, которая возвращает пользовательский класс, генерирует ошибки в Reference.cs - PullRequest
Новая
       14

Служба WCF, которая возвращает пользовательский класс, генерирует ошибки в Reference.cs

6 голосов
/ 29 октября 2009

У меня есть проект службы WCF в Visual Studio 2008, который содержит около 12 методов, некоторые из которых возвращают примитивные типы, такие как bool или string. У меня также есть тестовый проект Visual Studio, который ссылается на опубликованную службу WCF. Тестовый проект успешно компилируется, когда все возвращаемые типы являются примитивными.

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

  1. Тип «PublisherFaultException» уже содержит определение «Причина».
  2. Тип «PublisherFaultException» уже содержит определение «PropertyChanged».
  3. Тип «Publisher.Test.LibraryReference.PublisherFaultException» уже определяет член с именем «RaisePropertyChanged» с теми же типами параметров.

все в автоматически сгенерированном файле reference.cs.

Договор на метод Службы WCF: - 

Page GetItem(string path);

и класс Page имеет атрибут DataContract, а его общедоступные свойства имеют атрибут DataMember.

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

Кто-нибудь знает, почему это происходит?

Стюарт.

Ответы [ 3 ]

1 голос
/ 14 октября 2010

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

Для обработки подобной ситуации я использовал отдельную сборку с классами контрактов данных и интерфейсом обслуживания.

Контракт dll будет иметь: 


public interface IService
{
    [OperationContract]
    List GetContentList();
}

[DataContract]
public class ContentItem
{
  [DataMember] public string Name;
  [DataMember] public object Data;
}

У клиента будет ссылка на Contract.dll. Прокси будет создан вручную: 


class ServiceProxy : ClientBase<IService>, IService
 {
  public List GetContentList()
  {
   return Channel.GetContentList();
  }
 }

Сервер DLL будет иметь ссылку на тот же контракт DLL. Таким образом, мы сможем избежать любых ошибок с автоматически сгенерированным прокси. Кроме того, созданный вручную прокси-сервер будет проще, более управляемым.

1 голос
/ 29 октября 2009

Когда вы добавляете ссылку на сервис, вы получаете опцию «повторное использование типов в сборке» - это, вероятно, ключ к устранению дублирования.

Или у вас есть тестовые ссылки, которые вызывают дублирование?

Кроме того, посмотрите в разделе «Ссылки» дерева проекта и посмотрите, есть ли там что-то непредвиденное (есть ли у вас ссылки на 2 сборки, которые обе содержат ссылки на службы в одном и том же пространстве имен?).

0 голосов
/ 05 сентября 2014

При добавлении справочника услуг попробуйте нажать кнопку «Дополнительно» и выбрать «Создать асинхронные операции».

Я думаю, что в веб-сервисе было несколько асинхронных методов с именами, заканчивающимися на "Async", которые конфликтуют с методами, сгенерированными в References.cs.

например. Представьте, что веб-сервис содержит 2 метода: (1) SayHello и (2) SayHelloAsync.

Генерация с использованием метода на основе задач по умолчанию приводит к:

  • SayHello и SayHelloAsync для (1)
  • SayHelloAsync и SayHelloAsyncAsync для (2).

Конфликт произошел из-за того, что было создано 2 метода с именем SayHelloAsync.

По крайней мере, я так думаю. В любом случае настройка «Генерировать асинхронные операции» у меня сработала.

...