A namespace implemented over several different assemblies?

[thechaosengine]

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

 

[Guest]

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

 

[tim.aranki]

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

 

[Nicholas Paldino [.NET/C# MVP]]

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.

 

[Guest]

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.

 

[Jay B. Harlow [MVP - Outlook]]

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


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

 

[tim.aranki]

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

 

[Jay B. Harlow [MVP - Outlook]]

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

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