DLL mess in .NET, how to split one solution to multiple DLLs?

Question

I've got a big VS.NET project with 5-6 projects and one of these projects is the Core DLL.

Now to add some plugin support I extracted an interface, however interface was required to use some other classes and the Core.dll needed the interface so I had to separate them. (I can't reference to each other)

After this my day ruined because even after spending about 4 hours, I couldn't separate them! At the end I created like 20+ projects and still it doesn't work (actually not even close). Looks like I am going to end up with 50 projects and need to change lots of code to get it right.

I was aware of that my code was highly coupled, and bit back.

Am I doing this right? Now do I have to pay my dues and suffer because of my highly coupled code? Or am I missing something?

Answer 1

Refactoring, refactoring, refactoring. You will have to pay your dues, but I think it is worth it. You'll learn a lot.

Answer 2

If your working with interfaces, you should be able to pull your interface out of the core DLL, and interfaces for any requirements on that original interface, with little pain.

If you have highly coupled dependencies through your interface, you will likely need to refactor a bit. Try to extract either interfaces or base classes out of the main interface's dependencies (which would be easy to pull into the new project). This should help prevent the circular dependency problems it sounds like you're running into right now.

In general, though, I'd say to step back and think about your project before you do this at all. The project layout should be based off function more than depedencies - if you group your classes according to what they are doing cleanly, most of the dependency issues tend to clean themselves up. I'd really look into refactoring this before you try to extract, in order to get the cleanest layout possible.

Answer 3

Have you considered using MEF

Answer 4

Did you already create a dependency graph? Graphviz dot can help visualizing (and explaining) the problem.