3

Question

It seems to me that any time I make a class library, all of its dependencies should just come with it. In other words, I would expect to just reference a .dll and go. After all, the .dll I reference builds just fine on its own.

Is this not the case? I reference all of a dependency's dependencies, in order to use it?

Looking forward to being enlightened about this.

Issue

To illustrate, here's an example.

  • ClassLibrary1 is a class library project, with one public class: Class1.

  • ClassLibrary2 is another class library, in the same solution, with one public class: Class1.

    These two classes exist in their own namespaces.

    However, ClassLibrary2 references ClassLibrary1, and ClassLibrary2.Class1 inherits from ClassLibrary1.Class1.

  • ConsoleApplication1 is a console app, in the same solution, that references only ClassLibrary2.

Up to this point, everything builds. Everything is the same framework.

However, when I attempt to initiate ClassLibrary2.Class1, I get a build error:

Error 1 The type 'ClassLibrary1.Class1' is defined in an assembly that is not referenced. You must add a reference to assembly 'ClassLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. ...\ConsoleApplication1\Program.cs 12 4 ConsoleApplication1

Code Snippets

namespace ClassLibrary1
{
    public class Class1
    {
        public Class1() { }
    }
}

...

namespace ClassLibrary2
{
    public class Class1 : ClassLibrary1.Class1
    {
        public Class1() : base() { }
    }
}

...

namespace ConsoleApplication1
{
    using ClassLibrary2;

    class Program
    {
        static void Main(string[] args)
        {
            // error mentioned previously in post is on following line
            var a = new Class1();
        }
    }
}
Aaron Thomas
  • 4,670
  • 6
  • 35
  • 79
  • 1
    It should'n, but ClassLibrary1.dll must be accessible. – McNets Dec 29 '16 at 15:40
  • I think it's just how C# and .NET work. `ClassLibrary1` is a direct dependency of `ClassLibrary2` and `ClassLibrary2` is a direct dependency of `ConsoleApplication1`, so `ClassLibrary1` is an indirect dependency of `ConsoleApplication1`. The compiler needs to know that all of the dependencies are available for a particular project before that project is built. – Theodoros Chatzigiannakis Dec 29 '16 at 15:44
  • Exactly, you have to add all (direct or indirect) used libraries to your application. Btw. it is not a good idea to use the same name for classes one derived from the other. – H.G. Sandhagen Dec 29 '16 at 15:47
  • Do you need reference `ClassLibrary1` in case where `ClassLibrary2` use `ClassLibrary1.Class1` internally? – Fabio Dec 29 '16 at 15:47
  • @TheodorosChatzigiannakis if all dependencies are in the same solution, this still holds true? – Aaron Thomas Dec 29 '16 at 15:54
  • 1
    The fact that they are in the same solution wouldn't matter. In VS, project level is more important. Each project has its own dependencies and then at build time, the compiler will traverse the dependency tree and copy all the dependencies it needs to the output folder. If one project references another project in VS, all you're really doing is pointing to the location of the built .dll. – coolboyjules Dec 29 '16 at 16:09
  • There are quite a lot of questions about this already. For example:http://stackoverflow.com/q/1132243/5311735 – Evk Dec 29 '16 at 16:13
  • @coolboyjules thanks for clarification. I think if you posted with a reference to some documentation on this process it would qualify as an answer. – Aaron Thomas Dec 29 '16 at 16:17

2 Answers2

3

I'll try to formulate an answer here. It helps to look at dependencies on the project level in VS and hopefully it will be more clear.

Suppose you have two projects, ProjectA and ProjectB in a solution. Both projects reference an assembly Important.dll. By reference here, I am referring to if you right click -> Add 'Reference' in a VS project. Suppose also, that ProjectA references ProjectB in our solution in VS. By this I mean, right click -> 'Add Reference' -> 'Solution' -> Pick Project B

What is actually going on? Remember, all a VS reference is a way to help the compiler find the .dll. At build time (compiling), VS will go through all the projects in the solution that are required to be built (you can see this in the Configuration Manager). It will notice that both ProjectA and ProjectB are set to build. Then it will look at all its direct dependencies in the references section by traversing the dependency tree. For all the VS references that are set to 'Copy local' (true by default), they will be sent to the build folder. So Important.dll will go to the build folder.. you probably knew that.

But ProjectA references ProjectB in VS. When you have a project that references another project in a solution, all you're really doing is pointing to the built .dll of that project... in this case ProjectB.dll. It's no different from antoher .dll. You can see this if you look at the references section under 'Path' in ProjectA... it'll be something like C:\users\jdwqdwqd\vs\ProjectB\ProjectB\bin\x64\ProjectB.dll. So this will be copied to the output folder as well.

I guess one might ask 'Won't Important.dll be copied twice along with ProjectB.dll?. VS gives you a lot of help here and will pick the correct .dll to copy.

Hope this helps.

Some more information:

https://msdn.microsoft.com/en-us/library/ez524kew.aspx

coolboyjules
  • 1,782
  • 1
  • 16
  • 36
0

It's just the way C# works. The inheritance rules seem to be skewed. I'm working on a massive project at work, and I can use class libraries and namespaces across multiple files, but I have to reference them every time, regardless of inheritance. It's weird and annoying. Maybe they'll fix that soon.

Uchiha Itachi
  • 1,140
  • 1
  • 15
  • 37