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

Question

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

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

Допущения и уточнения

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

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

Answer 1

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

Вы можете использовать опцию «Повторное использование типов в ссылочных сборках» при создании ссылки на службу, чтобы сгенерированный прокси службы использовал ваш связанный класс, а не генерировал новый. Однако есть несколько приемов, чтобы заставить это работать правильно, я обрисовал их в посте несколько месяцев назад Возобновление типов в сервисных ссылках Silverlight .

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

Answer 2

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

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

Answer 3

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

Answer 4

Ответ Найджела Сампсона привел меня в правильном направлении, спасибо миллион!

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

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