It seems that the confusion here is about the conceptualization of what is namespace
.
A namesapace
is a surname for a type (a class for example). If you have a namespace X
and a class Y
. Is the same as saying you stated class X.Y
.
Import
When you put the import X
, you are just telling the compiler that it should search for types (classes for example) used in your code in that file (technically in any code that is below the directive import
). Then the compiler understands that you used the class Y
in its code and has a import X
. Everything will work because he finds the class, he has the full name of the class.
When using a class member you can refer to a Z method such as X.Y.Z()
and not use the import
. This way it becomes clearer than the namespace
is just a class surname.
Namespace is not encapsulation
So you can have repetition of namespace
s everywhere in your software. It does not compartmentalize anything. In . NET this compartmentalization occurs through the Assembly. Which is roughly the equivalent of package
of Java. Actually the package
also organizes such last name of the type at the same time. The last name of the type is the same of the package where it is.
A package
has path, as well as the Assembly. But in . NET this does not matter in the code. The Assembly is inserted in the project externally to the code. C# and VB.NET separated the concept of code package and type grouping (classes, enums, etc.).
The namespace
transcends the assembly
and are orthogonal concepts. Effectively when the code is compiled, the namespace
disappears and only one guy with a last name is in the code.
Disambiguation
If your code has the same class in namespace
different s, you need to use the full name (you can even use the import
to create an alias for a namespace
to facilitate).
But if you have the same class in it namespace
, some error must occur. So much so that the only way to have twice the same name for a class is by using partial
which indicates that in different sources you have the same complement each other. But it doesn’t seem to be your case.
Assembly X namespace
The fact that there is a Assembly and a namespace
with the same name, it’s just coincidence. They’re very different things. The Assembly is referenced in the project (it may be that the problem is there).
Your case
If you took the import
s and no problem happened, you were not using any kind contained in namespace
s "imported". If you change the name of namespace
that really is necessary, will give error.
It is possible that some of these files that you say have duplicate classes are not even being referenced in the project. Could be it was garbage, test, I don’t know, that the previous programmer left there unnecessarily.
If you need more specific information, we need to better understand how your project and code are structured.
For more information you can read that one and that one reply.
Do you know Java? as
namespace
are for C# the same thing as thepackages
are for Java as far as I remember.– Marciano.Andrade
I know a little bit about java yes. And as far as I understand the namespace was to call yyy.Asp because it’s the path equivalent. Since the namespace does not have a full path.
– Iago Leão
@Andrade They are not, there is a huge conceptual difference between
namespace
s andpackage
s. In C# the equivalent ofpackage
would be theassembly
.– Maniero
@bigown I heard this once in a discussion about the differences and equivalences between C# and Java, but could not say, so I commented that as far as I remember was this. I’ll take a look at the concepts
– Marciano.Andrade
In fact, I was wrong too, because the
package
is not the same as theassembly
, after all it carries a concept ofnamespace
together. Package and type naming get mixed up in Java. In C# or VB.Net it is that they are totally separated.– Maniero
You can accept one of the answers if it helped you. None helped? There is something in my answer that I would need to improve to meet 100% of what you need?
– Maniero