5 ms·

Recently we have started using Mono for a huge project. We have a pure unix-based stack and everyone cringed at the idea of running a .net application on Unix b

Recently we have started using Mono for a huge project. We have a pure unix-based stack and everyone cringed at the idea of running a .net application on Unix but decided to give it a try. HUGE mistake. After a couple months of development we have (today) abandoned the project and decided to take a different direction. Mono isn't just reliable for production, as simple as that. It will inevitably have unstable and unpredictable behaviours, period. That said, it might still be good alternative for desktop local apps. Just make sure you save your work enough times during your workflow ;)

rottyguy 13y ago
can you elaborate more on the reliability please?
- jnardiello 13y ago
  Well, by "unpredictable" i mean truly unpredictable. You can randomly get seg-faults with no stack trace nor log, 100% CPU sorted only by dirty tricks that totally out of question in production-like environments, etc.. Most of the problems weren't caused by mono alone nor by the app alone. The really buggy behaviors came out with the interaction of the two.
  - rottyguy 13y ago
    was hoping to hear something more concrete and what you had to do to resolve it (also what finally broke the camel's back to decide to walk away). I realize it could involve a bit of verbage but given the interest in .net openness these days, some real world scrutiny would be beneficial to us interested observers.
  - giulianob 13y ago
    What type of app were you running? Website or regular app? Also what version of Mono were you using? I have been running my server app for a few months now on 3.x and had some issues. For example, the default threadpool size is too small, the default implementation of FastCGI on Mono is super slow (there are alternatives out), and the GC behaves a bit differently (nursery size and collection schedule is different). I did have to learn more about the gritty details than when using .NET on Windows but you can fine tune most things. Things are running pretty smooth now though I am still trying to figure out how to debug from a GDB core dump.
  - rossjudson 13y ago
    Did you mix native and managed code?
  - Hansi 13y ago
    Any chance of a blog post about the issues is detail? Would be interested in hearing more.
socialist_coder 13y ago
This was my experience as well. Serving c# web apps on linux just sucks. I was using NancyFX, not ServiceStack. I wish I would have tried ServiceStack as well since I think they are probably better.
- giulianob 13y ago
  What issues were you having?
  - socialist_coder 13y ago
    Mostly just a very difficult time figuring out the "right" way to host it on Linux. I could never get it to perform worth a damn after trying a bunch of different hosting methods. I think ServiceStack would probably have solved my issues though.
patja 13y ago
I'm curious if you found some reference sites that had been successful running C# web apps on Mono, and if so what are they?
gabriel 13y ago
I know there are subtle differences in the .net memory model compared to mono. I've fallen victim to this sort of thing before and depending on what you are doing and how aware/disciplined a team is, this could very much be a pain point.
Skinney 13y ago
Sorry to hear that. I was running a mono-based server app for myself for some time. Never ran into any issues but my own. Ran Mono 2.10 on Ubuntu Server.
snarfy 13y ago
It works well enough for the servicestack people.
dawkins 13y ago
I'm sorry to hear that. I have been successfully running a web app on ubuntu/mono for four years now and I'm really happy about the stability and performance. It doesn't use any of the asp.net stack though.
DrJokepu 13y ago
Sadly, we had very similar experiences.
ihnorton 13y ago
Building a huge project on any unknown stack seems ... iffy. Apropos this rant that I recently (re-)read: http://lua-users.org/lists/lua-l/2011-10/msg00825.html http://lua-users.org/lists/lua-l/2011-10/msg00825.html Some other guy read about LuaJIT somewhere, so they give it a try, but obviously don't get a speedup and (of course) blame LuaJIT. They write angry letters to me, I try to politely explain to them that their design leaves something to be desired, they blame the messenger. Then they go and write a post-mortem in a game-centric blog about how bad Lua is, that nobody should ever use scripting for anything and that their next stellar project will use C# with lots of enterprise-ready frameworks. And that they're hiring, because they got nobody with a friggin clue about C#, but management dined with someone from Redmond and they know best, of course.
- jnardiello 13y ago
  Well, we are very well aware of what you mean. With us the situation was slightly different :) We hired - because our management cares - people who actually knew what they were doing, we got in touch with the person who phisically maintain the app that was running on mono and he re-assured that his software + mono were running smoothly. We have been hacking on it for months, literally. Contributed to the original project in any possible way. But THEN mono started to give strage behaviours. Unless hacking really bad on it, we understood that there was no way to deploy it in production as it could fuck up in any moment and we could do literally nothing unless deleting a file here and there and reboot. So yeah, i'm 100% sure that things could have been done differently - better - yet this was the outcome no matter how many resources we putted on it. We never complained with the creator of the application (yet, we discussed about it with him) and for the very same reason i don't want to name the product as i'm still convinced it is indeed a good piece of software. I'm just saying that with our project, 4+ very skilled people for about 2 months ended up with nothing. Take it or leave it :)
  - mikeho1999 13y ago
    Interesting story... but just out of curiosity, if there was already the investment made in the codebase for your application, as well as the team in place to continue with the project and maintain it afterwards, was there a consideration to switch to .NET / Windows Server? If so, I'm curious to hear the reasoning behind abandoning the project altogether and re-writing from scratch (and likely re-interviewing and hiring a different team with different skillsets) as opposed to simply moving the production environment onto Windows...
edwinnathaniel 13y ago
I know there are several desktop apps built using Mono for Linux but I suppose people have their opinions with respect to Mono. My biggest grip with Mono is the lack of automation tools (SCM in this case) and that alone is a show stopper for me. Maven and Eclipse/IntelliJ spoiled me too much that I'd rather not touch Make/Ant/CMake/MSBuild. MSBuild is Microsoft only (despite there may have been some support in Mono, as you have read the article, it's still Microsoft exclusive tool). I'd love to use Mono to develop cross-platform desktop application. I really really really do. In fact, I decided to give it a try one time despite its shortcoming that I mentioned above. In the end, I felt that there's simply too much work for me to build any side project using Mono. This may not be the case for serious commercial desktop app because they can invest more resources to deal with the automation tools. But for side project? Mono would definitely not on top of my list.
- BSousa 13y ago
  Have you taken a look at FAKE? http://fsharp.github.io/FAKE/ http://fsharp.github.io/FAKE/
  - edwinnathaniel 13y ago
    No, I have not. It's great to see a build tool like this but my apology, the syntax is horrifying! :( (I suppose that's a personal taste). I'm really2 spoiled by Maven because of all the things it does for me. FAKE is just like Ant/NAnt/MSBuild so it's not what I'm hoping for. I've worked with Ant before and the build script generally becomes bloated really quick with no standard.
MichaelGG 13y ago
I've been running telecom applications on Mono since 2008, doing up to a billion transactions a week across dozens of servers. After sorting out some minor deployment issues (mainly reading docs or making sure we understood which switches do what)... it just works. We've not had any unstable or unpredictable behavior. Once we've tested and gotten it working, it has stayed working. Only thing we've had problems with I think was the LLVM backend; IIRC some of our F# code didn't work on it. But that was before Mono 3.0 and I am not sure if we checked it since. One set of applications is typical business message processing. Read XML files, deal with SQL Server, Postgres, RabbitMQ. Another one was using the Mono runtime embedded in FreeSWITCH to do stuff to an active SIP call. FreeSWITCH's Mono integration isn't totally unused and I've yet to hear of any stability related bugs.
spo81rty 13y ago
Would it make more sense not to abandon all that work but instead just run the project on Windows??
knocte 13y ago
Saying that mono failed for your project and that you're not going to touch it again is like saying that opensource failed for your project and you're not touching it again. Mono is a project which has a lot of different pieces of technology underneath. Please tell us the part that didn't work for you, because you cannot attribute low quality to the whole project just by testing a small part. (i.e.: was your project a web app or a desktop app? how did you host it? did your team have any Unix expertise or were just a bunch of Windows devs expecting to become Linuxers overnight?) And most importantly, what version of Mono did you use? (Most people that complain end up saying that they just used the mono that their 4 year old distro supplied, which is a version even older than 4 years.)
- jnardiello 13y ago
  That is not the case. Team with a dedicated Unix devops engineer and a windows dev consultant, all other are skilled unix devs. We have been debugging like beasts and we are probably and realistically one of the best technical teams in the country. We ran everything on Mono 3.0, which we was chosen for specific reasons and weare very aware that is a 1.5yrs old distro. The last specific problem would maybe be sorted upgrading to last release (we don't know) but we already know that new issues would rise as the pattern keeps being the same.
  - turnip 13y ago
    "we are probably and realistically one of the best technical teams in the country" yet were unable to debug 2 months worth of new code on a mature platform, that lesser people have no troubles with.
  - knocte 13y ago
    You still haven't said the type of the app (web, desktop?), and in case of web, what technology you chose to host it (this is actually the root of many issues that people wanting to host Mono apps face, and it's kind of unrelated to Mono stack).
romanovcode 13y ago
Completely agree. I also recently did a medium-sized project with Mono (website) because I thought that it will be cheaper since service such as digital-ocean is very cheap. Turns out it would be cheaper to just host on Windows Azure because the work of fixing/tweaking things just so it will run properly took way more time (money) than was planned.
kanwisher 13y ago
I have a relatively large project in production that is using a ton of legacy c# code using mono for months ;/ with little issues. Could you maybe explain more about what you saw?

rottyguy 13y ago

can you elaborate more on the reliability please?

jnardiello 13y ago
Well, by "unpredictable" i mean truly unpredictable. You can randomly get seg-faults with no stack trace nor log, 100% CPU sorted only by dirty tricks that totally out of question in production-like environments, etc.. Most of the problems weren't caused by mono alone nor by the app alone. The really buggy behaviors came out with the interaction of the two.
- rottyguy 13y ago
  was hoping to hear something more concrete and what you had to do to resolve it (also what finally broke the camel's back to decide to walk away). I realize it could involve a bit of verbage but given the interest in .net openness these days, some real world scrutiny would be beneficial to us interested observers.
- giulianob 13y ago
  What type of app were you running? Website or regular app? Also what version of Mono were you using? I have been running my server app for a few months now on 3.x and had some issues. For example, the default threadpool size is too small, the default implementation of FastCGI on Mono is super slow (there are alternatives out), and the GC behaves a bit differently (nursery size and collection schedule is different). I did have to learn more about the gritty details than when using .NET on Windows but you can fine tune most things. Things are running pretty smooth now though I am still trying to figure out how to debug from a GDB core dump.
- rossjudson 13y ago
  Did you mix native and managed code?
- Hansi 13y ago
  Any chance of a blog post about the issues is detail? Would be interested in hearing more.

socialist_coder 13y ago

This was my experience as well. Serving c# web apps on linux just sucks. I was using NancyFX, not ServiceStack. I wish I would have tried ServiceStack as well since I think they are probably better.

giulianob 13y ago
What issues were you having?
- socialist_coder 13y ago
  Mostly just a very difficult time figuring out the "right" way to host it on Linux. I could never get it to perform worth a damn after trying a bunch of different hosting methods. I think ServiceStack would probably have solved my issues though.

patja 13y ago

I'm curious if you found some reference sites that had been successful running C# web apps on Mono, and if so what are they?

gabriel 13y ago

I know there are subtle differences in the .net memory model compared to mono. I've fallen victim to this sort of thing before and depending on what you are doing and how aware/disciplined a team is, this could very much be a pain point.

Skinney 13y ago

Sorry to hear that. I was running a mono-based server app for myself for some time. Never ran into any issues but my own. Ran Mono 2.10 on Ubuntu Server.

snarfy 13y ago

It works well enough for the servicestack people.

dawkins 13y ago

I'm sorry to hear that. I have been successfully running a web app on ubuntu/mono for four years now and I'm really happy about the stability and performance. It doesn't use any of the asp.net stack though.

DrJokepu 13y ago

Sadly, we had very similar experiences.

ihnorton 13y ago

Building a huge project on any unknown stack seems ... iffy. Apropos this rant that I recently (re-)read: http://lua-users.org/lists/lua-l/2011-10/msg00825.html http://lua-users.org/lists/lua-l/2011-10/msg00825.html Some other guy read about LuaJIT somewhere, so they give it a try, but obviously don't get a speedup and (of course) blame LuaJIT. They write angry letters to me, I try to politely explain to them that their design leaves something to be desired, they blame the messenger. Then they go and write a post-mortem in a game-centric blog about how bad Lua is, that nobody should ever use scripting for anything and that their next stellar project will use C# with lots of enterprise-ready frameworks. And that they're hiring, because they got nobody with a friggin clue about C#, but management dined with someone from Redmond and they know best, of course.

jnardiello 13y ago
Well, we are very well aware of what you mean. With us the situation was slightly different :) We hired - because our management cares - people who actually knew what they were doing, we got in touch with the person who phisically maintain the app that was running on mono and he re-assured that his software + mono were running smoothly. We have been hacking on it for months, literally. Contributed to the original project in any possible way. But THEN mono started to give strage behaviours. Unless hacking really bad on it, we understood that there was no way to deploy it in production as it could fuck up in any moment and we could do literally nothing unless deleting a file here and there and reboot. So yeah, i'm 100% sure that things could have been done differently - better - yet this was the outcome no matter how many resources we putted on it. We never complained with the creator of the application (yet, we discussed about it with him) and for the very same reason i don't want to name the product as i'm still convinced it is indeed a good piece of software. I'm just saying that with our project, 4+ very skilled people for about 2 months ended up with nothing. Take it or leave it :)
- mikeho1999 13y ago
  Interesting story... but just out of curiosity, if there was already the investment made in the codebase for your application, as well as the team in place to continue with the project and maintain it afterwards, was there a consideration to switch to .NET / Windows Server? If so, I'm curious to hear the reasoning behind abandoning the project altogether and re-writing from scratch (and likely re-interviewing and hiring a different team with different skillsets) as opposed to simply moving the production environment onto Windows...

edwinnathaniel 13y ago

I know there are several desktop apps built using Mono for Linux but I suppose people have their opinions with respect to Mono. My biggest grip with Mono is the lack of automation tools (SCM in this case) and that alone is a show stopper for me. Maven and Eclipse/IntelliJ spoiled me too much that I'd rather not touch Make/Ant/CMake/MSBuild. MSBuild is Microsoft only (despite there may have been some support in Mono, as you have read the article, it's still Microsoft exclusive tool). I'd love to use Mono to develop cross-platform desktop application. I really really really do. In fact, I decided to give it a try one time despite its shortcoming that I mentioned above. In the end, I felt that there's simply too much work for me to build any side project using Mono. This may not be the case for serious commercial desktop app because they can invest more resources to deal with the automation tools. But for side project? Mono would definitely not on top of my list.

BSousa 13y ago
Have you taken a look at FAKE? http://fsharp.github.io/FAKE/ http://fsharp.github.io/FAKE/
- edwinnathaniel 13y ago
  No, I have not. It's great to see a build tool like this but my apology, the syntax is horrifying! :( (I suppose that's a personal taste). I'm really2 spoiled by Maven because of all the things it does for me. FAKE is just like Ant/NAnt/MSBuild so it's not what I'm hoping for. I've worked with Ant before and the build script generally becomes bloated really quick with no standard.

MichaelGG 13y ago

I've been running telecom applications on Mono since 2008, doing up to a billion transactions a week across dozens of servers. After sorting out some minor deployment issues (mainly reading docs or making sure we understood which switches do what)... it just works. We've not had any unstable or unpredictable behavior. Once we've tested and gotten it working, it has stayed working. Only thing we've had problems with I think was the LLVM backend; IIRC some of our F# code didn't work on it. But that was before Mono 3.0 and I am not sure if we checked it since. One set of applications is typical business message processing. Read XML files, deal with SQL Server, Postgres, RabbitMQ. Another one was using the Mono runtime embedded in FreeSWITCH to do stuff to an active SIP call. FreeSWITCH's Mono integration isn't totally unused and I've yet to hear of any stability related bugs.

spo81rty 13y ago

Would it make more sense not to abandon all that work but instead just run the project on Windows??

knocte 13y ago

Saying that mono failed for your project and that you're not going to touch it again is like saying that opensource failed for your project and you're not touching it again. Mono is a project which has a lot of different pieces of technology underneath. Please tell us the part that didn't work for you, because you cannot attribute low quality to the whole project just by testing a small part. (i.e.: was your project a web app or a desktop app? how did you host it? did your team have any Unix expertise or were just a bunch of Windows devs expecting to become Linuxers overnight?) And most importantly, what version of Mono did you use? (Most people that complain end up saying that they just used the mono that their 4 year old distro supplied, which is a version even older than 4 years.)

jnardiello 13y ago
That is not the case. Team with a dedicated Unix devops engineer and a windows dev consultant, all other are skilled unix devs. We have been debugging like beasts and we are probably and realistically one of the best technical teams in the country. We ran everything on Mono 3.0, which we was chosen for specific reasons and weare very aware that is a 1.5yrs old distro. The last specific problem would maybe be sorted upgrading to last release (we don't know) but we already know that new issues would rise as the pattern keeps being the same.
- turnip 13y ago
  "we are probably and realistically one of the best technical teams in the country" yet were unable to debug 2 months worth of new code on a mature platform, that lesser people have no troubles with.
- knocte 13y ago
  You still haven't said the type of the app (web, desktop?), and in case of web, what technology you chose to host it (this is actually the root of many issues that people wanting to host Mono apps face, and it's kind of unrelated to Mono stack).

romanovcode 13y ago

Completely agree. I also recently did a medium-sized project with Mono (website) because I thought that it will be cheaper since service such as digital-ocean is very cheap. Turns out it would be cheaper to just host on Windows Azure because the work of fixing/tweaking things just so it will run properly took way more time (money) than was planned.

kanwisher 13y ago

I have a relatively large project in production that is using a ton of legacy c# code using mono for months ;/ with little issues. Could you maybe explain more about what you saw?