What is an assembly?

  • Thread starter Thread starter TC
  • Start date Start date
T

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?
 
:
: 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
 
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?
 
TC,

An assembly is a build program whatever it is.

Cor

TC said:
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?
Click to expand...
 
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?
Click to expand...

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.
 
:
: _AnonCoward 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?
: >
: >
: > 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
 
Simplistic explanation
I'm trying to figure out what the "Friend" keyword does
Click to expand...


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
 
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"?
 
TC said:
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"?
Click to expand...

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
 
TC said:
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"?
Click to expand...

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
 
:
: 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/quickstart/aspplus/doc/deployment.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
 
TC said:
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"?
Click to expand...

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.
 
Back
Top