static member function, with no public/private/etc.

[Zytan]

A member that is public is visible to any code that can see the class.

So if
your class is public, its public members will be visible outside of
the
assembly. If the class is internal (the default), its public members
are
visible only to other classes within the same assembly.
[snip]

Ok, I get that. That's the technical definition that I already know.

What I am asking is: What is the assembly?

I think it's the current compilation (.exe or .dll). So, what is the
point of this distinction? What can possibly be outside the assembly
for us to care if something outside of it can see our stuff? What is
the difference between public and internal assuming 'assembly' isn't
defined? Your answer assumes the asker knows what 'assembly' means.
And this is precisely the term whose meaning I am trying to determine.

I hope my question is more clear now.

thanks!

Zytan

 

[xperthands]

What I am asking is: What is the assembly?

The output of a compilation process in .NET -- an
application (solution in VS2005 terminology) is a
set of assemblies (one exe and many dlls) that are
cobbled together to work together to provide the
services you need.

I think it's the current compilation (.exe or .dll). So, what is the
point of this distinction? What can possibly be outside the assembly
for us to care if something outside of it can see our stuff?

If you are creating a library (dll), presumably you are doing
it because you want to reuse those classes in several
different applications. Unless your classes are public, there
is no way to use them. If your classes are public, there
would still be no way to use them unless they had public
members.

What is
the difference between public and internal assuming 'assembly' isn't
defined? Your answer assumes the asker knows what 'assembly' means.
And this is precisely the term whose meaning I am trying to determine.

I see now what you were asking. Assemblies are so key
to what .NET is that it didn't occur to me that you were
asking that question in a round-about way.

It is true that it is rare for anything in an executable
assembly (exe) to need to be public, still most people do
make their classes and several of their members public
(mostly just out of habit).

As you get more experience with .NET and start using it
for real work, you'll probably find that, like most people,
you spend more time developing dll assemblies
(.NET components, if you will) since they are where
domain-specific class families (collaborating classes,
not necessarily inheriting classes) reside. As you put
those dlls together you will be able to develop lots
of applications, but you will need to access the pieces
of the different assemblies you have developed to make
them work, so the distinction between public and
internal is very important.

 

[Jon Skeet [C# MVP]]

I know internal means visible only within the assembly. But, isn't
that the case with public? I mean, what else other than the assembly,
could see it anyway? Does it refer to linking to DLLs, where public
means the caller can see them, but internal means the DLL keeps it
hidden?

Yes, that's exactly the case.

 

[Zytan]

The output of a compilation process in .NET -- an

application (solution in VS2005 terminology) is a
set of assemblies (one exe and many dlls) that are
cobbled together to work together to provide the
services you need.

So each single .exe and .dll is *one* assembly?

If you are creating a library (dll), presumably you are doing
it because you want to reuse those classes in several
different applications. Unless your classes are public, there
is no way to use them. If your classes are public, there
would still be no way to use them unless they had public
members.

So, if I have a .dll with classes that many other programs will use:

If they have everything as internal, other programs cannot see them,
since they are internal to the .dll assembly itself, and not visible
outside of the .dll assembly? And if they are public, then the
program can them see inside of the .dll assembly?

I see now what you were asking. Assemblies are so key
to what .NET is that it didn't occur to me that you were
asking that question in a round-about way.

Yes, I figured this was the case. And this is why I want to have a
proper understanding of them.

It is true that it is rare for anything in an executable
assembly (exe) to need to be public, still most people do
make their classes and several of their members public
(mostly just out of habit).

Yes, as I do. So, these people should all be using internal instead
of public, since they are never going to need for them to visible
outside of their assembly (to other programs that may use the .dll
that they are creating).

As you get more experience with .NET and start using it
for real work, you'll probably find that, like most people,
you spend more time developing dll assemblies
(.NET components, if you will) since they are where
domain-specific class families (collaborating classes,
not necessarily inheriting classes) reside. As you put
those dlls together you will be able to develop lots
of applications, but you will need to access the pieces
of the different assemblies you have developed to make
them work, so the distinction between public and
internal is very important.

Right, like little sets of tools to be used by may current / future
programs, and they need to be 'seen' by these programs for them to be
used.

Thanks for the indepth explanation xperthands.

Zytan

 

[Zytan]

I know internal means visible only within the assembly. But, isn't

Yes, that's exactly the case.

Thanks, Jon.

Zytan

 

[Jon Skeet [C# MVP]]

So each single .exe and .dll is *one* assembly?
Yes.


So, if I have a .dll with classes that many other programs will use:

If they have everything as internal, other programs cannot see them,
since they are internal to the .dll assembly itself, and not visible
outside of the .dll assembly? And if they are public, then the
program can them see inside of the .dll assembly?

Spot on.

Yes, as I do. So, these people should all be using internal instead
of public, since they are never going to need for them to visible
outside of their assembly (to other programs that may use the .dll
that they are creating).

Indeed. It's usually laziness which makes people use public when they
mean internal - and that applies very much to myself, by the way. On
the other hand, it rarely does any harm. (Making things public which
should be *private* is more of an issue, of course.)

 

[Zytan]

So each single .exe and .dll is *one* assembly?

Yes.



Spot on.


Indeed. It's usually laziness which makes people use public when they
mean internal - and that applies very much to myself, by the way. On
the other hand, it rarely does any harm. (Making things public which
should be *private* is more of an issue, of course.)

Ok! Thank you, xperthands and Jon!!!

Zytan