conflicting namespace problem

[alex sparsky]

I have a rather unique problem that I need some advice on.

I have multiple c# controls that need to make use of a common
namespace. So when I go to include both controls that make use of
that common namespace and one control has a newer version of that
namespace, the compiler complains about ambiguous references.

I've tried using compiler directives to manipulate the namespaces to
be different at compile time but vs.net 2005 keeps giving me grief
over them saying that

Warning 2 A namespace or class definition was found within a
conditional compilation directive in the file "BorderStrip.cs ". This
may lead to an incorrect choice for the manifest resource name for
resource "Common\BorderS trip.resx". MyUserControl2
anyone have any suggestions?

[Michael C]

"alex sparsky" <al**@sparkysys tems.com> wrote in message
news:2d******** *************** *********@4ax.c om...

anyone have any suggestions?
Update them to use the same version?

[Stoitcho Goutsev \(100\) [C# MVP]]

Alex,

Frankly I don't understand the problem very well, but I'd suggest using
aliases (giving namespaces different names at the *using* directive or C#
2.0 new feature - extern aliase - if you want to reference different
versions of the same library.

The warning that you get when using conditional compilation
is because the compiler uses the first namespace it sees, regardles of the
conditional directives, to place the form resource in.
--

Stoitcho Goutsev (100)

"alex sparsky" <al**@sparkysys tems.com> wrote in message
news:2d******** *************** *********@4ax.c om...

I have a rather unique problem that I need some advice on.

I have multiple c# controls that need to make use of a common
namespace. So when I go to include both controls that make use of
that common namespace and one control has a newer version of that
namespace, the compiler complains about ambiguous references.

I've tried using compiler directives to manipulate the namespaces to
be different at compile time but vs.net 2005 keeps giving me grief
over them saying that

Warning 2 A namespace or class definition was found within a
conditional compilation directive in the file "BorderStrip.cs ". This
may lead to an incorrect choice for the manifest resource name for
resource "Common\BorderS trip.resx". MyUserControl2
anyone have any suggestions?

[alex sparsky]

the problem is that I have more than one control that uses a common library. If people have more than one of my controls in a project then they will get more than one idential namespace. Worse yet, the code in those namespaces may be slightly
different based on which version it is.

On Wed, 4 Jan 2006 10:56:00 -0500, "Stoitcho Goutsev \(100\) [C# MVP]" <10*@100.com> wrote:

Alex,

Frankly I don't understand the problem very well, but I'd suggest using
aliases (giving namespaces different names at the *using* directive or C#
2.0 new feature - extern aliase - if you want to reference different
versions of the same library.

The warning that you get when using conditional compilation
is because the compiler uses the first namespace it sees, regardles of the
conditional directives, to place the form resource in.

[Stoitcho Goutsev \(100\) [C# MVP]]

Alex,

I don't think there is a general solution to your problem.
If your controls use the common library internaly without exposing publicly
any type from the common library outside everything will work OK. If the
main code tries to instantiate any of the files in the library there is a
problem and this problem can only be solved in c# 2.0 using extern aliase,
but this should be taken care of the programmer using the controls and even
then it might be not that easy to use.

The only solution I can see is to use the same version for all your
controls.
--

Stoitcho Goutsev (100)
"alex sparsky" <al**@sparkysys tems.com> wrote in message
news:gt******** *************** *********@4ax.c om...

the problem is that I have more than one control that uses a common
library. If people have more than one of my controls in a project then
they will get more than one idential namespace. Worse yet, the code in
those namespaces may be slightly
different based on which version it is.

On Wed, 4 Jan 2006 10:56:00 -0500, "Stoitcho Goutsev \(100\) [C# MVP]"
<10*@100.com> wrote:

Alex,

Frankly I don't understand the problem very well, but I'd suggest using
aliases (giving namespaces different names at the *using* directive or C#
2.0 new feature - extern aliase - if you want to reference different
versions of the same library.

The warning that you get when using conditional compilation
is because the compiler uses the first namespace it sees, regardles of the
conditional directives, to place the form resource in.

[Michael C]

"alex sparsky" <al**@sparkysys tems.com> wrote in message
news:gt******** *************** *********@4ax.c om...

the problem is that I have more than one control that uses a common
library. If people have more than one of my controls in a project then
they will get more than one idential namespace. Worse yet, the code in
those namespaces may be slightly
different based on which version it is.

You didn't answer my question. Why not update the controls to use the same
common library?

Michael

[Stoitcho Goutsev \(100\)]

Michael,

I don't know what the Alex's problem actually is, but I can see where this
can happen and updating control's is not possible. Imagine that I'm
manufacturer of the common library. I sell this library to other companies
and have released couple of versions. Other companies are using my library
to in their own controls. Company A uses version 5 but company B has
released their control using version 2 and doesn't want to upgrade for some
reason. A customer buy controls from Company A and Company B and he/she
cannot use them because of conflicting namespaces.

I don't see easy solution for this. If the common library is build fully
bacword compatible the consumer of the controls can redirect the versions of
the common library to use the latest one, but if the library is not backword
compatible the only solution that I see is to use external aliases.

--

Stoitcho Goutsev (100)
"Michael C" <mc*****@NOSPAM optushome.com.a u> wrote in message
news:%2******** ********@TK2MSF TNGP14.phx.gbl. ..

"alex sparsky" <al**@sparkysys tems.com> wrote in message
news:gt******** *************** *********@4ax.c om...

the problem is that I have more than one control that uses a common
library. If people have more than one of my controls in a project then
they will get more than one idential namespace. Worse yet, the code in
those namespaces may be slightly
different based on which version it is.

You didn't answer my question. Why not update the controls to use the same
common library?

Michael

[Michael C]

"Stoitcho Goutsev (100)" <10*@100.com> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..

Michael,

I don't know what the Alex's problem actually is, but I can see where this
can happen and updating control's is not possible. Imagine that I'm
manufacturer of the common library. I sell this library to other companies
and have released couple of versions. Other companies are using my library
to in their own controls. Company A uses version 5 but company B has
released their control using version 2 and doesn't want to upgrade for
some reason. A customer buy controls from Company A and Company B and
he/she cannot use them because of conflicting namespaces.

But in that case the controls would be in different dirs so there'd be no
problem. The same company would need to ship both versions for there to be a
problem.

Michael

[Stoitcho Goutsev \(100\)]

Why they are going to be in different dirs? If they are in the GAC - Yesm
but if they are privately deployed they might be in the same dir.
Even in different dirs there are going to be a problem if the client of the
control tries to use a type decalred in the common library (e.g. declare a
variable of a type form the custom library) Because there are two versions
of types with exactly the same name (including the namespace) the compiler
cannot pick one of them and will report ambiguity.
--

Stoitcho Goutsev (100)

"Michael C" <mc*****@NOSPAM optushome.com.a u> wrote in message
news:ue******** ******@TK2MSFTN GP10.phx.gbl...

"Stoitcho Goutsev (100)" <10*@100.com> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..

Michael,

I don't know what the Alex's problem actually is, but I can see where
this can happen and updating control's is not possible. Imagine that I'm
manufacturer of the common library. I sell this library to other
companies and have released couple of versions. Other companies are using
my library to in their own controls. Company A uses version 5 but company
B has released their control using version 2 and doesn't want to upgrade
for some reason. A customer buy controls from Company A and Company B and
he/she cannot use them because of conflicting namespaces.

But in that case the controls would be in different dirs so there'd be no
problem. The same company would need to ship both versions for there to be
a problem.

Michael

[alex sparsky]

this is a very astute observation. That is a very close example to
what the reality is. The dll's are usually in the same directory and
included into the same project. Those who are using an older version
of a given library and don't want to upgrade every control will have
the namespace conflict.

On Mon, 9 Jan 2006 09:23:37 -0500, "Stoitcho Goutsev \(100\)"
<10*@100.com> wrote:

Michael,

I don't know what the Alex's problem actually is, but I can see where this
can happen and updating control's is not possible. Imagine that I'm
manufacturer of the common library. I sell this library to other companies
and have released couple of versions. Other companies are using my library
to in their own controls. Company A uses version 5 but company B has
released their control using version 2 and doesn't want to upgrade for some
reason. A customer buy controls from Company A and Company B and he/she
cannot use them because of conflicting namespaces.

I don't see easy solution for this. If the common library is build fully
bacword compatible the consumer of the controls can redirect the versions of
the common library to use the latest one, but if the library is not backword
compatible the only solution that I see is to use external aliases.