4 ms·

I can't share the name, but we've built a complete enterprise stack on Mono. There are several parts: - Server, Nancy2/Marten/Hangfire, runs on linux - Headle

I can't share the name, but we've built a complete enterprise stack on Mono. There are several parts: - Server, Nancy2/Marten/Hangfire, runs on linux - Headless clients for linux and Windows (x64) - GUI clients for macOS, linux and Windows (x64) The server is deployed as a static fat binary. The headless clients are static binaries for linux and .NET proper for Windows. The GUI clients use Eto, which in turn means: - Static binary using Eto.Gtk on linux - Static, signed app bundle (Gatekeeper friendly) using Eto.Xamarin on macOS - .NET proper application using Eto.Wpf on Windows No performance issues so far. I wish Mono would implement a GUI for the profiler though. The log profiler is great to use, but clunky in comparison with dotTrace or NProfiler. The whole architecture sounds complicated but really isn't. It's a single solution with three* projects: - Server - Headless Clients - Single Eto GUI for all platforms - (* Target build projects for the GUI platforms, no code in here) The build server then only needs to do some additional work for creating DMG installers and signing the macOS app.

galli-leo 8y ago
Try Xamarin Profiler as a GUI :). It supports loading mlpd files and makes your life 10x easier (if it doesn‘t crash).
oblio 8y ago
How's Eto? It seems really cool but it's backed by a small company, I think there's just 1 developer. Also, do your GUI clients have fancier UIs? For example, have you implemented your own grid view, something where you put custom controls in the cells, images, graphics, etc.?
- minxomat 8y ago
  We maintain internal forks of Eto and Nancy. They are easy enough to grok for us to modify and maintain, even when development upstream dies. Most of the user interaction is happening via the web app served by the server. The local clients are "just" for configuration, comparable in complexity with e.g. Tunnelbear or Glasswire. We use some custom grid elements, which have been easy to implement. Eto is the only framework out there which gives you native GUIs everywhere. That's what was most important to us. Native speed, native OS integration (tray menus, notifications etc.). It's also really easy to learn for devs who might have been WPF-exclusive before.
  - oblio 8y ago
    A sort of follow-up question: have you contributed things back to Eto? Were they responsive? Thank you for your detailed answer, by the way! :)
    - minxomat 8y ago
      No, most of the small customizations are very specific to our application. Mostly how closing events or notifications are handled. TBH at least I don't think much about Eto day to day, it's just there and works. Questions mostly have been answered by existing issues, where the author seems responsive enough.

galli-leo 8y ago

Try Xamarin Profiler as a GUI :). It supports loading mlpd files and makes your life 10x easier (if it doesn‘t crash).

oblio 8y ago

How's Eto? It seems really cool but it's backed by a small company, I think there's just 1 developer. Also, do your GUI clients have fancier UIs? For example, have you implemented your own grid view, something where you put custom controls in the cells, images, graphics, etc.?

minxomat 8y ago
We maintain internal forks of Eto and Nancy. They are easy enough to grok for us to modify and maintain, even when development upstream dies. Most of the user interaction is happening via the web app served by the server. The local clients are "just" for configuration, comparable in complexity with e.g. Tunnelbear or Glasswire. We use some custom grid elements, which have been easy to implement. Eto is the only framework out there which gives you native GUIs everywhere. That's what was most important to us. Native speed, native OS integration (tray menus, notifications etc.). It's also really easy to learn for devs who might have been WPF-exclusive before.
- oblio 8y ago
  A sort of follow-up question: have you contributed things back to Eto? Were they responsive? Thank you for your detailed answer, by the way! :)
  - minxomat 8y ago
    No, most of the small customizations are very specific to our application. Mostly how closing events or notifications are handled. TBH at least I don't think much about Eto day to day, it's just there and works. Questions mostly have been answered by existing issues, where the author seems responsive enough.