469,623 Members | 1,850 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,623 developers. It's quick & easy.

A namespace implemented over several different assemblies?

Hi all,

Can anyone tell me if it is advisable (or even possible) to define a namespace
across 2 or more assemblies?

For example, consider the namespace SampleApplication.Data.Providers

Would it be possible to have assembly A define a class as part of that namespace
as well as Assembly B also declaring a class to be within it as well?

In particular, I have a number of data providers. It would be useful (I think)
to declare them in the same namespace, but for the purposes of a demonstration
I'm doing, each provider must exisit in its own seperately deployed assembly.

Is this possible and is it a good idea?

Thanks to anyone who can share some advice! :-)

Kindest Regards

tce
Nov 17 '05 #1
7 8007
It's definitely possible and there is nothing wrong with it. The .NET
framework itself has namespaces spread across multiple assemblies. For
example, the System.Data namespace and the System.Web, System.Web,
System.Drawing, etc., etc., etc. namespaces are implemented in multiple
assemblies.

It's perfectly fine in my opinion as long as it is clear to the users of
your class library that what assembly they will need to reference for given
functionality.
Hope this helps.

Brian Delahunty
Ireland

http://briandela.com/blog
"thechaosengine" wrote:
Hi all,

Can anyone tell me if it is advisable (or even possible) to define a namespace
across 2 or more assemblies?

For example, consider the namespace SampleApplication.Data.Providers

Would it be possible to have assembly A define a class as part of that namespace
as well as Assembly B also declaring a class to be within it as well?

In particular, I have a number of data providers. It would be useful (I think)
to declare them in the same namespace, but for the purposes of a demonstration
I'm doing, each provider must exisit in its own seperately deployed assembly.

Is this possible and is it a good idea?

Thanks to anyone who can share some advice! :-)

Kindest Regards

tce

Nov 17 '05 #2
I would say that, while possible to do this, it is not necessarily best
practice. For management purposes, you will want to encapsulate an
entire namespace in a single assembly. This will help with maintenance
down the line, and will also help avoid silly problems like duplicate
class names in the same namespace (but different assemblies).

The .NET Framework IS indeed split into multiple assemblies, but I do
not know of a case where a single namespace is split accross
assemblies. By that, I mean that while the System.Web and
System.Web.Mobile namespaces may be split into multiple assemblies, you
will not find System.Web itself in multiple assemblies.

I hope this helps,

Tim Aranki

Nov 17 '05 #3
Tim,

Actually, there are a number of namespaces with functionality split
between System.dll and mscorlib.dll (System, System.Net, System.IO, etc,
etc). Of course, this doesn't really matter so much, because pretty much
every program in existence is going to have references to these two
assemblies (as a matter of fact, the C# compiler automatically references
mscorlib.dll by default unless you tell it not to).

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"tim.aranki" <ti********@gmail.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...
I would say that, while possible to do this, it is not necessarily best
practice. For management purposes, you will want to encapsulate an
entire namespace in a single assembly. This will help with maintenance
down the line, and will also help avoid silly problems like duplicate
class names in the same namespace (but different assemblies).

The .NET Framework IS indeed split into multiple assemblies, but I do
not know of a case where a single namespace is split accross
assemblies. By that, I mean that while the System.Web and
System.Web.Mobile namespaces may be split into multiple assemblies, you
will not find System.Web itself in multiple assemblies.

I hope this helps,

Tim Aranki

Nov 17 '05 #4
System.Web is in both System.dll and System.Web.dll with classes from the
namespace in both dll's. The System namespace itself is split across multiple
dll's. System.Resources is split across multiple dll's, System.Xml has
classes in System.dll and System.Xml.dll, etc., etc., etc.. There are a
number of namespaces like this. Reflector is a great tool :-)

I know that it can lead to issues with management down the line and I should
have addressed that in my response but I was just trying to say that it's
possible and it's done by the .NET framework itself. I agree completely that
it could lead to issues.

--
Brian Delahunty
Ireland

http://briandela.com/blog
"tim.aranki" wrote:
I would say that, while possible to do this, it is not necessarily best
practice. For management purposes, you will want to encapsulate an
entire namespace in a single assembly. This will help with maintenance
down the line, and will also help avoid silly problems like duplicate
class names in the same namespace (but different assemblies).

The .NET Framework IS indeed split into multiple assemblies, but I do
not know of a case where a single namespace is split accross
assemblies. By that, I mean that while the System.Web and
System.Web.Mobile namespaces may be split into multiple assemblies, you
will not find System.Web itself in multiple assemblies.

I hope this helps,

Tim Aranki

Nov 17 '05 #5
Tim,
The System.Uri type is in the System assembly, while System.String type is
in the mscorlib assembly.

Most of System.Xml is in the System.Xml assembly, while
System.Xml.XmlDataDocument is in the System.Data assembly.

System.Diagnostics is split between the mscorlib & System assemblies. As
well as a number of other namespaces are split between mscorlib & System
assemblies.

System.Web is split between the System & System.Web assemblies.

I'm sure there are others, I just tried to highlight the "common" ones...

Although I agree spliting may not always make sense, in the case of
XmlDataDocument I think it makes sense to include it in the System.Xml
namespace, however to gain access to internal/friend methods of the DataSet
object model, it makes sense to have it in the System.Data assembly..

Hope this helps
Jay
"tim.aranki" <ti********@gmail.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...
|I would say that, while possible to do this, it is not necessarily best
| practice. For management purposes, you will want to encapsulate an
| entire namespace in a single assembly. This will help with maintenance
| down the line, and will also help avoid silly problems like duplicate
| class names in the same namespace (but different assemblies).
|
| The .NET Framework IS indeed split into multiple assemblies, but I do
| not know of a case where a single namespace is split accross
| assemblies. By that, I mean that while the System.Web and
| System.Web.Mobile namespaces may be split into multiple assemblies, you
| will not find System.Web itself in multiple assemblies.
|
| I hope this helps,
|
| Tim Aranki
|
Nov 17 '05 #6
I should have known better...and Reflector is sitting on my desktop
even!

I still think that it can be a dangerous practice, and I expect that
there were significant driving forces behind those decisions by the
team at MS (The Xml one comes to mind as a necessary evil). The System
and mscorlib coupling makes sense to a point, but I would be interested
in knowing the real driving forces that lead to namespaces needing to
be split... To me namespaces delimit objects in a common domain (XML,
Web, Messaging, etc), so when I need to reference that namespace to use
it's functionality, I would not expect to have to reference multiple
assemblies. Perhaps it was/is assumed that all (or at least the vast
majority of) projects would need both the mscorlib and System
assemblies, and therefore it was not such a bad thing to do? While
that is probably true, it just does not seem as elegant to me.

Or perhaps I am just plain crazy! :)

So, do we agree that is is not "best practice", but possible to do when
design/architecture necessitates?

/tim

Nov 17 '05 #7
Tim,
| So, do we agree that is is not "best practice", but possible to do when
| design/architecture necessitates?

That's my general feeling on it.

However! I've also used multiple assemblies & a single namespace, where I
wanted multiple assemblies to manage the sheer number of types, however
those types made the most sense in a single namespace. Basically each class
was a plug-in, there were a handful of closely related plug-ins in a single
assembly, the various plug-ins were dynamically loaded based on criteria met
in the program. The plug-in (class), along with its assembly were listed in
the app.config based on a "key"...

Hope this helps
Jay

"tim.aranki" <ti********@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
|I should have known better...and Reflector is sitting on my desktop
| even!
|
| I still think that it can be a dangerous practice, and I expect that
| there were significant driving forces behind those decisions by the
| team at MS (The Xml one comes to mind as a necessary evil). The System
| and mscorlib coupling makes sense to a point, but I would be interested
| in knowing the real driving forces that lead to namespaces needing to
| be split... To me namespaces delimit objects in a common domain (XML,
| Web, Messaging, etc), so when I need to reference that namespace to use
| it's functionality, I would not expect to have to reference multiple
| assemblies. Perhaps it was/is assumed that all (or at least the vast
| majority of) projects would need both the mscorlib and System
| assemblies, and therefore it was not such a bad thing to do? While
| that is probably true, it just does not seem as elegant to me.
|
| Or perhaps I am just plain crazy! :)
|
| So, do we agree that is is not "best practice", but possible to do when
| design/architecture necessitates?
|
| /tim
|
Nov 17 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by Richard Brown | last post: by
6 posts views Thread by jeffo | last post: by
10 posts views Thread by anders | last post: by
11 posts views Thread by alex sparsky | last post: by
1 post views Thread by peeping_t | last post: by
reply views Thread by devrayhaan | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.