 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / August 2005A 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 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 > Hi all, > [quoted text clipped - 17 lines] > > tce 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, 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.  Signature- Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.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 [quoted text clipped - 11 lines] > > Tim Aranki 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. SignatureBrian Delahunty Ireland http://briandela.com/blog > I would say that, while possible to do this, it is not necessarily best > practice. For management purposes, you will want to encapsulate an [quoted text clipped - 11 lines] > > Tim Aranki 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 [quoted text clipped - 11 lines] | | 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 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! [quoted text clipped - 18 lines] | | /tim Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.