|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
What is an assembly?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" <golemdan***@yahoo.com> wrote in message This is extremely simplistic (and incomplete), but hopefully it will givenews:1153879087.718628.46820@p79g2000cwp.googlegroups.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? 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. 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: Show quoteHide quote > "TC" <golemdan***@yahoo.com> wrote in message > news:1153879087.718628.46820@p79g2000cwp.googlegroups.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,
An assembly is a build program whatever it is. Cor Show quoteHide quote "TC" <golemdan***@yahoo.com> schreef in bericht news:1153884492.480519.116950@75g2000cwc.googlegroups.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" <golemdan***@yahoo.com> wrote in message >> news:1153879087.718628.46820@p79g2000cwp.googlegroups.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. > > Thank you for the explanation. In your example, the two classes defined No. Usually, all .vb files in the same project (but not solution) belong > 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? 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
Show quote
Hide quote
"TC" <golemdan***@yahoo.com> wrote in message Not exactly. It is possible to compile two or vb files into the samenews:1153884492.480519.116950@75g2000cwc.googlegroups.com... : : _AnonCoward wrote: : > : > "TC" <golemdan***@yahoo.com> wrote in message : > news:1153879087.718628.46820@p79g2000cwp.googlegroups.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? 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. 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: Show quoteHide quote > > 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
Show quote
Hide quote
"TC" <golemdan***@yahoo.com> wrote in message Quoted from news:1153925700.366301.17400@i42g2000cwa.googlegroups.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"? > > "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
Show quote
Hide quote
"TC" <golemdan***@yahoo.com> wrote in message Ok Friend is relative to an assembly while Private is relative to the news:1153925700.366301.17400@i42g2000cwa.googlegroups.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"? > > 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
Show quote
Hide quote
"TC" <golemdan***@yahoo.com> wrote in message No, I don't think so. As a basic rule of thumb, a VS project and a .Netnews:1153925700.366301.17400@i42g2000cwa.googlegroups.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"? 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 -- -- ---------------------------------------------------------- * ^~^ ^~^ * * _ {~ ~} {~ ~} _ * * /_``>*< >*<''_\ * * (\--_)++) (++(_--/) * ---------------------------------------------------------- There are no advanced students in Aikido - there are only competent beginners. There are no advanced techniques - only the correct application of basic principles. You've explained it very well. I see things clearly now. Thank you.
_AnonCoward wrote: Show quoteHide quote > "TC" <golemdan***@yahoo.com> wrote in message > news:1153925700.366301.17400@i42g2000cwa.googlegroups.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/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 > -- > -- > ---------------------------------------------------------- > * ^~^ ^~^ * > * _ {~ ~} {~ ~} _ * > * /_``>*< >*<''_\ * > * (\--_)++) (++(_--/) * > ---------------------------------------------------------- > 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 wrote:
Show quoteHide quote > Thanks for the clarification. It sounds like an assembly most closely No. It so happens that what VS calls 'Projects' usually end up producing > 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"? 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 larryl***@googlemail.com The address is real, but unread - please reply to the group For VB and C# questions - tell us which version 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 Show quoteHide quote "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? > > 
Other interesting topics
silly, probably meaninigless question
DEBUG: can we disable try/catch ? Microsoft (R) Visual Basic Compiler has encountered a problem and needs to close. :o( How do I handle this Programmable LEGO blocks? How to ping an IP address by using sockets in Visual Basic .NET No accessible overloaded Disabling the Form Designer Week Ending last API question.... |
|||||||||||||||||||||||
