Неоднозначные ссылки со связанным .CS File и WCF Service

Question

Неоднозначные ссылки со связанным .CS File и WCF Service

2

Для краткости этот пост относится к неоднозначным ссылкам в файле Silverlight Page.XAML.CS, проект которого содержит ссылку на службу WCF и файл MyClass.cs, добавленный как "ссылка". Решение содержит проект Silverlight и веб-проект, содержащий службу WCF и файл MyClass.cs(вместе с файлами aspx и т.д.).

По какой-то причине я получаю неоднозначные ссылочные ошибки, когда добавляю ссылку на службу на страницу page.xaml.cs. Перед добавлением оператора using для ref ref, у меня был один для MyClass.cs(который был добавлен в проект SL в качестве ссылки) на страницу, и он работал нормально. После добавления ссылки SVC компилятор жалуется на неоднозначность в моем вызове любому классу/свойству в MyClass.cs, так что ссылка на MyClass.Class становится двусмысленной для "ServiceReference.MyClass.Class... Кажется, очень странно меня.

Предположения и разъяснения

Я гарантировал, что имена пространств имен, имен классов, методов или переменных не имели похожих имен
Служба WCF должна находиться в веб-приложении, чтобы иметь доступ к другим сборкам не Silverlight и т.д.
Другие .cs файлы в проекте Silverlight Project MyClass.cs, иначе я бы просто удалил ссылку на MyClass.cs и разрешил ссылку MyClass.cs через ссылку службы.

Мое предположение заключается в том, что это как-то связано с добавлением файла в качестве ссылки? Любой KungFu Masters там может предложить некоторое представление о том, почему это происходит, альтернативы добавлению в качестве связанного файла, другие идеи?

Nigel Sampson 30 июль 2009, в 03:18

Источник

Теги:

c#

visual-studio

wcf

silverlight

4 ответа

Ещё вопросы

Nigel Sampson · Answer 1 · 2009-07-30T02-17-00.000Z

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

Вы можете использовать опцию "Повторное использование в ссылочных сборках" при создании Service Reference, чтобы созданный прокси-сервер службы использовал связанный класс, а не генерировал новый. Однако есть несколько трюков, чтобы заставить это работать правильно, я изложил их в сообщении несколько месяцев назад. Resoing types в ссылках на службы Silverlight.

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

John Saunders · Answer 2 · 2009-07-30T00-51-00.000Z

Является ли MyClass классом, используемым службой, для которой вы добавили ссылку на службу? Если true, то в MyClass.cs есть две версии каждого класса: одна из MyClass.cs и одна из справки службы.

Вы должны выбрать тот или другой - либо использовать службу, либо не использовать эту услугу.

Hunter Kingsley · Answer 3 · 2016-10-25T10-27-00.000Z

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

PortageMonkey · Answer 4 · 2009-07-30T13-07-00.000Z

Nigel Sampsons Отвечал мне в правильном направлении, благодаря миллиону!

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

В отличие от типичного сценария обслуживания клиент/сервер, файл класса должен быть скомпилирован отдельно для Siverlight и ASP.NET.

Это потому, что это две разные платформы с разными фреймворками.