Interesting namespace conflict problem

A

Andrew

I am having an interesting namespace conflict. When we use a third party
lib we create a company assembly for any descending classes to go in. I
have simplified the problem into the example below.

We are using the third party assembly Abc.Reports so we have an assembly
called ComanyName.Abc.

The problem is when I try to use the class Abc.Reports.Thing it tries to
find it in CompanyName.Abc.Reports.Thing.

It is assuming I have entered a partial namespace path when actually I have
entered a complete path.
What I really need is some way to tell it that it is the full path from the
root like: root.Abc.Reports.Thing.
Is there a way to specifiy that it is the full path?

This can normally be solved by having a "using Abc.Reports" at the top and
then just working with "Thing" but in this case I cannot because "Thing"
exists ambiguously in two places in the third party lib.

Of course I can fix this by just renaming our namespace but I thought it was
an interesting problem that you can't tell the compiler that you are
referring to the full path, or can you?

Example code:

namespace CompanyName.Abc
{
public class MyClass
{
// Get a compile error here:
// I have specified the full namespace path but
// it tries to look for CompanyName.Abc.Reports.Thing
private Abc.Reports.Thing Thing;
}
}
 
I

Ignacio Machin ( .NET/ C# MVP )

I am having an interesting namespace conflict.  When we use a third party
lib we create a company assembly for any descending classes to go in.  I
have simplified the problem into the example below.

We are using the third party assembly Abc.Reports so we have an assembly
called ComanyName.Abc.

The problem is when I try to use the class Abc.Reports.Thing it tries to
find it in CompanyName.Abc.Reports.Thing.

It is assuming I have entered a partial namespace path when actually I have
entered a complete path.
What I really need is some way to tell it that it is the full path from the
root like: root.Abc.Reports.Thing.
Is there a way to specifiy that it is the full path?

This can normally be solved by having a "using Abc.Reports" at the top and
then just working with "Thing" but in this case I cannot because "Thing"
exists ambiguously in two places in the third party lib.

Of course I can fix this by just renaming our namespace but I thought it was
an interesting problem that you can't tell the compiler that you are
referring to the full path, or can you?

Honestly, I would rename your namespace and be done with it. Cause if
you think about the same problem can present to another developer
under your same escenario.

In any case global:: prefix will solve your problem
 
B

Brian Gideon

This can normally be solved by having a "using Abc.Reports" at the top and
then just working with "Thing" but in this case I cannot because "Thing"
exists ambiguously in two places in the third party lib.

Well, this may come as a shock, but that isn't necessarily true. And
in the interest of discussing other namespace oddities consider this
example which I've posted several times before in this group.

// The following line imports namespace B types (Bar1 & Bar2).
using B;
namespace A.C.D
{
// The following line imports namespace A.B types (Foo1 & Foo2).
using B;
}

namespace A.B
{
public class Foo1 { }
public class Foo2 { }
}

namespace B
{
public class Bar1 { }
public class Bar2 { }
}
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top