You can override the names of the files to alternate versions... if youd
like
Most people don't.
MyOrg.Applications.NorthwindManager
MyOrg.Applications.NorthwindManager.Presentation.W informs.1
MyOrg.Applications.NorthwindManager.BusinessLogic
MyOrg.Applications.NorthwindManager.Data
MyOrg.Applications.NorthwindManager.Data.DataSets
that's am example of what I do for an application.
I put those in file/folders like this:
c:\development\MyOrg\
c:\development\MyOrg\Applications\
c:\development\MyOrg\Applications\NorthwindManager
cc:\development\MyOrg\Applications\NorthwindManage r.Presentation.Winform.1
c:\development\MyOrg\Applications\NorthwindManager \BusinessLogic\
c:\development\MyOrg\Applications\NorthwindManager \Data\
(etc)
so I'd have (one example only this time)
c:\development\MyOrg\Applications\NorthwindManager \BusinessLogic\MyOrg.Appli
cations.NorthwindManager.BusinessLogic.csproj
something like that.
then I'd get a file like this:
MyOrg.Applications.NorthwindManager.BusinessLogic. dll
perhaps I override the name.... and do this:
MyOrg.Applications.NWM.BusinessLogic.dll
the NAMESPACE would remain:
MyOrg.Applications.NorthwindManager.BusinessLogic
but the filename would be
MyOrg.Applications.NWM.BusinessLogic.dll
the only time i do this is when I might encounter the overall windows issue
of filepath/names length. I think the max is .. 255 characters or something
like that??
my framework stuff would be:
MyOrg.Email
MyOrg.Data
etc
"Bob Weiner" <bo*@engr.uconn.edu> wrote in message
news:uH**************@TK2MSFTNGP04.phx.gbl...
That's good to know.
Since you mentioned it, I don't know why I thought there should be a
relationship between the dll files and the namespaces. I think that might
have been an old Java concept creeping in.
Thanks!
bob
"Jeffrey Hornby" <Je***********@discussions.microsoft.com> wrote in
message news:84**********************************@microsof t.com... The best way to dea with namespaces in this case is not to think of them
as
part of scoping. Think of them as just a way to organize your libraries
by
grouping similar things together.
You seem to be on the right track in your last paragraph except that
there's
really no reason to store individual .dlls in their own directory
structure.
Just make sure that the name of the .dll synchs up with the name of the
namespace. (Your source code, of course, is a different matter)
The other thing I would suggest is to plan at least your namespace
hierarchy if not the entire libraries in advance. This will help to
ensure
that things get put in the proper namespace as you create them.
Good luck.
--
Jeffrey Hornby
Hornby Consulting, Inc.
"Bob Weiner" wrote:
Hi,
I am an IT person who uses .Net to support our infrastructure. Since I
have
been doing this for a while it would be a misnomer for classify myself
as a
newbie; perpetual amatuer seems more appropriate.
Notwithstanding, I am tired of cutting and pasting code and moving
classes
from one project to the next and would like to know the "proper" way to
store code for reuse. I have used .dll's with some success but am
still not
organized.
Ideally, I'd like to have a hierarchial namespace with "myOrg" at the
root.
Underneath I should find myOrg.AD, myOrg.AD.Queries, myOrg.Exchange...
I assume professional developers do it this way.
I have seen a lot on Namespaces but I haven't been able to conceptually
move
from the simple concept of scope to that of organizing code for reuse.
Does this happen by creating a 1 dll / namespace, copying that dll into
a matching directory structure, then adding a reference to each dll in
all subsequent projects?
advice or referrals would be greatly appreciated.
Thanks, bob
