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
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.
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
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.
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.
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/).
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.
As far as I'm aware, the most popular F# tools for writing code are (from most to least popular): Visual Studio, Ionide (either using Atom or VS Code) and Emacs. I haven't seen that many people coding in F# using anything else, but I'm sure you'd find a few people using the usual suspects (Vim, Sublime Text, etc...).
Last I tried there were a couple of issues with autoindentation with the fsharp plugin for emacs, but they're well aware of the issue and have been working on it last I checked.
I'd like to use mainly emacs but I've noticed high delays in auto completions on certain type providers that don't exist in VS. Not sure what the issue is...
The toolset is pretty boring/standard though: VS2015 + TeamCity + in-house Nuget + Gitlab
[1] https://github.com/louthy/language-ext/