OO Process...references use - why not?
This has sorta hit me... and I'm not kinda started thinking and wondering.
Let's say I have an assembly that is a .DLL. So, we'll call it A.DLL.
To create A.DLL I have references to B.DLL and C.DLL. All of the .DLL's are in using a difference namespace. Let's say all the methods and everything are publically scoped in B.DLL and C.DLL like "Test" in C EXCEPT for those that are used internally in B.DLL or C.DLL and let's say they are private (restricted to the class.)
Now, I have assembly E.EXE and it is using the reference A.DLL.
Why cannot I not use and anything in C.DLL that are publically scoped?
I mean I am "using A;". But why can't I do something A.Test?
A has C in it but yet I cannot access C.
The only way is in the E.EXE I add a reference to C then I needing to add "using C;"
Then I can access Test. Not through A.Test but "Test".
If I have to do that they isn't C in the assembly twice? Once for the E.EXE and onces for the A.DLL?
What am I missing here because it seems duplicative?
Any information would be greatly appreciated.
Thanks
Let's say I have an assembly that is a .DLL. So, we'll call it A.DLL.
To create A.DLL I have references to B.DLL and C.DLL. All of the .DLL's are in using a difference namespace. Let's say all the methods and everything are publically scoped in B.DLL and C.DLL like "Test" in C EXCEPT for those that are used internally in B.DLL or C.DLL and let's say they are private (restricted to the class.)
Now, I have assembly E.EXE and it is using the reference A.DLL.
Why cannot I not use and anything in C.DLL that are publically scoped?
I mean I am "using A;". But why can't I do something A.Test?
A has C in it but yet I cannot access C.
The only way is in the E.EXE I add a reference to C then I needing to add "using C;"
Then I can access Test. Not through A.Test but "Test".
If I have to do that they isn't C in the assembly twice? Once for the E.EXE and onces for the A.DLL?
What am I missing here because it seems duplicative?
Any information would be greatly appreciated.
Thanks
ASKER
I so apologize, I even confused myself what what I was trying to say...
A.DLL has a reference to B.DLL and C.DLL
E.EXE has the A.DLL but I cannot access anything in the C which is a part of the A.DLL.
In the E.EXE I need some of the functions of A.DLL and some of what C offers in objects and methods.
Now, in the E.EXE when I just reference the A.DLL (which again includes C.DLL) I cannot access what C offers only what A uses of C.
The only way for me to do it is in the E.EXE, I add a reference to A.DLL AND C.DLL.
Good point on the duplication aspects and that set me straight as it would the CLR would use the manifest for the assembly. It's still a small footprint but it still must process the reference or pointer to the C.DLL in BOTH when used so a footprint and process none-the-less.
Is there a way to advertise the implementation though so that in my example the E.EXE uses the A.DLL (which includes the reference or pointer (defined in the manifest for the assembly to the C.DLL)) so that I can use more of C?
I have to say I'm missing the point of it when a new D.DLL happened. Because it would essentially be a different DLL with a different version and assembly constructed with a different manifest. A.DLL version 1 would be with the C.DLL requirement. A.DLL version 2 would be with the new D.DLL as a requirement and no longer using C.
In a situation like that then a *new*, if needed due a change requirement or what have you, then E.EXE would then be forced to reference the A.DLL AND the C.DLL.
I'm referencing package DLL's that are with the application and not those in the GAC.
Does that attempted explanation serve more justice?
A.DLL has a reference to B.DLL and C.DLL
E.EXE has the A.DLL but I cannot access anything in the C which is a part of the A.DLL.
In the E.EXE I need some of the functions of A.DLL and some of what C offers in objects and methods.
Now, in the E.EXE when I just reference the A.DLL (which again includes C.DLL) I cannot access what C offers only what A uses of C.
The only way for me to do it is in the E.EXE, I add a reference to A.DLL AND C.DLL.
Good point on the duplication aspects and that set me straight as it would the CLR would use the manifest for the assembly. It's still a small footprint but it still must process the reference or pointer to the C.DLL in BOTH when used so a footprint and process none-the-less.
Is there a way to advertise the implementation though so that in my example the E.EXE uses the A.DLL (which includes the reference or pointer (defined in the manifest for the assembly to the C.DLL)) so that I can use more of C?
I have to say I'm missing the point of it when a new D.DLL happened. Because it would essentially be a different DLL with a different version and assembly constructed with a different manifest. A.DLL version 1 would be with the C.DLL requirement. A.DLL version 2 would be with the new D.DLL as a requirement and no longer using C.
In a situation like that then a *new*, if needed due a change requirement or what have you, then E.EXE would then be forced to reference the A.DLL AND the C.DLL.
I'm referencing package DLL's that are with the application and not those in the GAC.
Does that attempted explanation serve more justice?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you much! Very detailed and affective information.
It did make me wonder why some of what I am working on was done the way it was. It should have been re-architected. Where as A.DLL should never have really had a reference to C.DLL. I see no value in that with respect to the purpose and intent of C.DLL.
The container assembly or E.EXE should have used A.DLL and C.DLL as separate references in the first place.
It did make me wonder why some of what I am working on was done the way it was. It should have been re-architected. Where as A.DLL should never have really had a reference to C.DLL. I see no value in that with respect to the purpose and intent of C.DLL.
The container assembly or E.EXE should have used A.DLL and C.DLL as separate references in the first place.
A.DLL provides implementation of some object or group of objects
B.DLL provides implementation of some object or group of objects
C.DLL provides implementation of some object or group of objects
The fact that A references B which references C is not relevant to your EXE.
If you want to use an object/functionality that is defined in the C.DLL library, you have to reference it that way. C.DLL contains the functional code you want to use. Just because A or B might reference it and make use of code contained within C, A or B doesn't advertise the implementation of that code. The linker is aware of it so that it will load the proper DLL when required, but from your executable's perspective, it needs to know that it requires code from C.DLL directly.
Consider this, if it worked the way you were thinking, you could never change the implementation of A to reference a new D.DLL and no longer use C.DLL as the chained requirement would exist to keep C.DLL. That would become a problem as bad or worse than DLL Hell...
As to duplication, the various DLLs do not copy the code they reference into themselves, the linker creates a dependency for that DLL to be loaded and a reference into the DLL so that that code can be used. One of the primary reasons Dynamic Link Libraries were created was for the very duplication problem you think you are seeing. When using statically linked code, executable files would copy some or all of the binary library (depending on the language/linker capabilities). This would cause memory and disk bloat in systems using these statically linked executables. Consider if you had a statically linked program you loaded multiple instances of. Each program would have memory allocated for the library code contained within it. DLLs relieve this problem as each executable will only reference the DLL and thus multiple instances will still only load one copy of the DLL.
That help any?