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?

[Nick Hounsome]

This is exactly what strong names and the GAC are for.

Of course they are far more useful to microsoft than to anyone else because
they are incompatible with no-touch/xcopy deployment which isn't a problem
for them as (1) the runtime is free (2) you can reasonably expect people to
install the latest.

This is also a good reason for sticking to the standard controls wherever
possible.

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

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
manufacture r 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\)]

Nick,

Strong names in the GAC won't help in all of the cases. They will work as
long as all the types in the assemblies with the multiple versions are used
internally in the controls or users don't use the type names explicitly.
Imagine that there are multiple versions of the assembly foo.dll in the GAC
and there are two copies with different versions of that assembly loaded.
both assemblies expose a class called Foo.

As soon as the user decides to use that name in their code

Foo f = new Foo();

the compiler will fire an error because there are two types Foo comming from
different assemblies. The namespaces are the same, the name of the type is
the same. This problem has no resolution until .NET2.0 and external aliases.
--

Stoitcho Goutsev (100)
"Nick Hounsome" <nh***@nickhoun some.me.uk> wrote in message
news:sb******** ***********@fe1 .news.blueyonde r.co.uk...

This is exactly what strong names and the GAC are for.

Of course they are far more useful to microsoft than to anyone else
because they are incompatible with no-touch/xcopy deployment which isn't a
problem for them as (1) the runtime is free (2) you can reasonably expect
people to install the latest.

This is also a good reason for sticking to the standard controls wherever
possible.

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

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
manufactur er 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.