472,972 Members | 2,052 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,972 software developers and data experts.

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 8347
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: thechaosengine | last post by:
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 ...
3
by: thechaosengine | last post by:
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 ...
10
by: Richard Brown | last post by:
I think I might be on track to a misnomer that I keep running into. A lot of the assemblies that I reference are named "System", "System.Drawing", etc. There are dlls, ie, system.dll and...
6
by: jeffo | last post by:
Hello everyone I'm looking at an example in the MSDN library and it says that this code requires a reference to the system namesppace. What does this mean? Thanks in advance.
10
by: anders | last post by:
I have 2 external assemblies A1 and A2 that both define class X in the global namespace. I need to use both assemblies in my VB project but the names X are ambiguous. How can I get around this...
11
by: alex sparsky | last post by:
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...
1
by: peeping_t | last post by:
Im currently writing an application that will have some plugin functionality and therefor Ive created two projects one that will build the exe and one that contains the "framework" for the...
12
by: bgeneto | last post by:
I know that it's a very basic question, but I can't figure out or find an answer to why do we have to specify a namespace, like this #include<string> using namespace std; when using the...
27
by: HKSHK | last post by:
Hello, I have this problem: I wrote some DLLs with VB.Net 2003 which I use with my programs. But I want to avoid that I have to go down to "DLL hell" and to copy all used dlls into each program...
0
by: lllomh | last post by:
Define the method first this.state = { buttonBackgroundColor: 'green', isBlinking: false, // A new status is added to identify whether the button is blinking or not } autoStart=()=>{
2
by: DJRhino | last post by:
Was curious if anyone else was having this same issue or not.... I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 4 Oct 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM) The start time is equivalent to 19:00 (7PM) in Central...
0
tracyyun
by: tracyyun | last post by:
Hello everyone, I have a question and would like some advice on network connectivity. I have one computer connected to my router via WiFi, but I have two other computers that I want to be able to...
4
NeoPa
by: NeoPa | last post by:
Hello everyone. I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report). I know it can be done by selecting :...
3
NeoPa
by: NeoPa | last post by:
Introduction For this article I'll be using a very simple database which has Form (clsForm) & Report (clsReport) classes that simply handle making the calling Form invisible until the Form, or all...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 1 Nov 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM) Please note that the UK and Europe revert to winter time on...
3
by: nia12 | last post by:
Hi there, I am very new to Access so apologies if any of this is obvious/not clear. I am creating a data collection tool for health care employees to complete. It consists of a number of...
0
isladogs
by: isladogs | last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, Mike...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.