Assemblies vs. Namespace

  • Thread starter Thread starter Richard Brown
  • Start date Start date
R

Richard Brown

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
system.drawing.dll", etc. However, in my Imports statements, I also use
Import System and Import System.Drawing, which I assume are 'namespaces'.

So, is it that Microsoft just wanted to confuse us by naming them the same,
or is there some direct relation?

For example, if I have...

Begin Namespace MyNamespace.SubSpace

End Namespace

Can I put that in an assembly called 'core.dll'. So I would reference Core,
but Import MyNamespace.SubSpace?
Although not a big deal, I think I would like to keep the dll names a little
bit different than the actually namespaces, such as "spcore", "spui",
"spetc"...
 
Richard Brown said:
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
system.drawing.dll", etc. However, in my Imports statements, I also
use Import System and Import System.Drawing, which I assume are
'namespaces'.

So, is it that Microsoft just wanted to confuse us by naming them the
same, or is there some direct relation?
Click to expand...

No, they wanted to make it easier. If you are looking for a namespace,
simply set a reference to a assembly with the same name (usually).
For example, if I have...

Begin Namespace MyNamespace.SubSpace

End Namespace

Can I put that in an assembly called 'core.dll'. So I would
reference Core, but Import MyNamespace.SubSpace?
Exactly.

Although not a big deal, I think I would like to keep the dll names a
little bit different than the actually namespaces, such as "spcore",
"spui", "spetc"...
Click to expand...

I think different. ;-)
 
Thank you Armin, this has cleared up a big misunderstanding on my part.
I would normally agree with you regarding keeping base namespaces the same
as assembly names, however, he have very big, powerful and sneaky
competitors who would love to get ahold of our proprietary scheduling
algorithms, so my bosses are just a little panicky. -- thus, I have also
been looking into the dotfuscator from preemptive software.

All of our assemblies will be private assemblies, so there is not an issue
with 3rd parties having to use them.
Now, here is a question...

Can you have a library of private assemblies in your app directories, but
create a global assembly that provides a wrapper around the private
assemblies -- such to expose certain code to 3rd parties who may want to
integrate?
 
Hi Richard,

|| Can you have a library of private assemblies in your app
|| directories, but create a global assembly that provides a
|| wrapper around the private assemblies.

I would imagine that all direct references in a global assembly would have to be to other global assemblies. It kind of breaks
the spirit of being global, otherwise.

That said, there is no reason why you shouldn't hook up to your private assemblies dynamically. The next question is how. (and
it's not for me)

Regards,
Fergus
 
Note sure what you mean by this...
That said, there is no reason why you shouldn't hook up to your
Click to expand...
private assemblies dynamically. The next
question is how. (and it's not for me)
Click to expand...

You mean, somehow do a LoadAssembly call to the private assemblies?
Basically, I don't plan on doing this, but was just wondering, in the event
that we write all this as private assemblies and decide later to expose some
sort of public assembly for other people to tie into our app.

Fergus Cooney said:
Hi Richard,

|| Can you have a library of private assemblies in your app
|| directories, but create a global assembly that provides a
|| wrapper around the private assemblies.

I would imagine that all direct references in a global assembly would
Click to expand...
have to be to other global assemblies. It kind of breaks
the spirit of being global, otherwise.

That said, there is no reason why you shouldn't hook up to your
Click to expand...
private assemblies dynamically. The next question is how. (and
 
Hi Richard,

|| You mean, somehow do a LoadAssembly call
|| to the private assemblies?

If that'll do it, yes. That or whatever. (Not my area, you see :-))

Regards,
Fergus

ps. About those 'very big, powerful and sneaky competitors'. Have you vetted your cleaning staff? Especially that one who seems to
know an awful lot about computers?
 
Yeah, well, we screened all the cleaning staff.... none of them speak
english ;-)
Nah, we're just a small transportation company that wrote this software and
sell it at ridiculously cheap prices comparatively, and just so happened to
luck into a really nifty algorithm (the original developer was on something
really good I think) -- thats all. We our software goes for 20k and
competitors goes for 80k, you kinda get the idea, no use in losing the small
market we have.

Fergus Cooney said:
Hi Richard,

|| You mean, somehow do a LoadAssembly call
|| to the private assemblies?

If that'll do it, yes. That or whatever. (Not my area, you see :-))

Regards,
Fergus

ps. About those 'very big, powerful and sneaky competitors'. Have you
Click to expand...
vetted your cleaning staff? Especially that one who seems to
 
Hi Richard,

Just joking, of course. :-) More power to you. I hope it goes well for the company and you get a nice fat bonus!!

Regards,
Fergus
 
Haha... yeah, of course.... I think I get a weekend off if it goes well ;-)

Fergus Cooney said:
Hi Richard,

Just joking, of course. :-) More power to you. I hope it goes well for
Click to expand...
the company and you get a nice fat bonus!!
 
Richard,
I tend to follow what the Framework does.

I name the assembly for the namespace it contains, complete with the periods
in the dll names!
Can I put that in an assembly called 'core.dll'. So I would reference Core,
but Import MyNamespace.SubSpace?
Although not a big deal, I think I would like to keep the dll names a little
bit different than the actually namespaces, such as "spcore", "spui",
"spetc"...
Click to expand...
As Armin stated, your naming convention is acceptable also.

Interesting enough I do not see in the .NET Design Guidelines for Class
Library Developers any guidelines for naming the Assembly.

http://msdn.microsoft.com/library/d...en-us/cpgenref/html/cpconnamingguidelines.asp

In fact the guides specifically state "Finally, note that a namespace name
does not have to parallel an assembly name. For example, if you name an
assembly MyCompany.MyTechology.dll, it does not have to contain a
MyCompany.MyTechnology namespace." (which supports your convention).
http://msdn.microsoft.com/library/d...enref/html/cpconnamespacenamingguidelines.asp

Hope this helps
Jay
 
Back
Top