Question about good practices to split up a big project when using Paket

Description

As I did not find a mailing list or forum for discussion I try to ask my question here as an issue. If that is not appropriate please guide me to the right forum.;-)

We have a big .NET solution wit about 400 C# projects, mainly some kind of platform software and GUI with about 150 projects and about 10 user (application) projects with the rest of the projects. As this does not really scale anymore we are thinking about splitting this up into smaller modules with smaller git repos (we are currently in one big Clearcase repo). Paket seems very promising to us for managing dependencies but we are asking ourselves how to manage dependencies across repos? In the end everything is deployed together on a target machine and 3rd party dependencies should be the same version across our program, at least as long as we load everything into one app domain.

How would you manage the common part .paket, paket.dependencies and paket.lock across the projects? How would you split up a big project when you use Paket. Which boundaries would you use? Everything with its own installer is a module? Even smaller modules, especially for interface contracts?

Thanks for any hints

Review the dependency files named in the issue: .paket, paket.dependencies, and paket.lock. Determine what guidance is needed for sharing or separating them across repositories and how module boundaries should be chosen; done means documenting a clear recommended approach for this large multi-project solution.