I created a assembly having a child class that derives from a parent defined in another assembly.
When I add reference to the child, Visula studio also requires reference to be added to the parent.
Why is it so and how can I prevent it without losing any functionality?
What you describe is partially possible. You can eliminate the need for them to explicitly reference the hidden assembly, but that assembly will still get pulled in at compiled time, and required at runtime.
Let's say you have these classes defined:
// in assembly 1:
public class A
{
public virtual void Foo() { }
}
// and in assembly 2:
// requires explicit reference to assembly 1 to use
public class B : A
{
public override void Foo() { }
public A Value { get; set; }
public void Foo(A value) { }
}
// has implicit reference to assembly 1, but end user can ignore
public class C
{
private A Value { get; set; }
internal void Foo(A value) { }
protected internal A Bar() { return new A(); }
}
// usable at runtime even if assembly 1 is missing, as long as you don't call Foo()
public class D
{
public void Foo() { A blah = new A(); }
public void Bar() { }
}
If the end user uses class B, they will require an explicit reference to assembly 1. Since A is part of B's public interface, in order to use B, you have to know about A. There are 3 different public references to A, and any of them will require knowing about A to use B.
However, class C makes references to A, but all references are private/internal/local. Since every reference to A is hidden from the outside, the end user doesn't have to explicitly know about assembly 1. It will still be required at runtime, but you don't have to add it as a reference, it's an indirect reference.
And if the end user uses class D, without ever using B or C, assembly 1 will only get loaded if you call D.Foo(), which has a local variable of type A. You can actually use D.Bar() freely even if assembly 1 is completely missing at runtime. Although if you call D.Foo() and assembly 1 is missing, you'll get an exception.
In C/C++, class definition is present in a .h header file. That gives you ability to reference information about a class (as needed e.g. when you want to inherit from that class) without the need to source file with implementation information. The downside is code duplication (implementation in .cpp file needs to repeat most of the information in .h file).
In .NET world the design is different: an assembly contains both the code for the class (CLR bytecode) as well as all the metadata (class name, information about its members etc.) needed to e.g. inherit from that class.
A consequence of that design is that in order to use a class defined in assembly A that inherits from a class in assembly B, .NET needs both A and B assemblies. Or more generically: if you use anything from a given assembly (a class, an enum, a struct), either directly or indirectly, you need to reference that assembly.
I'm not sure what you want to prevent. If you decide to split your code in two assemblies like you described, there's no way around the need to reference both of them.
There are, of course, different ways of structuring your code but not knowing what goal you're trying to achieve by splitting the code into 2 assemblies in the first place, it's impossible to make a useful suggestion.
