[louthy]

Our eco-system is wide rather than tall. We have a solution that is a general purpose set of libraries that most of our projects include, then our core app which is a 50+ project solution, and many satellite service solutions.

The satellite services communicate with each other through my LanguageExt.Process system which is a clustered actor-library, and so as long as the message formats stay the same they can be built and updated separately.

Each solution has a '<project name>.Dependencies' csproj included that contains all of the nu-get dependencies. It builds to ../bin, and then all of the projects in the solution add their dependencies from there. That means it's relatively easy to manage the dependencies for each solution.

There's a manual element of waiting for a project to build [on TeamCity] before updating the references in projects that depend on it, but on the whole it's not been too bad.

[smoothdeveloper]

it is 'paket.references' file next to each proj file and a single 'paket.dependencies' at the root of the repository.

You can also integrate the restore part to msbuild so it works out of box from visual studio, msbuild, teamcity, whatever.

People prefer though to have separate restore packages step, the same way people prefer to use a better tool than raw msbuild to orchestrate build tasks (tool such as FAKE http://fsharp.github.io/FAKE/).

[louthy]

Thanks for that. So I assume from this that I could drop the Dependencies project that we're using for paket.dependencies. Would the auto-migrator deal with this do you think? I guess it seems like it would.

[smoothdeveloper]

Sorry, I think I misunderstood your setup.

The proper way to do it with paket would be:

* get rid of the Dependencies project (it was a side effect of trying to cope with the pain of using raw nuget)

* add a paket.dependencies at the root of your repository listing all nugets used across the solutions

* next to each project, add a paket.references file with the names of the dependencies (only top level, you don't need to list transitive ones)

running the convert-from-nuget command should practically work out of the box if you don't have far out inconsistencies (which I believe you managed by reducing amount of packages.config files), but I'd recommend to do another round of sanitization similar to what I'm describing.

I think if you give it half a day of studying / using paket on a smaller repository, you'll figure out all the things you need to accomplish migration on a large scale repository, after which you'll be recouping benefits any time you need to adjust references in projects / add or update nuget packages.

[louthy]

Thanks for the info, very useful. I'll definitely investigate.