Hacker News new | ask | show | jobs
by smoothdeveloper 3665 days ago
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/).

1 comments

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.
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.

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