5 ms·

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

by louthy 10y ago

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/ https://github.com/louthy/language-ext/

hurricaneSlider 10y ago
Hey Louthy. Just wanted to say that I really appreciated your framework.
- louthy 10y ago
  Thank you :) Out of interest, what are you using it for?
  - hurricaneSlider 10y ago
    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 10y ago
      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.
smoothdeveloper 10y ago
Small note about Nuget, you might consider upgrading to paket (works nice with C# too): http://fsprojects.github.io/Paket/ http://fsprojects.github.io/Paket/ It removes so much pain compared to raw usage of Nuget and is very easy to learn/adopt.
- louthy 10y ago
  > 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
  - markfsharp 10y ago
    paket convert-from-nuget
  - mscrivo 10y ago
    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 10y ago
      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 10y 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/ http://fsharp.github.io/FAKE/).

by louthy 10y ago

hurricaneSlider 10y ago

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

louthy 10y ago
Thank you :) Out of interest, what are you using it for?
- hurricaneSlider 10y ago
  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 10y ago
    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.

smoothdeveloper 10y ago

Small note about Nuget, you might consider upgrading to paket (works nice with C# too): http://fsprojects.github.io/Paket/ http://fsprojects.github.io/Paket/ It removes so much pain compared to raw usage of Nuget and is very easy to learn/adopt.

louthy 10y ago
> 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
- markfsharp 10y ago
  paket convert-from-nuget
- mscrivo 10y ago
  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 10y ago
    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 10y 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/ http://fsharp.github.io/FAKE/).