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]

Re: conflicting namespace problem

"alex sparsky" <alex@sparkysys tems.com> wrote in message
news:2ddjr1tsk0 300j92ljo1aopkg 1tvjitqfr@4ax.c om...[color=blue]
> anyone have any suggestions?[/color]

Update them to use the same version?
[color=blue]
>
>[/color]

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

Re: conflicting namespace problem

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" <alex@sparkysys tems.com> wrote in message
news:2ddjr1tsk0 300j92ljo1aopkg 1tvjitqfr@4ax.c om...[color=blue]
>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?
>
>[/color]

[alex sparsky]

Re: conflicting namespace problem

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]" <100@100.com> wrote:
[color=blue]
>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.[/color]

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

Re: conflicting namespace problem

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" <alex@sparkysys tems.com> wrote in message
news:gtgqr11af1 t00k2n74ojq1v5q 6tttu89m1@4ax.c om...[color=blue]
> 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]"
> <100@100.com> wrote:
>[color=green]
>>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.[/color]
>[/color]

[Michael C]

Re: conflicting namespace problem

"alex sparsky" <alex@sparkysys tems.com> wrote in message
news:gtgqr11af1 t00k2n74ojq1v5q 6tttu89m1@4ax.c om...[color=blue]
> 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.[/color]

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

Michael

[Stoitcho Goutsev \(100\)]

Re: conflicting namespace problem

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" <mculley@NOSPAM optushome.com.a u> wrote in message
news:%23avXatJF GHA.2012@TK2MSF TNGP14.phx.gbl. ..[color=blue]
> "alex sparsky" <alex@sparkysys tems.com> wrote in message
> news:gtgqr11af1 t00k2n74ojq1v5q 6tttu89m1@4ax.c om...[color=green]
>> 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.[/color]
>
> You didn't answer my question. Why not update the controls to use the same
> common library?
>
> Michael
>[/color]

[Michael C]

Re: conflicting namespace problem

"Stoitcho Goutsev (100)" <100@100.com> wrote in message
news:%23QYY0fSF GHA.2892@TK2MSF TNGP10.phx.gbl. ..[color=blue]
> 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.[/color]

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

Re: conflicting namespace problem

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" <mculley@NOSPAM optushome.com.a u> wrote in message
news:ueO7XuWFGH A.3172@TK2MSFTN GP10.phx.gbl...[color=blue]
> "Stoitcho Goutsev (100)" <100@100.com> wrote in message
> news:%23QYY0fSF GHA.2892@TK2MSF TNGP10.phx.gbl. ..[color=green]
>> 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.[/color]
>
> 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
>[/color]

[alex sparsky]

Re: conflicting namespace problem

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\)"
<100@100.com> wrote:
[color=blue]
>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.[/color]

[Nick Hounsome]

Re: conflicting namespace problem

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" <alex@sparkysys tems.com> wrote in message
news:hsmrs19b88 nolle35d7v2qtaf m2bmvd1bt@4ax.c om...[color=blue]
> 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\)"
> <100@100.com> wrote:
>[color=green]
>>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.[/color]
>[/color]

[Stoitcho Goutsev \(100\)]

Re: conflicting namespace problem

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" <nh002@nickhoun some.me.uk> wrote in message
news:sbnzf.2353 7$lL4.15627@fe1 .news.blueyonde r.co.uk...[color=blue]
> 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" <alex@sparkysys tems.com> wrote in message
> news:hsmrs19b88 nolle35d7v2qtaf m2bmvd1bt@4ax.c om...[color=green]
>> 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\)"
>> <100@100.com> wrote:
>>[color=darkred]
>>>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.[/color]
>>[/color]
>
>[/color]