Assemblies vs. Namespace

[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"...

[Armin Zingler]

"Richard Brown" <rb****@easylift.org> schrieb

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?
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"...

I think different. ;-)
--
Armin

[Richard Brown]

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?

"Armin Zingler" <az*******@freenet.de> wrote in message
news:eu**************@TK2MSFTNGP09.phx.gbl...

"Richard Brown" <rb****@easylift.org> schrieb

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?

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

I think different. ;-)
--
Armin

[Fergus Cooney]

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

[Richard Brown]

Note sure what you mean by this...

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)
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" <fi******@tesco.net> wrote in message
news:Oa**************@TK2MSFTNGP10.phx.gbl... 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

[Fergus Cooney]

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?

[Richard Brown]

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" <fi******@tesco.net> wrote in message
news:Oj**************@tk2msftngp13.phx.gbl...

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?

[Fergus Cooney]

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

[Richard Brown]

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

"Fergus Cooney" <fi******@tesco.net> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

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

[Fergus Cooney]

LOL, Aw boo.

Fergus

[Jay B. Harlow [MVP - Outlook]]

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"... 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/de...guidelines.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/de...guidelines.asp

Hope this helps
Jay
"Richard Brown" <rb****@easylift.org> wrote in message
news:eB**************@TK2MSFTNGP11.phx.gbl... 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"...