What is an assembly?

[TC]

I'm trying to figure out what the "Friend" keyword does. I know it
specifies that "elements are accessible from within the same assembly",
but that doesn't help because I don't know what an assembly is. I know
what a project is, and I know what a solution is, but "assembly" isn't
defined in the help file anywhere. Can anyone provide a simple
definition?

[_AnonCoward]

"TC" <go*********@yahoo.comwrote in message
news:11*********************@p79g2000cwp.googlegro ups.com...
:
: I'm trying to figure out what the "Friend" keyword does. I know it
: specifies that "elements are accessible from within the same assembly",
: but that doesn't help because I don't know what an assembly is. I know
: what a project is, and I know what a solution is, but "assembly" isn't
: defined in the help file anywhere. Can anyone provide a simple
: definition?
This is extremely simplistic (and incomplete), but hopefully it will give
you a starting off point.
Think of an assembly as a block of code that contains one or more classes or
structures. Such assemblies can be part of a library (DLL) or part of a
stand alone executable (EXE). Typically, the classes and structures will be
logically related to one another, but they don't absoulely have to be.
So let's say you decide to build a simple little "hello world" executable
that contains a single class:
File: HelloWorld.vb
================================================== ==========
Public Class HelloWorld
Public Shared Sub Main(Args() As String)
System.Console.Writeline("Hello World!")
End Sub
End Class
================================================== ==========
You can compile this file into and executable by running the following
command from a command prompt (be sure the VBC complier is in the path:)
C:\>vbc helloworld.vb
This will generate the file "helloworld.exe" which you can then run from the
command line. This executable is an assembly. Small and trival granted, but
an assembly nonetheless.
Let's change this somewhat by creating two new files:
File 1: HelloWorld1.vb
================================================== ==========
Public Class HelloWorld1
Public Shared Sub Main(Args() As String)
Dim Hw2 As New HelloWorld2
Hw2.Say("Hello World Too!")
End Sub
End Class
================================================== ==========
File 2: HelloWorld2.vb
================================================== ==========
Public Class HelloWorld2
Public Sub Say(Something As String)
Dim Hw3 As New HelloWorld3
Hw3.Repeat(Something)
End Sub
End Class

Friend Class HelloWorld3
Public Sub Repeat(Something As String)
System.Console.WriteLine(Something)
End Sub
End Class
================================================== ==========
If you compile these two files, you will get two assemblies. Piece of cake.
Now here is the tricky part...
Sub Main() in File1 can access the sub Say() in class HelloWorld2 (File2)
because that class is Public.
However, Sub Main() in File1 cannot access sub Repeat() in class HelloWorld3
(File2) because that class is a Friend Class. Classes HelloWorld1 and
HelloWorld3 are two separate assemblies, so class HelloWorld3 cannot be
called from class HelloWorld1.
On the otherhand, classes HelloWorld2 and HelloWorld3 are in the same
assembly, so they are accessible to one another. Therefore, sub Say() in
class HelloWorld2 can access sub Repeat() in class HelloWorld3.
I'm sure this is as clear as mud, but as I said this will hopefully get you
started.
Ralf
--
--
----------------------------------------------------------
* ^~^ ^~^ *
* _ {~ ~} {~ ~} _ *
* /_``>*< >*<''_\ *
* (\--_)++) (++(_--/) *
----------------------------------------------------------
There are no advanced students in Aikido - there are only
competent beginners. There are no advanced techniques -
only the correct application of basic principles.

[TC]

Thank you for the explanation. In your example, the two classes defined
in the same .vb file belong to the same assembly, but the class defined
in other .vb file belongs to a different assembly. Is that the
definition of an assembly, then? Each assembly contains all the code
defined within a single .vb file?
_AnonCoward wrote:

"TC" <go*********@yahoo.comwrote in message
news:11*********************@p79g2000cwp.googlegro ups.com...
:
: I'm trying to figure out what the "Friend" keyword does. I know it
: specifies that "elements are accessible from within the same assembly",
: but that doesn't help because I don't know what an assembly is. I know
: what a project is, and I know what a solution is, but "assembly" isn't
: defined in the help file anywhere. Can anyone provide a simple
: definition?
This is extremely simplistic (and incomplete), but hopefully it will give
you a starting off point.
Think of an assembly as a block of code that contains one or more classes or
structures. Such assemblies can be part of a library (DLL) or part of a
stand alone executable (EXE). Typically, the classes and structures will be
logically related to one another, but they don't absoulely have to be.
So let's say you decide to build a simple little "hello world" executable
that contains a single class:
File: HelloWorld.vb
================================================== ==========
Public Class HelloWorld
Public Shared Sub Main(Args() As String)
System.Console.Writeline("Hello World!")
End Sub
End Class
================================================== ==========
You can compile this file into and executable by running the following
command from a command prompt (be sure the VBC complier is in the path:)
C:\>vbc helloworld.vb
This will generate the file "helloworld.exe" which you can then run from the
command line. This executable is an assembly. Small and trival granted, but
an assembly nonetheless.
Let's change this somewhat by creating two new files:
File 1: HelloWorld1.vb
================================================== ==========
Public Class HelloWorld1
Public Shared Sub Main(Args() As String)
Dim Hw2 As New HelloWorld2
Hw2.Say("Hello World Too!")
End Sub
End Class
================================================== ==========
File 2: HelloWorld2.vb
================================================== ==========
Public Class HelloWorld2
Public Sub Say(Something As String)
Dim Hw3 As New HelloWorld3
Hw3.Repeat(Something)
End Sub
End Class

Friend Class HelloWorld3
Public Sub Repeat(Something As String)
System.Console.WriteLine(Something)
End Sub
End Class
================================================== ==========
If you compile these two files, you will get two assemblies. Piece of cake.
Now here is the tricky part...
Sub Main() in File1 can access the sub Say() in class HelloWorld2 (File2)
because that class is Public.
However, Sub Main() in File1 cannot access sub Repeat() in class HelloWorld3
(File2) because that class is a Friend Class. Classes HelloWorld1 and
HelloWorld3 are two separate assemblies, so class HelloWorld3 cannot be
called from class HelloWorld1.
On the otherhand, classes HelloWorld2 and HelloWorld3 are in the same
assembly, so they are accessible to one another. Therefore, sub Say() in
class HelloWorld2 can access sub Repeat() in class HelloWorld3.
I'm sure this is as clear as mud, but as I said this will hopefully get you
started.
Ralf
--
--
----------------------------------------------------------
* ^~^ ^~^ *
* _ {~ ~} {~ ~} _ *
* /_``>*< >*<''_\ *
* (\--_)++) (++(_--/) *
----------------------------------------------------------
There are no advanced students in Aikido - there are only
competent beginners. There are no advanced techniques -
only the correct application of basic principles.

[Cor Ligthert [MVP]]

TC,

An assembly is a build program whatever it is.

Cor

"TC" <go*********@yahoo.comschreef in bericht
news:11**********************@75g2000cwc.googlegro ups.com...

Thank you for the explanation. In your example, the two classes defined
in the same .vb file belong to the same assembly, but the class defined
in other .vb file belongs to a different assembly. Is that the
definition of an assembly, then? Each assembly contains all the code
defined within a single .vb file?
_AnonCoward wrote:

>"TC" <go*********@yahoo.comwrote in message
news:11*********************@p79g2000cwp.googlegr oups.com...
:
: I'm trying to figure out what the "Friend" keyword does. I know it
: specifies that "elements are accessible from within the same assembly",
: but that doesn't help because I don't know what an assembly is. I know
: what a project is, and I know what a solution is, but "assembly" isn't
: defined in the help file anywhere. Can anyone provide a simple
: definition?
This is extremely simplistic (and incomplete), but hopefully it will give
you a starting off point.
Think of an assembly as a block of code that contains one or more classes
or
structures. Such assemblies can be part of a library (DLL) or part of a
stand alone executable (EXE). Typically, the classes and structures will
be
logically related to one another, but they don't absoulely have to be.
So let's say you decide to build a simple little "hello world" executable
that contains a single class:
File: HelloWorld.vb
================================================= ===========
Public Class HelloWorld
Public Shared Sub Main(Args() As String)
System.Console.Writeline("Hello World!")
End Sub
End Class
================================================= ===========
You can compile this file into and executable by running the following
command from a command prompt (be sure the VBC complier is in the path:)
C:\>vbc helloworld.vb
This will generate the file "helloworld.exe" which you can then run from
the
command line. This executable is an assembly. Small and trival granted,
but
an assembly nonetheless.
Let's change this somewhat by creating two new files:
File 1: HelloWorld1.vb
================================================= ===========
Public Class HelloWorld1
Public Shared Sub Main(Args() As String)
Dim Hw2 As New HelloWorld2
Hw2.Say("Hello World Too!")
End Sub
End Class
================================================= ===========
File 2: HelloWorld2.vb
================================================= ===========
Public Class HelloWorld2
Public Sub Say(Something As String)
Dim Hw3 As New HelloWorld3
Hw3.Repeat(Something)
End Sub
End Class

Friend Class HelloWorld3
Public Sub Repeat(Something As String)
System.Console.WriteLine(Something)
End Sub
End Class
================================================= ===========
If you compile these two files, you will get two assemblies. Piece of
cake.
Now here is the tricky part...
Sub Main() in File1 can access the sub Say() in class HelloWorld2 (File2)
because that class is Public.
However, Sub Main() in File1 cannot access sub Repeat() in class
HelloWorld3
(File2) because that class is a Friend Class. Classes HelloWorld1 and
HelloWorld3 are two separate assemblies, so class HelloWorld3 cannot be
called from class HelloWorld1.
On the otherhand, classes HelloWorld2 and HelloWorld3 are in the same
assembly, so they are accessible to one another. Therefore, sub Say() in
class HelloWorld2 can access sub Repeat() in class HelloWorld3.
I'm sure this is as clear as mud, but as I said this will hopefully get
you
started.
Ralf
--
--
----------------------------------------------------------
* ^~^ ^~^ *
* _ {~ ~} {~ ~} _ *
* /_``>*< >*<''_\ *
* (\--_)++) (++(_--/) *
----------------------------------------------------------
There are no advanced students in Aikido - there are only
competent beginners. There are no advanced techniques -
only the correct application of basic principles.

[Peter Macej]

Thank you for the explanation. In your example, the two classes defined

in the same .vb file belong to the same assembly, but the class defined
in other .vb file belongs to a different assembly. Is that the
definition of an assembly, then? Each assembly contains all the code
defined within a single .vb file?

No. Usually, all .vb files in the same project (but not solution) belong
to the same assembly. Perhaps there may be exceptions but assembly is
DLL or EXE. So your whole project is an assembly. You can even find (in
VS 2003/2003) one AssemblyInfo.vb file per project which specifies
assembly properties. So if you declare member as Friend, it is
accessible from anywhere in you project but not from outside it.

--
Peter Macej
Helixoft - http://www.vbdocman.com
VBdocman - Automatic generator of technical documentation for VB, VB
..NET and ASP .NET code

[_AnonCoward]

"TC" <go*********@yahoo.comwrote in message
news:11**********************@75g2000cwc.googlegro ups.com...
:
: _AnonCoward wrote:
: >
: "TC" <go*********@yahoo.comwrote in message
: news:11*********************@p79g2000cwp.googlegro ups.com...
: :
: : I'm trying to figure out what the "Friend" keyword does. I know it
: : specifies that "elements are accessible from within the same
: : assembly", but that doesn't help because I don't know what an assembly
: : is. I know what a project is, and I know what a solution is, but
: : "assembly" isn't defined in the help file anywhere. Can anyone provide
: : a simple definition?
: >
: >
: This is extremely simplistic (and incomplete), but hopefully it will
: give you a starting off point.
: >
: >
: Think of an assembly as a block of code that contains one or more
: classes or structures. Such assemblies can be part of a library (DLL) or
: part of a stand alone executable (EXE). Typically, the classes and
: structures will be logically related to one another, but they don't
: absoulely have to be.
: >
: >
: So let's say you decide to build a simple little "hello world"
: executable that contains a single class:
: >
: >
: File: HelloWorld.vb
: ================================================== ==========
: Public Class HelloWorld
: Public Shared Sub Main(Args() As String)
: System.Console.Writeline("Hello World!")
: End Sub
: End Class
: ================================================== ==========
: >
: >
: You can compile this file into and executable by running the following
: command from a command prompt (be sure the VBC complier is in the path:)
: >
: >
: C:\>vbc helloworld.vb
: >
: >
: This will generate the file "helloworld.exe" which you can then run from
: the command line. This executable is an assembly. Small and trival
: granted, but an assembly nonetheless.
: >
: >
: Let's change this somewhat by creating two new files:
: >
: >
: File 1: HelloWorld1.vb
: ================================================== ==========
: Public Class HelloWorld1
: Public Shared Sub Main(Args() As String)
: Dim Hw2 As New HelloWorld2
: Hw2.Say("Hello World Too!")
: End Sub
: End Class
: ================================================== ==========
: >
: >
: File 2: HelloWorld2.vb
: ================================================== ==========
: Public Class HelloWorld2
: Public Sub Say(Something As String)
: Dim Hw3 As New HelloWorld3
: Hw3.Repeat(Something)
: End Sub
: End Class
: >
: Friend Class HelloWorld3
: Public Sub Repeat(Something As String)
: System.Console.WriteLine(Something)
: End Sub
: End Class
: ================================================== ==========
: >
: >
: If you compile these two files, you will get two assemblies. Piece of
: cake.
: >
: >
: Now here is the tricky part...
: >
: >
: Sub Main() in File1 can access the sub Say() in class HelloWorld2
: (File2) because that class is Public.
: >
: >
: However, Sub Main() in File1 cannot access sub Repeat() in class
: HelloWorld3 (File2) because that class is a Friend Class. Classes
: HelloWorld1 and HelloWorld3 are two separate assemblies, so class
: HelloWorld3 cannot be called from class HelloWorld1.
: >
: >
: On the otherhand, classes HelloWorld2 and HelloWorld3 are in the same
: assembly, so they are accessible to one another. Therefore, sub Say() in
: class HelloWorld2 can access sub Repeat() in class HelloWorld3.
: >
: >
: I'm sure this is as clear as mud, but as I said this will hopefully get
: you started.
:
: Thank you for the explanation. In your example, the two classes defined
: in the same .vb file belong to the same assembly, but the class defined
: in other .vb file belongs to a different assembly. Is that the
: definition of an assembly, then? Each assembly contains all the code
: defined within a single .vb file?
Not exactly. It is possible to compile two or vb files into the same
assembly. For example, I could type the following at the command line:
C:\>vbc /out:helloWorld.exe helloWorld1.vb helloWorld2.vb
This would produce a single assembly "helloWorld.exe" from the two .vb
files. In that case, all three classes (HelloWorld1, HelloWorld2 and
HelloWorld3) would be in the same assembly and so HelloWorld1 could call
HelloWorld3.Repeat().
The DLL or EXE that a given compile operation outputs (whether from within
the IDE or from the command line) is typically what makes up an assembly.
That compile may use a single .vb file or combine several.
Ralf
--
--
----------------------------------------------------------
* ^~^ ^~^ *
* _ {~ ~} {~ ~} _ *
* /_``>*< >*<''_\ *
* (\--_)++) (++(_--/) *
----------------------------------------------------------
There are no advanced students in Aikido - there are only
competent beginners. There are no advanced techniques -
only the correct application of basic principles.

[Michel Posseth [MCP]]

Simplistic explanation

I'm trying to figure out what the "Friend" keyword does

this keyword makes sure that elements are only accessible on friendly
grounds ( the same assembly )

What is an assembly ??

An assembly is a container for compiled code ( exe , dll )

The friend Keyword behaves inside the project the same as Public however
other projects who reference your assembly can`t see the fields

hope to have shined some light on the subject :-)

regards

Michel Posseth
"TC" wrote:

I'm trying to figure out what the "Friend" keyword does. I know it
specifies that "elements are accessible from within the same assembly",
but that doesn't help because I don't know what an assembly is. I know
what a project is, and I know what a solution is, but "assembly" isn't
defined in the help file anywhere. Can anyone provide a simple
definition?

[TC]

Thanks for the clarification. It sounds like an assembly most closely
corresponds to a project, but that there is a contextual difference
between a project and an assembly.

Now here's the really substantive part of my question: To the extent
that there is a differrence between "project" and "assembly", isn't it
more correct to say that Friend applies to a project, not an assembly?

In other words, I'm proposing that the definition of Friend is not only
confusing, but technically wrong. It seems to me that the distinction
between Friend and Private is relevant only during development; thus,
it is a concept with meaning in the context of projects, not
assemblies. Wouldn't it be more appropriate to define Friend as a way
to specify that "elements are accessible from within the same PROJECT",
not "within the same ASSEMBLY"?
_AnonCoward wrote:

>
Not exactly. It is possible to compile two or vb files into the same
assembly. For example, I could type the following at the command line:
C:\>vbc /out:helloWorld.exe helloWorld1.vb helloWorld2.vb
This would produce a single assembly "helloWorld.exe" from the two .vb
files. In that case, all three classes (HelloWorld1, HelloWorld2 and
HelloWorld3) would be in the same assembly and so HelloWorld1 could call
HelloWorld3.Repeat().
The DLL or EXE that a given compile operation outputs (whether from within
the IDE or from the command line) is typically what makes up an assembly.
That compile may use a single .vb file or combine several.
Ralf

[Mythran]

"TC" <go*********@yahoo.comwrote in message
news:11*********************@i42g2000cwa.googlegro ups.com...

Thanks for the clarification. It sounds like an assembly most closely
corresponds to a project, but that there is a contextual difference
between a project and an assembly.

Now here's the really substantive part of my question: To the extent
that there is a differrence between "project" and "assembly", isn't it
more correct to say that Friend applies to a project, not an assembly?

In other words, I'm proposing that the definition of Friend is not only
confusing, but technically wrong. It seems to me that the distinction
between Friend and Private is relevant only during development; thus,
it is a concept with meaning in the context of projects, not
assemblies. Wouldn't it be more appropriate to define Friend as a way
to specify that "elements are accessible from within the same PROJECT",
not "within the same ASSEMBLY"?

Quoted from
"ms-help://MS.MSDNQTR.2003FEB.1033/cpguide/html/cpconassemblies.htm":

"Assemblies are the building blocks of .NET Framework applications; they
form the fundamental unit of deployment, version control, reuse, activation
scoping, and security permissions. An assembly is a collection of types and
resources that are built to work together and form a logical unit of
functionality. An assembly provides the common language runtime with the
information it needs to be aware of type implementations. To the runtime, a
type does not exist outside the context of an assembly."

-------------------------------------------

Quoted from
"ms-help://MS.MSDNQTR.2003FEB.1033/cpguide/html/cpconassembliesoverview.htm":

"Assemblies can be static or dynamic. Static assemblies can include .NET
Framework types (interfaces and classes), as well as resources for the
assembly (bitmaps, JPEG files, resource files, and so on). Static assemblies
are stored on disk in portable executable (PE) files. You can also use the
..NET Framework to create dynamic assemblies, which are run directly from
memory and are not saved to disk before execution. You can save dynamic
assemblies to disk after they have executed.
There are several ways to create assemblies. You can use development tools,
such as Visual Studio .NET, that you have used in the past to create .dll or
..exe files. You can use tools provided in the .NET Framework SDK to create
assemblies with modules created in other development environments. You can
also use common language runtime APIs, such as Reflection.Emit, to create
dynamic assemblies."

So, to really get more of a hang on what an assembly is...check out the msdn
documentation. Open the MSDN Library on your local machine (granted you
must have it installed) and open the "Index" for the help
(View->Navigation->Index). In the Filtered By drop down...select "(no
filter)" if it's not already. In the "Look for" drop-down, type in the word
"assemblies". In the treeview below it (I believe it's a treeview without
all the + and .. symbols), click on "about assemblies" for more information
:)

Hope this helps!
Mythran

[Mythran]

"TC" <go*********@yahoo.comwrote in message
news:11*********************@i42g2000cwa.googlegro ups.com...

Thanks for the clarification. It sounds like an assembly most closely
corresponds to a project, but that there is a contextual difference
between a project and an assembly.

Now here's the really substantive part of my question: To the extent
that there is a differrence between "project" and "assembly", isn't it
more correct to say that Friend applies to a project, not an assembly?

In other words, I'm proposing that the definition of Friend is not only
confusing, but technically wrong. It seems to me that the distinction
between Friend and Private is relevant only during development; thus,
it is a concept with meaning in the context of projects, not
assemblies. Wouldn't it be more appropriate to define Friend as a way
to specify that "elements are accessible from within the same PROJECT",
not "within the same ASSEMBLY"?

Ok Friend is relative to an assembly while Private is relative to the
containing class or assembly (whichever is lesser in terms of visibility):

Friend Enum MyEnum
...
End Enum

Friend Class MyClass
Friend Sub MySub()
End Sub
Private Sub MySub2()
End Sub
End Class

In the above sample, the enumeration and class is only visible to the
assembly. The instanced methods MySub and MySub2 are different though.
MySub is visible to the rest of the assembly through an instance of MyClass.
MySub2 may ONLY be accessed by other methods or members of MyClass and is
NOT visible outside of MyClass (even by other classes inside the same
assembly).

Hope I didn't confuse ya more on this ;)

Mythran

[_AnonCoward]

"TC" <go*********@yahoo.comwrote in message
news:11*********************@i42g2000cwa.googlegro ups.com...
:
: Thanks for the clarification. It sounds like an assembly most closely
: corresponds to a project, but that there is a contextual difference
: between a project and an assembly.
:
: Now here's the really substantive part of my question: To the extent
: that there is a differrence between "project" and "assembly", isn't it
: more correct to say that Friend applies to a project, not an assembly?
:
: In other words, I'm proposing that the definition of Friend is not only
: confusing, but technically wrong. It seems to me that the distinction
: between Friend and Private is relevant only during development; thus,
: it is a concept with meaning in the context of projects, not
: assemblies. Wouldn't it be more appropriate to define Friend as a way
: to specify that "elements are accessible from within the same PROJECT",
: not "within the same ASSEMBLY"?
No, I don't think so. As a basic rule of thumb, a VS project and a .Net
assembly are the same thing, conceptually.
"Assemblies are the unit of class deployment in the common language
runtime. Developers writing .NET Framework classes using Visual
Studio .NET version 7.0 will produce a new assembly with each
Visual Studio project that they compile. Although it is possible to
have an assembly span multiple portable executable (PE) files
(several module DLLs), Visual Studio .NET will, by default, compile
all assembly code into a single DLL (1 Visual Studio .NET project
= 1 .NET Framework assembly = 1 physical DLL)."

http://samples.gotdotnet.com/quickst...eployment.aspx
However, and I think this is what you are overlooking, VS projects aren't
the only way to generate assemblies. I will use notepad and the command line
compiler as often as not for small efforts. What the two approaches have in
common is that they both end up creating assemblies.
The .net framework is what you are targeting and it uses "assemblies".
Visual Studio on the other hand is a tool you can use to create those
assemblies. However, you might have instead chosen to use a tool that uses
the term "Container" instead of "Project" when developing assemblies. So
would it then be more correct to say that "Friend" applies to a "container"
and not a "project"? Of course not; the question is meaningless.
At the end of the day, an "assembly" is really the only thing the framework
knows about. It doesn't know or care about which tools you used to create it
or the terminology those tools used to describe how the assembly was being
generated. It is fine to refer to "Projects" in a VS context, but the term
risks loosing its meaning in any other. Stick with "assemblies" if you are
speaking about the .net framework.
As for the meaning of "Friend", it is a well accepted term in OOP that
conveys a specific concept. Essentially, declaring something as "Friend"
grants privileged access to that object or functionality to other members
within the same assembly while denying that access to consumers of the
assembly.
For example, say you create an assembly that accesses a database and you
decide to create a separate class within the assembly to handle that
functionality. It may not be a good idea to grant just any consumer of the
assembly access to that class as you may want to carefully control how users
get to and manipulate the database. By declaring that class "Friend", you
allow the other classes in the assembly to access it (since those classes
presumably will behave themselves when manipulating the data) yet you
prevent outside, potentially malicious (or at least careless) users from
getting to the database via the class.
<snip>
Ralf
--
--
----------------------------------------------------------
* ^~^ ^~^ *
* _ {~ ~} {~ ~} _ *
* /_``>*< >*<''_\ *
* (\--_)++) (++(_--/) *
----------------------------------------------------------
There are no advanced students in Aikido - there are only
competent beginners. There are no advanced techniques -
only the correct application of basic principles.

[Larry Lard]

TC wrote:

Thanks for the clarification. It sounds like an assembly most closely
corresponds to a project, but that there is a contextual difference
between a project and an assembly.

Now here's the really substantive part of my question: To the extent
that there is a differrence between "project" and "assembly", isn't it
more correct to say that Friend applies to a project, not an assembly?

In other words, I'm proposing that the definition of Friend is not only
confusing, but technically wrong. It seems to me that the distinction
between Friend and Private is relevant only during development; thus,
it is a concept with meaning in the context of projects, not
assemblies. Wouldn't it be more appropriate to define Friend as a way
to specify that "elements are accessible from within the same PROJECT",
not "within the same ASSEMBLY"?

No. It so happens that what VS calls 'Projects' usually end up producing
assemblies on a one-to-one basis; but it must be remembered that VS is
just one of many ways of producing .NET executable code. We could use
SharpDevelop; we could use Notepad; we could write our own IDE that
simultaneously edited every .vb file we've ever written. All these
methods will produce *assemblies*, though only one of them necessarily
knows what a *project* is. And for all of them, Friend will mean the
same thing - accessible within the same assembly - because they all use
vbc.exe to compile, and vbc.exe cares only for assemblies.

--
Larry Lard
la*******@googlemail.com
The address is real, but unread - please reply to the group
For VB and C# questions - tell us which version

[TC]

You've explained it very well. I see things clearly now. Thank you.
_AnonCoward wrote:

"TC" <go*********@yahoo.comwrote in message
news:11*********************@i42g2000cwa.googlegro ups.com...
:
: Thanks for the clarification. It sounds like an assembly most closely
: corresponds to a project, but that there is a contextual difference
: between a project and an assembly.
:
: Now here's the really substantive part of my question: To the extent
: that there is a differrence between "project" and "assembly", isn't it
: more correct to say that Friend applies to a project, not an assembly?
:
: In other words, I'm proposing that the definition of Friend is not only
: confusing, but technically wrong. It seems to me that the distinction
: between Friend and Private is relevant only during development; thus,
: it is a concept with meaning in the context of projects, not
: assemblies. Wouldn't it be more appropriate to define Friend as a way
: to specify that "elements are accessible from within the same PROJECT",
: not "within the same ASSEMBLY"?
No, I don't think so. As a basic rule of thumb, a VS project and a .Net
assembly are the same thing, conceptually.
"Assemblies are the unit of class deployment in the common language
runtime. Developers writing .NET Framework classes using Visual
Studio .NET version 7.0 will produce a new assembly with each
Visual Studio project that they compile. Although it is possible to
have an assembly span multiple portable executable (PE) files
(several module DLLs), Visual Studio .NET will, by default, compile
all assembly code into a single DLL (1 Visual Studio .NET project
= 1 .NET Framework assembly = 1 physical DLL)."

http://samples.gotdotnet.com/quickst...eployment.aspx
However, and I think this is what you are overlooking, VS projects aren't
the only way to generate assemblies. I will use notepad and the command line
compiler as often as not for small efforts. What the two approaches have in
common is that they both end up creating assemblies.
The .net framework is what you are targeting and it uses "assemblies".
Visual Studio on the other hand is a tool you can use to create those
assemblies. However, you might have instead chosen to use a tool that uses
the term "Container" instead of "Project" when developing assemblies. So
would it then be more correct to say that "Friend" applies to a "container"
and not a "project"? Of course not; the question is meaningless.
At the end of the day, an "assembly" is really the only thing the framework
knows about. It doesn't know or care about which tools you used to create it
or the terminology those tools used to describe how the assembly was being
generated. It is fine to refer to "Projects" in a VS context, but the term
risks loosing its meaning in any other. Stick with "assemblies" if you are
speaking about the .net framework.
As for the meaning of "Friend", it is a well accepted term in OOP that
conveys a specific concept. Essentially, declaring something as "Friend"
grants privileged access to that object or functionality to other members
within the same assembly while denying that access to consumers of the
assembly.
For example, say you create an assembly that accesses a database and you
decide to create a separate class within the assembly to handle that
functionality. It may not be a good idea to grant just any consumer of the
assembly access to that class as you may want to carefully control how users
get to and manipulate the database. By declaring that class "Friend", you
allow the other classes in the assembly to access it (since those classes
presumably will behave themselves when manipulating the data) yet you
prevent outside, potentially malicious (or at least careless) users from
getting to the database via the class.
<snip>
Ralf
--
--
----------------------------------------------------------
* ^~^ ^~^ *
* _ {~ ~} {~ ~} _ *
* /_``>*< >*<''_\ *
* (\--_)++) (++(_--/) *
----------------------------------------------------------
There are no advanced students in Aikido - there are only
competent beginners. There are no advanced techniques -
only the correct application of basic principles.