Both methods have their advantages and disadvantages, and which one is better ultimately depends on multiple factors such as your team size and composition, your build and release setup, and what's more convenient for you.
Many projects just chuck everything into one solution, and for small- to medium-sized codebases worked on by a few people this is a perfectly fine approach. You get the convenience of being able to reference common code easily without messing with private NuGet feeds or cross-solution references, you don't need to switch between Visual Studio instances if the change you're making touches multiple solutions, and debugging is less of a pain. Judging by Microsoft focusing on things like lightweight solution load in VS2017 this is a pretty common use case.
In larger projects, however, the idea of having a single, tightly coupled repository of code with everything and the kitchen sink inside it requires a lot of communication and synchronization between the developers. If team Vendor Backend just changed your common library and needs to release their updated version yesterday, but team Customer Backend starts complaining that it'll take them a month to integrate the changes, that single solution becomes a problem.
You can rely on your source control discipline and proper branching to solve it, but at some point it becomes a good idea to split your project into smaller, independent components - for example, your utility methods could become a NuGet package, with a separate repository and solution, and a consistent versioning scheme. Then team Vendor Backend can update to the newest code in its own solution, and team Customer Backend can take its time working on integrating the newer package and other things they need to do without being held back.
If you're working alone and you don't have so much code that it becomes unwieldy to deal with a single solution, that's probably overkill. You trade away the convenience of just being able to change code and push things - if your common code is a NuGet reference, you need to change the code in the common solution, ensure it's up to snuff with respect to unit tests and standards, build and put it in the NuGet feed (presumably first the local one for testing, then the release one), update the package and only then have your change completed.
In short - if the benefits of loosely coupling your modules outweigh the drawbacks of having to maintain the strict release process, go for separate codebases for each module. If not, it's perfectly fine to just keep it in one solution.
