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

Question

Я столкнулся с этой странной проблемой пространства имен при добавлении моего первого «Справочника услуг» в клиентский проект в Visual Studio 2010.

Если пространство имен по умолчанию для моего проекта использует две или более частей, например, MyCompany.MyApp затем при добавлении ссылки на службу создается файл Reference.cs, содержащий пространство имен MyCompany.MyApp.ServiceReferenceName с большим количеством кода автоматического создания с полностью определенными именами, например, System.SerializableAttribute, System.Runtime.Serialization.DataContractAttribute.

Файл Reference.cs будет полон ошибок компиляции, поскольку компилятор начинает обрабатывать пространство имен System как подчиненный элемент пространства имен MyCompany.MyApp. Вы получаете очень много ошибок по типу:

The type or namespace name 'Runtime' does not exist in the namespace 'MyCompany.MyApp.System'...

Если я изменю пространство имен в верхней части файла Reference.cs на что-то простое, например, MyCompanyMyApp.ServiceRefernceName затем компилятор ведет себя и распознает ссылки на пространство имен System как декларацию пространства имен System.

Сейчас я использую другой обходной путь, поскольку я действительно хочу сохранить свои пространства имен из нескольких частей. Моя текущая альтернатива - добавить global:: перед ссылками пространства имен System, чтобы заставить компилятор сделать правильную вещь. Фактически, если мастер «Добавить ссылку на службу» использует шаблоны T4, я могу просто изменить их, чтобы встроить мой обходной путь в источник.

Вопросы * * 1023 Мне бы очень хотелось понять, что здесь происходит и почему проблема состоит из пространства имен, состоящего из нескольких частей. Предположительно есть больше пространства имен, чем я думал. Во-вторых, очень хотелось бы найти лучшее решение, чем выполнение глобального поиска / замены каждый раз, когда я добавляю ссылку на сервис или слоняюсь с некоторыми шаблонами T4.

Answer 1

Я нашел ответ здесь несколько неясным, поэтому я решил добавить его в качестве примера (я бы сделал это в комментариях, но здесь он выглядит лучше):

Итак, у меня есть это в качестве пространства имен по умолчанию:

namespace RelatedData.Loader

Но я также добавляю класс с именем:

 public class RelatedData
{
}

Поскольку имя класса совпадает с частью пространства имен, когда он генерирует ваш прокси с помощью Add Service Reference, он запутывается.

Ответом было переименовать мой класс:

 public class RelatedDataItem

Answer 2

А, ну, в конце концов я нашел причину.

Я работаю против очень большого стороннего API WCF и ... одно из их пространств имен - LameCompany.System (!!) Затем следует Carnage ...

Arrrgghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

Урок, который необходимо усвоить, заключается в том, что компилятор Visual Studio / .net перестает распознавать пространство имен System BCL *1008* * в вашем проекте, называемое в вашем проекте.Найдите его, удалите его, застрелите разработчика, который его создал.

Answer 3

Я обнаружил, что наличие имени класса, похожего на ваше пространство имен, вызывает это.

Попробуйте переименовать имя класса

Answer 4

Я пробовал разные вещи (и пробовал разные пространства имен при добавлении ссылки на службу), но у меня ничего не получалось, кроме этого грубого исправления - в моем случае это было нормально, но я знаю, что это некрасиво (и нужно повторить, если используйте «Обновить ссылку» в будущем):

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

MyNamespace.ServiceNamespace

с

ServiceNamespace

во всем решении (конечно, используйте ваши собственные пространства имен), включая автоматически сгенерированный файл Reference.cs.

Answer 5

Я столкнулся с похожей проблемой с VS2012, описанной jabu.hlong и Саймоном Нидхэмом после незначительных изменений в клиентском проекте, в котором есть ссылки на службы WCF после обновления ссылки на службы.Я получил много ошибок при компиляции сгенерированных файлов Reference.cs и т. Д. (Также сгенерированных файлов XAML).

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

Ошибка, которую я получаю, заключается в том, что пространство имен повторно используемой сборки и пространство имен сгенерированных типов невозможно найти при использовании в файле Reference.cs.Оба пространства имен имеют общие первые части, так как они из одного решения.Мои пространства имен в решении похожи на appname.tier.technology.project.Оба конфликтующих пространства имен: Appname.Dto.Modulename (повторно используемая сборка) и Appname.Client.Wpf.ServiceName (пространство имен в клиентском проекте, использующем службы для сгенерированных типов).

Проблема возникает после незначительного изменения в клиентском проекте,когда я создал новый служебный класс в пространстве имен Appname.Client.Wpf.Appname.Я выбираю это пространство имен, потому что Appname также является именем модуля в клиентском проекте.Это, кажется, запутывает компилятор и не может разрешить оба пространства имен в сгенерированном Reference.cs.После изменения пространства имен служебного класса, чтобы избежать использования в нем двух идентичных частей и обновления ссылки на службу, ошибки компилятора в Reference.cs исчезают.

Answer 6

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

Answer 7

В моем проекте была папка под названием «Система» (да, очень глупо с моей стороны), и это вызвало некоторые проблемы в файле reference.cs.

Переименование папки (и пространства имен), исправило проблему.