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\BorderStrip.resx". MyUserControl2


anyone have any suggestions?

 

[Michael C]

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.

 

[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.

 

[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.

 

[Michael C]

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.

 

[Michael C]

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.

 

[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.

 

[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.

 

[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.