[louthy]

We use it for satellite projects around our core C# app (the only reason the core isn't F# is legacy, so I created a C# library to get as close as possible when updating/refactoring [1]).

The toolset is pretty boring/standard though: VS2015 + TeamCity + in-house Nuget + Gitlab

[1] https://github.com/louthy/language-ext/

[smoothdeveloper]

Small note about Nuget, you might consider upgrading to paket (works nice with C# too):

http://fsprojects.github.io/Paket/

It removes so much pain compared to raw usage of Nuget and is very easy to learn/adopt.

[louthy]

> It removes so much pain compared to raw usage of Nuget and is very easy to learn/adopt

We have a very large number of projects and migrating them all to paket would be a hassle, so I'd be interested in what pain in particular it removes?

I'm no fan of nuget I can tell you, but I'd be interested to understand what you feel the big wins are

[smoothdeveloper]

* reduced churn on proj files

ensure consistency of dependencies across repository (can't do that with so many packages.config files)

* easy to figure out outdated dependencies / update those with changes that are very easy to diff

* no need to battle with transitive dependencies

* several transitive dependencies resolution algorithm (max can be used to be as up-to-date as possible)

* ease support for multi platform targeting (it puts conditionals around the references, when you switch platform, it switches to correct assemblies without you having to do anything)

* will write/maintain binding redirects related to nuget packages for you (saves from many runtime errors)

* can generate include scripts for nuget packages if you do .csx or .fsx scripting

* many more things

the UI integration in VS is not as good but if you look at it, the UI is also part of the problem with Nuget (doesn't work on several solutions, doesn't really understand transitive dependencies, etc.).

You can migrate with single command line, and start improving from then on.

[python_kaa]

it is a worth to try. It is: - fast, - reliable, - understands transitive dependencies, - can manage them in groups (like build-deps, test-deps, doc-deps) - can have http and github as a source. Just one drawback - comparable not so good graphical UI in VS, but very good CLI, converts entire solution from nuget with just one command in terminal

[mscrivo]

We have an almost identical setup to yours. How do you manage the long build chains in team city with the number of nuget packages you have? It's something we are grappling with and are considering moving everything back into a single repo with no nuget packages as a result.

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

[markfsharp]

paket convert-from-nuget

[hurricaneSlider]

Hey Louthy. Just wanted to say that I really appreciated your framework.

[louthy]

Thank you :) Out of interest, what are you using it for?

[hurricaneSlider]

All over the place. :) I'm busy writing a federated subscription resolution framework, and I was finding it difficult to maintain a coherent dependency graph with mutable data structures.

[louthy]

Awesome. That's great to hear. If you have suggestions on improvements I'm always open to feedback, so feel free to shout on the issues page.