Do you have a big and heavy solution? Do you want to split it? Are you afraid? I will try to help. Be for we start, though, we should answer a few questions.
Why Should I Split?
Before I show how to split, I have to deal with the common myths:
My solution isn't so big. It has only 10/20/100/100/X projects/classes inside
I cannot recommend how small one solution should be. I can agree that in some cases, 10 can be enough small, but I am sure that 50 is too much. I'm sure that when you open a solution, you will know that it is too big. But be fair with yourself.
I cannot split because we don't have enough test coverage
That is a very interesting myth. A split shouldn't make functional changes, so probably it won't break anything in the functional part of your system. Anyway, how do you test when you make new functionality? Automatically, manually, or using production users? In this case, do the same thing.
I don't see anything to separate
That's untrue, isn't it? For example, tools/utils can be separate, DTO, database projects, web projects, etc.
I don't have any dependency management
Maybe it's time to introduce it. Moreover, think about how you include external components. Can you build your stuff when the Internet is down? Aren't they a dependency management?
To introduce dependency management system, try just one library as a proof-of-concept.
My business owner/product manager/product owner won't accept spending time on this
Explain this: It won't take long, and after this change, we can develop more easily. We will spend some time now, but in the near future, we can work more quickly.
What if he doesn't understand? Maybe it's time to quit your job.
In near future, I will show how we can use ReSharper and Visual Studio to split your solution into smaller ones. Stay tuned.