Ошибки компиляции в Reference.cs после добавления Service Reference, вызванного многочастным пространством имен

Я ударил эту странную проблему с пространством имен при добавлении моего первого "Service Reference" в проект клиента в 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 как объявление пространства имен .net System.

На данный момент я использую другое обходное решение, так как я действительно хочу сохранить свои многочастные пространства имен. Моя нынешняя альтернатива - добавить global:: перед ссылками на пространство имен System, чтобы заставить complier делать правильные вещи. Фактически, если мастер "Add Service Reference" использует шаблоны T4, я могу просто изменить их, чтобы внедрить мой обходной путь в исходный код.

Вопросы

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

Ответ 1

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

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

Arrrgghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

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

Ответ 2

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

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

namespace RelatedData.Loader

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

 public class RelatedData
{
}

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

Ответ здесь состоял в том, чтобы переименовать мой класс:

 public class RelatedDataItem

Ответ 3

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

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

Ответ 4

Я столкнулся с аналогичной проблемой с 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 исчезают.

Ответ 5

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

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

MyNamespace.ServiceNamespace

ServiceNamespace

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

Вот как я решаю эту проблему в VisualStudio 2017, пытаясь добавить ссылку на веб-сервис в тестовом проекте.

Попытавшись добавить ссылки, перестроить, закрыть, открыть и потратить некоторое время на решение этой проблемы, я заметил, что VS поместил созданные файлы для ссылки на WS в папку с именем "Подключенные службы".

Я переименовал папку без пробела, затем открыл все файлы в папке и csproj с помощью текстового редактора, заменил все вхождения "Connected Services" на "ConnectedServices" и снова открыл проект.

Затем я добавил ссылки на System.Runtime.Serialization и System.ServiceModel, и теперь все работает нормально.