Linked by Thom Holwerda on Wed 4th May 2011 20:41 UTC, submitted by lemur2
SuSE, openSUSE The first major effect of Attachmate buying Novell (and thus, SUSE) has come into, uh, effect. Novell, of course, is the birth place of Mono, the open source implementation of Microsoft's .NET framework. Reports indicate Mono developers have been fired as part of the streamlining process, but according to Attachmate's CEO, they weren't fired because of Mono.
Thread beginning with comment 471954
To view parent comment, click here.
To read all comments associated with this story, please click here.
umccullough
Member since:
2006-01-26

DUnfortunately, Mono is also a non-starter if they can't keep up with Microsoft and release new versions in parallel, as well as guarantee compatibility with the Microsoft implementation of .NET.


Hardly...

Most software these days can be built to .NET Framework 2.0 compatibility. There have only been a few things added since then (and 3.0/3.5 are basically the 2.0 framework with extra assemblies).

.NET Framework 4.0 is required for some of the hot new Silverlight stuff - but unless you need that, Mono can likely still run most of the .NET software out there. Any developer who targets the 4.0 framework needlessly is probably shooting himself in the foot.

Update: Existing compatibility is key, however...

Edited 2011-05-06 00:06 UTC

Reply Parent Score: 3

pantheraleo Member since:
2007-03-07

Hardly... Most software these days can be built to .NET Framework 2.0 compatibility. There have only been a few things added since then (and 3.0/3.5 are basically the 2.0 framework with extra assemblies).


Sure, and some of them are major. LINQ for Entities being an example. To the best of my knowledge, Mono doesn't even have a stable implementation of LINQ for SQL yet (just a preview version), but LINQ for SQL is already deprecated in Microsoft's .NET implementation in favor of LINQ for Entities. I'm pretty sure graphing was also added in 3.5 and probably doesn't work in Mono.

Also, ASP.NET 3.5 added quite a few new advanced AJAX backed controls that presumably may or may not work on Mono.

Also, when a customer signs a million dollar contract for an application with me, any technology that does not have guaranteed compatibility is a non-starter for me. That's why all companies producing their own versions of Java have to have their Java implementation pass the extremely rigorous compatibility test suite before they are allowed to call their product Java. With Mono, however, I really have no guarantees of compatibility with .NET. And that's a non-starter on a million dollar contract.

Also, if we bring desktop apps into the equation, I wouldn't exactly consider WPF to be a minor feature.

Edited 2011-05-06 01:05 UTC

Reply Parent Score: 2

tanishaj Member since:
2010-12-22

You would be hard pressed to find anything on ASP.NET that does not work on Mono. The actual ASP.NET MVC 2 code is even distributed with Mono now. The Razor view engine (MVC 3) is not open source but I am serving ASP.NET (using Razor but do not tell) apps served off both OS X and Linux.

Mono supports .NET 4 applications. Perhaps not every API at this point but it supports everything I have tried.

Mono prioritises development and 100% feature parity with every Microsoft library is not really a goal. If you are developing for Mono it is not a real constraint.

So yes, LINQ-to-SQL was not a priority. Good call it turns out as even Microsoft is dropping it as you say. LINQ itself has been supported forever, including LINQ-to-XML.

Of course, you have been able to use real ORMs like NHibernate for years on Mono. By releasing Entity Framework, Microsoft is just trying to catch up with what is possible using these other solutions so it is really no hardship not to have them. How big a priority should LINQ-to-Entities support be if every Mono developer is already using something else?

So too with Windows Presentation Foundation. Mono supports GTK# as it's core cross-platform GUI solution. There are several large, complex GUI apps using GTK# to support Linux, Mac, and Windows.

It is also the position of the Mono team that quality apps should code the GUI native for each platform. That is why they have MonoTouch for iOS, Mono for Android, and MonoMac for native Cocoa desktop apps. Guess what the native GUI toolkit is for Windows: WPF. Windows Forms is supported cross platform on Mono and some apps do use them. PlasticSCM is a Windows Forms GUI for example.

Not having WPF on Linux is not a big deal for Mono developers. Spending time on WPF is not only not a priority but in fact against the philosophy of the Mono community. Why are you not instead saying that .NET is failing way behind because it does not even support MonoMac GUI apps? It is simply your bias that Mono is nothing but a Microsoft compatibility library.

WCF could be considered another example. The Mono support is way behind Windows. Of course, ServiceStack works just fine. The Mono team did not really pay any attention to WCF until they decided they needed it for Silverlight (Moonlight). It has come along quite nicely since then.

Mono is an extremely capable platform and the core is extremely compatible. Some of the add-on bits do lag but the only people that care are those that want to use nothing but Microsoft tech and then whine about it not being portable. Who cares?

Edited 2011-05-06 03:45 UTC

Reply Parent Score: 2

lemur2 Member since:
2007-02-17

"DUnfortunately, Mono is also a non-starter if they can't keep up with Microsoft and release new versions in parallel, as well as guarantee compatibility with the Microsoft implementation of .NET.
Hardly... Most software these days can be built to .NET Framework 2.0 compatibility. There have only been a few things added since then (and 3.0/3.5 are basically the 2.0 framework with extra assemblies). .NET Framework 4.0 is required for some of the hot new Silverlight stuff - but unless you need that, Mono can likely still run most of the .NET software out there. Any developer who targets the 4.0 framework needlessly is probably shooting himself in the foot. Update: Existing compatibility is key, however... "

Any developer who targets .NET at all is probably shooting himself in the foot. The only platform for which .NET applications can be developed without risk is Windows. All existing Mono applications (for Linux) call components of .NET which lie outside of the ECMA parts, and therefore they lie outside of Microsoft's Community Promise (which only applies to C# and CLI, not to all of .NET).

Any developer who targets multiple platforms should avoid .NET entirely (if you must use C#, use it within the Qt framework, not Mono). Doing so is the only way to put down the footgun.

Edited 2011-05-06 01:10 UTC

Reply Parent Score: 1

Slambert666 Member since:
2008-10-30

Any developer who targets multiple platforms should avoid .NET entirely (if you must use C#, use it within the Qt framework, not Mono). Doing so is the only way to put down the footgun.


I so do not agree with this. Any application that must run on different OS'es must have the UI and interaction designed for each specific OS or risk sucking big time.

While QT is ok on KDE, halfway decent on Windows XP it does not look ok on OSX or modern windows and usually the apps only has good integration with the OS on one single platform.

Mono is targeting a situation where you write a different UI for each OS so that iOS, OSX, Android, Windows, Web, Gnome and KDE each has a separate UI that is tailored for that OS and environment.

Reply Parent Score: 2