C#: Почему первое пространство имен избыточно?

Question

Это немного жуткий.

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

В нашем решении имеется около 50 различных проектов. По большей части библиотеки начинаются с пространства имен OurCompany.

Мы OurComany.This.That и OurCompany.Foo.Bar ... и т.д.

Существует пространство имен/класс столкновение между внешней библиотекой с пространством имен

OurCompany.Foo.Bar 

и класс что квалифицируется как так ..

OurCompany.Some.Location.Foo 

ошибка выглядит следующим образом:

Error 75 The type or namespace name 'MethodName' does not exist in the 
namespace 'OurCompany.Foo' (are you missing an assembly reference?) 

Даже Resharper дает мне сообщение «Классификатор избыточна», когда я полностью квалифицироваться ничего под «Ourcompany» пространство имен .. т.е.

OurCompany.Some.Location.Foo.MethodName(); 
//OurCompany is redundant 

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

я должен заявить, что, если я использую ...

Some.Location.Foo.MethodName(); //Leaving out OurCompany 

... сообщение Resharper уходит.

Answer 1

Мне показалось, что я понял, что здесь происходит, но теперь я вижу какое-то странное поведение, которое заставляет меня подвергнуть сомнению мое понимание поведения пространства имен C#.

Очевидно, что основной проблемой является область обзора. Предположительно, вы работаете над чем-то в каком-то пространстве имен под OurCompany; давайте просто скажем ради аргумента, вы находитесь в OurCompany.This.That. Автоматически любые типы или пространства имен, найденные непосредственно в OurCompany.This.That, OurCompany.This и OurCompany пространства имен в объеме, без необходимости использования.Вот почему все произошло, как только собралась сборка с пространством имен OurCompany.Foo (все в OurCompany по умолчанию включено в область видимости, включая пространство имен Foo, а пространства имен [по-видимому] имеют приоритет), а также почему вы получаете избыточные предупреждения пространства имен (пространство имен Some определено в пространстве имен OurCompany, поэтому оно автоматически входит в область).

Но, пытаясь воспроизвести это поведение, я столкнулся с чем-то странным. Я создал один файл для хранения остальной части соответствующего мира:

namespace OurCompany 
{ 
    namespace Some 
    { 
     namespace Location 
     { 
      public class Foo 
      { 
       public static void MethodName() { } 
      } 
     } 
    } 

    namespace Foo 
    { 
     namespace Bar { } 
    } 
} 

И обнаружил, что следующее (который я собираю подобно тому, что вы делаете) не работает:

using OurCompany.Some.Location; 

namespace OurCompany 
{ 
    namespace This 
    { 
     namespace That 
     { 
      class BeepBoop 
      { 
       private void DoSomething() 
       { 
        Foo.MethodName(); // No good; Foo is a namespace here. 
       } 
      } 
     } 
    } 
} 

... но это сделал:

namespace OurCompany 
{ 
    namespace This 
    { 
     namespace That 
     { 
      using OurCompany.Some.Location; 
      class BeepBoop 
      { 
       private void DoSomething() 
       { 
        Foo.MethodName(); // Puh-wha? This works? 
       } 
      } 
     } 
    } 
} 

Я свободно признаю, что я не знаю, что здесь происходит. Но, видимо, область обзора не так проста, как «Что бы ни было в сфере охвата, и пространства имен имеют приоритет».

Answer 2

Я видел эту ошибку всякий раз, когда мои ссылочные DLL не были построены. Возможно, ссылки не построены и имеют некоторые ошибки сборки. Следовательно, Resharper и VS жалуются на те типы, которые отсутствуют.

Для того, чтобы исправить это, я бы порекомендовал вам сделать следующее:

1. В решении 50 проектов пытаются выяснить базовые проекты. Вы можете использовать заказ сборки проекта (щелкните правой кнопкой мыши sln в обозревателе решений)
2. Отключите все другие проекты и нажмите «Создать сборку».
3. Теперь проверьте правильность сборки. Если сборка не удалась, исправьте ошибки. Если успешное повторение с шага 1.

Я знаю, что это утомительно, но я вижу, что это хороший способ исправить подавляющие (# 3000) ошибки, которые вы видите.