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

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

残花月 发布于 2021-11-27 字数 822 浏览 842 回复 4 原文

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?

如果你对这篇文章有疑问,欢迎到本站 社区 发帖提问或使用手Q扫描下方二维码加群参与讨论,获取更多帮助。

扫码加入群聊

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

深白境迁sunset 2022-06-07 4 楼

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

素染倾城色 2022-06-07 3 楼

Have you considered using MEF

宛菡 2022-06-07 2 楼

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

云归处 2022-06-07 1 楼

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.