7 ms·

Mono 2.8 has been released

92 points by icey 16y ago

j_baker 16y ago
I'm glad to finally be able to use C# 4.0 and dynamic types in Mono. That's a huge improvement!
arst 16y ago
Funny coincidence that Mono and LLVM both had 2.8 releases on the same day, and one of Mono 2.8's new features is a stable LLVM backend.
mahmud 16y ago
Any mono users here also familiar with .net? how compatible are they? What works and what doesn't? What sort of applications is mono best suited for (server backend? desktop? mobile? web front end? systems programming?) Would be nice to dish and get real insider info.
- kevingadd 16y ago
  I've used Mono to run some of my C# server applications on a linux box. I basically copied over the exe/dll files, ran it, and it worked. In a few cases I had to fix some platform-specific things (like hard-coding the directory separator), but all the core, standard APIs worked exactly like they did on windows. In most cases I was actually able to compile my applications from source using Mono's build tools without any modification, despite the fact that I authored them in Visual Studio so I didn't have a makefile (Mono provides a handy tool that reads VS project files). The biggest question mark is in terms of behavior and performance - it's possible that you could end up with a pure .NET application that happens to depend on a quirk in the Windows thread scheduler, or use a feature that happens to perform really badly on Linux due to API constraints (asynchronous IO in .NET is a good example of this; it's designed around Windows' IO Completion Port mechanism and there isn't a good analogue on Linux). For desktop/mobile .NET applications, it's going to be more difficult to run them on Mono since they probably rely on APIs that aren't part of the core .NET standards, like Windows Forms. Mono has implementations of some of those APIs, but they aren't complete, so those apps are going to be less likely to work without modification. A lot of desktop .NET applications also call directly into Win32 for whatever reason, so that won't work on Linux. To help address this problem, the Mono guys provide a tool that can scan .NET applications for uses of APIs/techniques that don't work in Mono, and lists out the problems for you so that you can fix them. Anyway, from my perspective, your best bet with Mono is server and mobile applications. Server, because you have two relatively solid server stacks to choose from (Microsoft .NET + ASP.net and Mono .NET + ASP.net) and you can develop in Visual Studio or MonoDevelop while running your deployed code on commodity hardware. However, it's worth pointing out that the Microsoft garbage collector is still a bit more mature than mono's so you might face challenges getting high performance out of your apps on Linux, since your ASP.net processes will be long-lived. Mobile, because Microsoft goes out of their way to make .NET development on their mobile platforms relatively accessible, and the Mono team has made great efforts to let people build native-feeling Android and iPhone apps in C#. In both cases you won't be able to write-once-run-anywhere, but you'll be able to write your core application logic once in C# and then do mobile platform specific UI development in C# as well.
  - mahmud 16y ago
    That was excellent Kevin, I thank you much. Also: you have two relatively solid server stacks to choose from (Microsoft .NET + ASP.net and Mono .NET + ASP.net) I know what you meant though :-)
  - SeveredCross 16y ago
    Great summary post, but I want to add one thing—Mono just got a new garbage collector with the 2.8 release called SGen. SGen is a generational garbage collector with nurseries, a cardtable-based write barrier, a parallel mark and sweep collector (which is not enabled by default right now, but there are instructions on how to enable it). SGen should show better performance on GC-heavy workloads, a fact demonstrated by the SGen part of http://www.mono-project.com/Release_Notes_Mono_2.8 http://www.mono-project.com/Release_Notes_Mono_2.8. Also, the LLVM backend can be used for yet-another-JITter, though the garbage collector I think remains SGen/Boehm (not sure on this).
- icey 16y ago
  Here is the "official" compatibility chart: http://www.mono-project.com/Compatibility http://www.mono-project.com/Compatibility The chart is based on 2.6, the stuff that was added today falls under the "Current Mono Trunk" section. I'm not sure if the DLR (dynamic language runtime) is fully functional on Mono yet. The DLR is what's used to make IronPython and IronRuby run on the .Net stack. It's embedded into Silverlight, which allows developers to run Python and Ruby in the browser (assuming their users have the Silverlight plugin). Mono has Moonlight, but again, I'm not sure if the DLR is in there. I personally see C# as an evolutionary next step from Java. That being said, languages like Scala, Clojure, JRuby (which I guess is technically a language implementation) let you get the benefits of Java without all the sucky language parts. C# is a solid server-side language. I'm not terribly impressed with it for the web, although MVC makes it much better than it used to be (blah, webforms). There's an interesting project that was posted here recently called "Manos de Mono" that offers some variety in the web space [1] It's also turned out to be a pretty decent mobile development language. You can develop iPhone and Android apps using Mono [2][3], as well as cross-platform games [4][5]. You can use Mono in client-side applications, but I'm not sure how well it works or everything that's involved with using it that way. One of the nice things about Mono is that it lets you write C# on Unix and Unix-like platforms. For those of us that use C# during the day, it's liberating to be able to use the same language on our Macs at home, or deployed on Linux servers next to our other software. [1] http://github.com/jacksonh/manos http://github.com/jacksonh/manos [2] http://monotouch.net/ http://monotouch.net/ [3] http://monodroid.net/ http://monodroid.net/ [4] http://code.google.com/p/monoxna/ http://code.google.com/p/monoxna/ [5] http://unity3d.com/ http://unity3d.com/
  - peregrine 16y ago
    I agree with your statements about webforms(double blah), I've been working on a fairly signifigant MVC2 project at work and its far better then doing the same in webforms. Microsoft is truly trying to get back into the web game and make it 'cool' to be a web dev on the M$ stack. That said the community is still lacking. Their are plenty of motivated passionate people but they very often feel like their are just doing it to get a book deal or speaking gigs and not because they care. Oh well.
  - 16y ago
- mcculley 16y ago
  We are a predominantly Unix/Linux shop that has taken over a .NET project. We are doing builds with Hudson and Mono for a web application that gets deployed to IIS. Overall, everything works but there have been a few surprises. One surprise was that debugging is hard because Mono uses a different format for debugging symbols. This means we get tracebacks with no line numbers. The second surprise is that we have to munge resulting executables with corflags.exe to force them to run in 32-bit mode on 64-bit boxes where there are library dependencies that keep them from being 64-bit clean. We are trying to develop using MonoDevelop but there are some weird incompatibilities with the SQL Server client library. These are not insurmountable, but it has been a hassle. The other hassle is that MonoDevelop is terribly slow. It does not appear to be able to do incremental compiles so any change to the project results in a recompile of the entire project.
  - audidude 16y ago
    Use pdb2mdb to convert your symbols from the .net to mono format. Place the .mdb's alongside your dll/exe. Then you will get files and line numbers.
    - mcculley 16y ago
      I can't. I have the reverse problem. I am building on Mono and deploying to IIS.
  - sandGorgon 16y ago
    how is the performance of Mono/ASP.net vs stacks like RoR, PHP, etc. on Linux ?
    - mcculley 16y ago
      I haven't done any benchmarking and I don't use RoR or PHP much, but as a data point, the Mono stuff running under Apache seems slower than similar Java code running under Tomcat.
    - migueldeicaza 16y ago
      Mono's ASP.NET or MVC or Manos are all running natively compiled code, so for equivalent tasks they should all be faster than interpreted languages. Whether this matters or not will depend on the what your application is doing and how many users you have. For example, if your application is database bound or file system bound you wont likely notice much of a difference as the time you spend running CIL code or interpreted code is a small portion of your overall CPU consumption. With Mono 2.8 we significantly improved Mono's web server scalability, but this will not matter if your application does not use or require more than a handful of CPUs. But is incredibly useful for people that are scaling servers under load.
- dawkins 16y ago
  I switched from .Net to Mono/linux for a web application and almost everything worked right away. Most of the differences I found where because of Linux: case sensitive file names and file encodings with non ascii characters.
- barrettcolin 16y ago
  There are quirks here and there; I use mono through unity3d, so that informs the things I notice. Specifically interop with unmanaged DLLs is: well, more guesswork than I would like. For instance, Marshal.PtrToStringAnsi (function that creates a .NET string from an unmanaged char* pointer) expects UTF-8 data; best of luck deducing that from the name of the function or the documentation.
  - barrkel 16y ago
    Ansi strings in Windows are encoded using the current codepage, which is an OS-level setting depending on the localization settings. Most of the time, in the Western world, it's Windows-1252 Western European / Latin-1. It indicates how string arguments to the Ansi versions of WinAPI functions will be interpreted (ending in A rather than W). This is the way things have been done on Windows for ages, so I don't think the concept is particularly foreign to people expert enough to need interop with native libraries. The Mono documentation[1] indicates that Mono uses UTF-8 for all string marhsalling operations, which seems pretty unambiguously documented. It's as if GetACP() returned CP_UTF8. [1] http://www.mono-project.com/Interop_with_Native_Libraries http://www.mono-project.com/Interop_with_Native_Libraries
    - barrettcolin 16y ago
      Right, understood. My particular beef was that the function to create a managed Mono string from a UTF-8 encoded unmanaged string was Marshal.PtrToStringAnsi (which is even more confusing if you are familiar with the Windows string encoding heritage: how should the data be encoded in Mono on Windows? Still as UTF-8, I think counter-intuitively, and differently to Microsoft's own runtime, which will of course expect ANSI). Let me also get a dig in at the documentation of the function: http://www.go-mono.com/docs/index.aspx?link=M:System.Runtime.InteropServices.Marshal.PtrToStringAnsi http://www.go-mono.com/docs/index.aspx?link=M:System.Runtime...
      - migueldeicaza 16y ago
        The problem is simple, this is a design mistake in .NET's API. They designed the Marshal class to suit Windows and Windows only and they only had two choices UCS2/UTF16 encoding which they call "Unicode" and current code page which they call "ANSI". Adding a new API say PtrFromUtf8 would mean that the code would not run on Windows because all of a sudden we are referencing a method that does not exist on .NET. So we took the approach of turning "current code page" in Unix to what made sense on Unix: it is UTF8. In fact, the particular issue of UTF-8 encoding is the oldest bug opened against Mono, not something that we can fix without breaking binary compatibility. At this point, we value more staying binary compatible with the core libraries than breaking compatibility with the .NET toolchain. We try to extend Mono in /new/ libraries like Mono.Simd or Mono.Unix where we have complete reign over the API and can still let them run on Windows with the native .NET toolchain.
sshconnection 16y ago
Is there a packaged build of MoMa for 2.8 available? I couldn't get our code base working in 2.6 due to a few compatibility issues, but a quick once over the compatibility page looks like those issues may be resolved. Here's looking forward to testing a lot of cross platform code!
deleted 16y ago
[deleted]

92 points by icey 16y ago

I'm glad to finally be able to use C# 4.0 and dynamic types in Mono. That's a huge improvement!

arst 16y ago

Funny coincidence that Mono and LLVM both had 2.8 releases on the same day, and one of Mono 2.8's new features is a stable LLVM backend.

mahmud 16y ago

Any mono users here also familiar with .net? how compatible are they? What works and what doesn't? What sort of applications is mono best suited for (server backend? desktop? mobile? web front end? systems programming?) Would be nice to dish and get real insider info.

kevingadd 16y ago
I've used Mono to run some of my C# server applications on a linux box. I basically copied over the exe/dll files, ran it, and it worked. In a few cases I had to fix some platform-specific things (like hard-coding the directory separator), but all the core, standard APIs worked exactly like they did on windows. In most cases I was actually able to compile my applications from source using Mono's build tools without any modification, despite the fact that I authored them in Visual Studio so I didn't have a makefile (Mono provides a handy tool that reads VS project files). The biggest question mark is in terms of behavior and performance - it's possible that you could end up with a pure .NET application that happens to depend on a quirk in the Windows thread scheduler, or use a feature that happens to perform really badly on Linux due to API constraints (asynchronous IO in .NET is a good example of this; it's designed around Windows' IO Completion Port mechanism and there isn't a good analogue on Linux). For desktop/mobile .NET applications, it's going to be more difficult to run them on Mono since they probably rely on APIs that aren't part of the core .NET standards, like Windows Forms. Mono has implementations of some of those APIs, but they aren't complete, so those apps are going to be less likely to work without modification. A lot of desktop .NET applications also call directly into Win32 for whatever reason, so that won't work on Linux. To help address this problem, the Mono guys provide a tool that can scan .NET applications for uses of APIs/techniques that don't work in Mono, and lists out the problems for you so that you can fix them. Anyway, from my perspective, your best bet with Mono is server and mobile applications. Server, because you have two relatively solid server stacks to choose from (Microsoft .NET + ASP.net and Mono .NET + ASP.net) and you can develop in Visual Studio or MonoDevelop while running your deployed code on commodity hardware. However, it's worth pointing out that the Microsoft garbage collector is still a bit more mature than mono's so you might face challenges getting high performance out of your apps on Linux, since your ASP.net processes will be long-lived. Mobile, because Microsoft goes out of their way to make .NET development on their mobile platforms relatively accessible, and the Mono team has made great efforts to let people build native-feeling Android and iPhone apps in C#. In both cases you won't be able to write-once-run-anywhere, but you'll be able to write your core application logic once in C# and then do mobile platform specific UI development in C# as well.
- mahmud 16y ago
  That was excellent Kevin, I thank you much. Also: you have two relatively solid server stacks to choose from (Microsoft .NET + ASP.net and Mono .NET + ASP.net) I know what you meant though :-)
- SeveredCross 16y ago
  Great summary post, but I want to add one thing—Mono just got a new garbage collector with the 2.8 release called SGen. SGen is a generational garbage collector with nurseries, a cardtable-based write barrier, a parallel mark and sweep collector (which is not enabled by default right now, but there are instructions on how to enable it). SGen should show better performance on GC-heavy workloads, a fact demonstrated by the SGen part of http://www.mono-project.com/Release_Notes_Mono_2.8 http://www.mono-project.com/Release_Notes_Mono_2.8. Also, the LLVM backend can be used for yet-another-JITter, though the garbage collector I think remains SGen/Boehm (not sure on this).
icey 16y ago
Here is the "official" compatibility chart: http://www.mono-project.com/Compatibility http://www.mono-project.com/Compatibility The chart is based on 2.6, the stuff that was added today falls under the "Current Mono Trunk" section. I'm not sure if the DLR (dynamic language runtime) is fully functional on Mono yet. The DLR is what's used to make IronPython and IronRuby run on the .Net stack. It's embedded into Silverlight, which allows developers to run Python and Ruby in the browser (assuming their users have the Silverlight plugin). Mono has Moonlight, but again, I'm not sure if the DLR is in there. I personally see C# as an evolutionary next step from Java. That being said, languages like Scala, Clojure, JRuby (which I guess is technically a language implementation) let you get the benefits of Java without all the sucky language parts. C# is a solid server-side language. I'm not terribly impressed with it for the web, although MVC makes it much better than it used to be (blah, webforms). There's an interesting project that was posted here recently called "Manos de Mono" that offers some variety in the web space [1] It's also turned out to be a pretty decent mobile development language. You can develop iPhone and Android apps using Mono [2][3], as well as cross-platform games [4][5]. You can use Mono in client-side applications, but I'm not sure how well it works or everything that's involved with using it that way. One of the nice things about Mono is that it lets you write C# on Unix and Unix-like platforms. For those of us that use C# during the day, it's liberating to be able to use the same language on our Macs at home, or deployed on Linux servers next to our other software. [1] http://github.com/jacksonh/manos http://github.com/jacksonh/manos [2] http://monotouch.net/ http://monotouch.net/ [3] http://monodroid.net/ http://monodroid.net/ [4] http://code.google.com/p/monoxna/ http://code.google.com/p/monoxna/ [5] http://unity3d.com/ http://unity3d.com/
- peregrine 16y ago
  I agree with your statements about webforms(double blah), I've been working on a fairly signifigant MVC2 project at work and its far better then doing the same in webforms. Microsoft is truly trying to get back into the web game and make it 'cool' to be a web dev on the M$ stack. That said the community is still lacking. Their are plenty of motivated passionate people but they very often feel like their are just doing it to get a book deal or speaking gigs and not because they care. Oh well.
- 16y ago
mcculley 16y ago
We are a predominantly Unix/Linux shop that has taken over a .NET project. We are doing builds with Hudson and Mono for a web application that gets deployed to IIS. Overall, everything works but there have been a few surprises. One surprise was that debugging is hard because Mono uses a different format for debugging symbols. This means we get tracebacks with no line numbers. The second surprise is that we have to munge resulting executables with corflags.exe to force them to run in 32-bit mode on 64-bit boxes where there are library dependencies that keep them from being 64-bit clean. We are trying to develop using MonoDevelop but there are some weird incompatibilities with the SQL Server client library. These are not insurmountable, but it has been a hassle. The other hassle is that MonoDevelop is terribly slow. It does not appear to be able to do incremental compiles so any change to the project results in a recompile of the entire project.
- audidude 16y ago
  Use pdb2mdb to convert your symbols from the .net to mono format. Place the .mdb's alongside your dll/exe. Then you will get files and line numbers.
  - mcculley 16y ago
    I can't. I have the reverse problem. I am building on Mono and deploying to IIS.
- sandGorgon 16y ago
  how is the performance of Mono/ASP.net vs stacks like RoR, PHP, etc. on Linux ?
  - mcculley 16y ago
    I haven't done any benchmarking and I don't use RoR or PHP much, but as a data point, the Mono stuff running under Apache seems slower than similar Java code running under Tomcat.
  - migueldeicaza 16y ago
    Mono's ASP.NET or MVC or Manos are all running natively compiled code, so for equivalent tasks they should all be faster than interpreted languages. Whether this matters or not will depend on the what your application is doing and how many users you have. For example, if your application is database bound or file system bound you wont likely notice much of a difference as the time you spend running CIL code or interpreted code is a small portion of your overall CPU consumption. With Mono 2.8 we significantly improved Mono's web server scalability, but this will not matter if your application does not use or require more than a handful of CPUs. But is incredibly useful for people that are scaling servers under load.
dawkins 16y ago
I switched from .Net to Mono/linux for a web application and almost everything worked right away. Most of the differences I found where because of Linux: case sensitive file names and file encodings with non ascii characters.
barrettcolin 16y ago
There are quirks here and there; I use mono through unity3d, so that informs the things I notice. Specifically interop with unmanaged DLLs is: well, more guesswork than I would like. For instance, Marshal.PtrToStringAnsi (function that creates a .NET string from an unmanaged char* pointer) expects UTF-8 data; best of luck deducing that from the name of the function or the documentation.
- barrkel 16y ago
  Ansi strings in Windows are encoded using the current codepage, which is an OS-level setting depending on the localization settings. Most of the time, in the Western world, it's Windows-1252 Western European / Latin-1. It indicates how string arguments to the Ansi versions of WinAPI functions will be interpreted (ending in A rather than W). This is the way things have been done on Windows for ages, so I don't think the concept is particularly foreign to people expert enough to need interop with native libraries. The Mono documentation[1] indicates that Mono uses UTF-8 for all string marhsalling operations, which seems pretty unambiguously documented. It's as if GetACP() returned CP_UTF8. [1] http://www.mono-project.com/Interop_with_Native_Libraries http://www.mono-project.com/Interop_with_Native_Libraries
  - barrettcolin 16y ago
    Right, understood. My particular beef was that the function to create a managed Mono string from a UTF-8 encoded unmanaged string was Marshal.PtrToStringAnsi (which is even more confusing if you are familiar with the Windows string encoding heritage: how should the data be encoded in Mono on Windows? Still as UTF-8, I think counter-intuitively, and differently to Microsoft's own runtime, which will of course expect ANSI). Let me also get a dig in at the documentation of the function: http://www.go-mono.com/docs/index.aspx?link=M:System.Runtime.InteropServices.Marshal.PtrToStringAnsi http://www.go-mono.com/docs/index.aspx?link=M:System.Runtime...
    - migueldeicaza 16y ago
      The problem is simple, this is a design mistake in .NET's API. They designed the Marshal class to suit Windows and Windows only and they only had two choices UCS2/UTF16 encoding which they call "Unicode" and current code page which they call "ANSI". Adding a new API say PtrFromUtf8 would mean that the code would not run on Windows because all of a sudden we are referencing a method that does not exist on .NET. So we took the approach of turning "current code page" in Unix to what made sense on Unix: it is UTF8. In fact, the particular issue of UTF-8 encoding is the oldest bug opened against Mono, not something that we can fix without breaking binary compatibility. At this point, we value more staying binary compatible with the core libraries than breaking compatibility with the .NET toolchain. We try to extend Mono in /new/ libraries like Mono.Simd or Mono.Unix where we have complete reign over the API and can still let them run on Windows with the native .NET toolchain.

sshconnection 16y ago

Is there a packaged build of MoMa for 2.8 available? I couldn't get our code base working in 2.6 due to a few compatibility issues, but a quick once over the compatibility page looks like those issues may be resolved. Here's looking forward to testing a lot of cross platform code!

deleted 16y ago

[deleted]