DLL reference chain question

[Bob]

I have a common DLL used across several applications, let's call it One.dll.
Then I have a data access component (called Two.dll) that references
One.dll. A particular application only needs Two.dll (and not One.dll
directly). I was hoping that add Two.dll in the application and reference
its namespace would be enough. However, during compiling the main
application, it complains that the classes in Two.dll needs One.dll,. which
is not referenced. I understand what the message means literally, and if I
add One.dll in the main application, it compiles and works fine. However, I
think it'd be better if Two.dll has enough info from One.dll and it's
self-contained. This way it's only necessary to reference Two.dll in the
main app. Is this doable? or not the intended behavior at all?

 

[Philip Rieck]

This is doable with proper design:

What you need to be sure of is that Two.dll doesn't expose any of the types
in One.dll. So no parameters, return types, events (delegates) are exposed
from Two.dll that are of types defined in One.dll.

In One.dll
public class oneClass{ public string field;}

In Two.dll -> this will trigger your compiler message
public class twoClass{ public void Func( oneClass one){}}

In Two.dll -> this will not
publc class twoClass{public void Func(string field){ oneClass one = new
oneClass; one.field = field ...... }}


Note that while you won't have to reference it, you will still need to
deploy the One.dll with your application (or have it be installed in the
GAC) or Two.dll will throw exceptions.

 

[Nicholas Paldino [.NET/C# MVP]]

One other important situation to mention is when you have a class in
Two.dll which derives from a class in One.dll. In this case, you need to
add a reference as well.

Hope this helps.