# [.net] Differences between .NET and Mono

This topic is 3484 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Disclaimer: I think this is the appropriate place for this thread, but please feel free to move it to the appropriate place. Now, on to the subject. I've been having a discussion on C# with a co-worker for some time now. He likes C/C++ and thinks that C# is pretty much a proprietary Microsoft tool to make everyone conform to their way of programming. I've disproven this where I could by pointing out that C# has an ISO standard and that the Mono project is attempting to create an Open Source VM according to this standard. The one claim that I don't have an answer for is this: "C# is basically designed to work with Visual Studio. In Mono it's a completely different beast due to the fact that you don't have Intellisense or any of the other Visual Studio features that C# pretty much requires." Is this a dumb argument? I mean, the .NET framework and Mono are both implementing something based off the same standard so they should be the same (barring the stuff that is proprietary to Microsoft). At the same time, C# benefits from the features of Visual Studio (like Intellisense) just like any other programming language would. Shouldn't it always be harder to program in a plain text editor than in Visual Studio due to the differences in features, regardless of the language?

##### Share on other sites
It's not really a valid argument. C# isn't tied to any IDE. You can edit your C# code in Visual Studio, and then compile it in Mono. The language is IDE independent, and the IDE can be used to edit the language source files without regard to which platform it is being compiled for.

EDIT: In fact, although I did not know this before, Mono can run binaries produced by Visual Studio. So there is no need to even recompile. Compile and run from Visual Studio, deploy and run on Mono.

Mono FAQ

##### Share on other sites
Quote:
 Original post by savagemonitor"C# is basically designed to work with Visual Studio. In Mono it's a completely different beast due to the fact that you don't have Intellisense or any of the other Visual Studio features that C# pretty much requires."
What the fuck? This is wrong on multiple levels:
* Why on earth would Intellisense be necessary to write C#? Even the forms editor isn't particularly necessary (it's arguably even less necessary in C# than in C++/MFC).
* SharpDevelop supports Mono, and both SharpDevelop and MonoDevelop have Intellisense support and forms designers.

Basically your coworker is an ignorant fool, at best.

##### Share on other sites
There's also the bigger point that Mono is the runtime, not the IDE. "Ignorant fool" is putting it nicely.

##### Share on other sites
Note that MonoDevelop[1], the IDE built by the Mono community supports intellisense. :)

I've been working on a C# project for years that works out of the box on Windows or Mono/Linux or Mono/Windows...

Basically, we have to think about coding for the .NET framework. Mono is stable enough to support almost everything you need.

[1] http://www.monodevelop.com/Main_Page

##### Share on other sites
Let's get some torches and some pitchforks and rid the world of this scoundrel!

##### Share on other sites
Now, Mono does trail behind the Microsoft CLR (the runtime) by a bit, mostly in libraries, but I haven't had much trouble switching my .dll's from CLR to CLR and pretty much everything runs nicely. Actually, my MfGames.* libraries are compiled on Debian and Mono and I just drop them into my Windows library directories.

There are some weak points, System.Windows.Forms is a bit, but its rapidly catching up and some of the more "obscure" namespaces of 3.x haven't been implemented (last I checked) and maybe 1-2 of the 2.0 or 3.5 features (like precompiling ASP.NET sites). They have a program (Momo) that gives you an idea of what is and isn't running.

Of course, I use Emacs instead of one of those fancy IDE's. :P

##### Share on other sites
You can still use the VS IDE to develop. You can even compile your app in windows, and copy the exe/dll's to linux. It runs fine. And right, monodevelop is also pretty good. Specific to game development, the following is mono based

http://unity3d.com/

Second Life also uses it, though more as a scripting engine I think.
http://wiki.secondlife.com/wiki/Mono

Still, You're friend has a valid point. C++ is probably going to be faster..

##### Share on other sites
Also, on the weak library note, I wanted to mention that the network stack on the mono runtime is not as robust as the network stack on the .net framework.

For example a simple udp socket application that I wrote a few months ago did not work on mono.

Also, some simple tcp network errors result in exceptions on the Microsoft framework, and just bring the process down entirely on Mono.

Since networking is a big feature set that doesn't work exceptionally well on Mono, it makes the system unready for prime time for my purpose.

##### Share on other sites
Yeah you don't need VS2008 at all to get all the latest C# functionality. All you need is to download this:

Microsoft .NET Framework 3.5
Brief Description
Microsoft .NET Framework 3.5 contains many new features building incrementally upon .NET Framework 2.0 and 3.0, and includes .NET Framework 2.0 service pack 1 and .NET Framework 3.0 service pack 1.

and do everything from the command line like Petzold always does-LOL!
Visual Studio IDE itself is a proprietary MS tool though of which there is no comparable Linux version although there now is MonoDevelop as has been pointed out.
He does sort of have a point in that Microsoft has the better and more complete implementation compared to Mono but that should come as no suprise as I'm sure they are pouring alot more money into it.
So in theory they should be the same like Java on Windows or Linux, Mac,etc, including GUI stuff but in practice they are not since they are not being written by the same company so Mono is missing or behind in implementing things that are already available on windows!

The Mono project has been tracking some of the improvements available in those releases, some of the highlights of our work so far are:

* Core: mscorlib, System and System.XML assemblies. These support both the 1.x and 2.0 profiles. Work is underway to complete the 2.0 profile.

* ADO.NET: System.Data and various other database providers, they are 1.x complete, and most of 2.x is complete

* ASP.NET 1.x and 2.x: WebForms and Web Services are supported. Only WebParts are missing from our 2.x support.

* System.Security support 1.1 features and has partial support for 2.0 (like XML encryption) but the S.S.C.Pkcs namespace is still imcomplete.

* DirectoryServices implemented on top of Novell.LDAP

* Windows.Forms 1.1 with almost complete 2.0 support.

* System.Drawing supports both 1.x and 2.0 profiles.

* Compilers: C# 1 and 2 as well as bits of 3, VB.NET 8 and various command line tools that are part of the SDK.

* Transaction support, we have some partial support but currently no plans exist beyond the current implementation (see the notes on its implementation and limitations).

* Open Source, Unix and Gnome specific libraries, see our Plans page for more details.

There are certain features that we are not planning on supporting and are available either as stubs (to allow other code to compile or to satisfy dependencies) or are not even present in Mono, these include:

* EnterpriseServices
* Web Services Enhancements (WSE)
* System.Management: too Windows specific
* System.Messaging.

Support for designers in Windows.Forms and ASP.NET for the majority of Mono provided controls does not exist. This is due to the lack of tools for designing Windows.Forms and ASP.NET components in Mono today. When designer surfaces are completed (there are work in progress for both of them) work on this areas will resume.

Designer support is only needed at development-time, this is not something that is required to run the applications on Unix. Many applications that are reported through the Mono Migration Analysis tool reports these problems and can be safely ignored.

Some components exist that were once developed but are no longer actively developed, these include:

Last time I tried running some simple winform games I made using C# on Linux using mono they failed miserably due to missing winforms support but I hear it's gotten better?
So major fail IMO since C# apps and winforms go hand in hand otherwise why even bother?
I have to give them some props though for at least coming out with some tools like this to help people that want to give it a shot:
The Mono Migration Analyzer (MoMA) tool helps you identify issues you may have when porting your .Net application to Mono. It helps pinpoint platform specific calls (P/Invoke) and areas that are not yet supported by the Mono project.

##### Share on other sites
No more than C++ and win32. It does not change much. If you wish to be portable use portable libraries SDL.net, Gtk#, neoaxis . The language C# 2.0 itself is completely compliant to mono.

##### Share on other sites
The only tricky area is P/Invoke, of course. After all, the Win32 API isn't available in Linux (despite occasional attempts to hook WINE and Mono together at some level). Because of this, WinForms works a bit differently on Microsoft.NET (the implementation of WinForms is pretty much MFC for .NET: it's a OO wrapper for Win32) as compared to Mono (which IIRC does all its own UI rendering on every platform rather than mapping to what's available). You'll find a slight speed hit if you use the Mono WinForm assemblies even on Windows, but if you're running Mono on Windows there's nothing keeping you from making use of the Microsoft.NET WinForm libraries.

If you're using any cross-platform, unmanaged libraries, you'll of course need to build those for each platform, as well as separate builds of interop assemblies for each platform due to symbol/linking differences. However, if all your code is managed and encapsulated in the set of assemblies treated as .NET 2.0, it should be build once run anywhere. And as pretty much all cross-platform interop libraries provide the same public interface on each platform, using those shouldn't change that fact.

If you want all the shiny new C# 3.0 language features, then at this time you'll need to use the Microsoft C# compiler as the Mono efforts to bring their compiler up to 3.0 are still ongoing. But that's the only way one would be forced to use Microsoft's tools (especially as all C# 3.0 language features map to the 2.0 framework when you get to the IL code).

##### Share on other sites
Quote:
 Original post by coldacidIf you want all the shiny new C# 3.0 language features, then at this time you'll need to use the Microsoft C# compiler as the Mono efforts to bring their compiler up to 3.0 are still ongoing. But that's the only way one would be forced to use Microsoft's tools (especially as all C# 3.0 language features map to the 2.0 framework when you get to the IL code).
Mono C# supposedly fully supports C# 3.0 as of last week.

##### Share on other sites
Quote:
Original post by mutex
Quote:
 Original post by coldacidIf you want all the shiny new C# 3.0 language features, then at this time you'll need to use the Microsoft C# compiler as the Mono efforts to bring their compiler up to 3.0 are still ongoing. But that's the only way one would be forced to use Microsoft's tools (especially as all C# 3.0 language features map to the 2.0 framework when you get to the IL code).
Mono C# supposedly fully supports C# 3.0 as of last week.

Awesomesuace. Thanks for the tidbit.

##### Share on other sites
Whatever about c#, I don't think .NET is cross platform in any meaningful way.
most commercial .net apps are using 2.0 and mono still hasn't that fully implemented.
Also, I heard that win forms was just a thin wrapper around the win32 api. That's hardly good for a cross platform api.
When someone ports a real application to Mono then I'll take more it seriously. (by real application I mean something complicated like the Multiverse client)

##### Share on other sites
Quote:
 Original post by captainfreedomWhatever about c#, I don't think .NET is cross platform in any meaningful way.most commercial .net apps are using 2.0 and mono still hasn't that fully implemented.Also, I heard that win forms was just a thin wrapper around the win32 api. That's hardly good for a cross platform api.When someone ports a real application to Mono then I'll take more it seriously. (by real application I mean something complicated like the Multiverse client)

Well they did get started on Paint.NET but I don't know how that is going?

##### Share on other sites
Quote:
 Original post by captainfreedomWhatever about c#, I don't think .NET is cross platform in any meaningful way.most commercial .net apps are using 2.0 and mono still hasn't that fully implemented.Also, I heard that win forms was just a thin wrapper around the win32 api. That's hardly good for a cross platform api.When someone ports a real application to Mono then I'll take more it seriously. (by real application I mean something complicated like the Multiverse client)

Unity is a complex tool that lets you build commercial games for Mac, Windows, Wii, iPhone and even embedded into a web-player. It uses Mono for *all* scripting duties, including your game logic -- about 90% of any Unity game's logic will be in script form. In other words: it'll be running as compiled Mono scripts.

Oh yes, I meant that "commercial" bit. People actually use this tool to build games for *sale*, not just as a hobby. Unity is even being used by the likes of Cartoon Network for an up-coming MMO.

So that's real, bona-fide Mono scripts, running in a commercial MMO, on multiple platforms. Today.

Sure, Mono's libraries have a few gaps left to fill, but that's true of any library: they're almost always works in progress. Nevertheless, Mono is very clearly cross platform in perfectly meaningful ways already.

##### Share on other sites
Quote:
 Original post by captainfreedomWhatever about c#, I don't think .NET is cross platform in any meaningful way.

It's too bad that it doesn't matter what you think. The facts of a situation don't change based upon how you feel about them.

Quote:
 most commercial .net apps are using 2.0 and mono still hasn't that fully implemented.

While it's true that most commerical .NET apps use 2.0, the second half of your statement is false. .NET 2.0 is supported by Mono, and even some C# 3.0 features are also implemented. Windows.Forms integration isn't complete, but it's close enough to be usable for the majority of projects.

Quote:
 Also, I heard that win forms was just a thin wrapper around the win32 api. That's hardly good for a cross platform api.

You heard incorrectly. Try doing a bit of research before spouting things off.

Quote:
 When someone ports a real application to Mono then I'll take more it seriously. (by real application I mean something complicated like the Multiverse client)

Here is a small list of some of the successful projects using Mono. Since you said that when somebody ports a real application to Mono you would take it more seriously, are you going to do that now?

##### Share on other sites
Quote:
Original post by Mike.Popoloski

Quote:
 Also, I heard that win forms was just a thin wrapper around the win32 api. That's hardly good for a cross platform api.

You heard incorrectly. Try doing a bit of research before spouting things off.

Oh, okay, here's the reseach you asked for:
http://www.ondotnet.com/pub/a/dotnet/2003/11/24/longhorn_01.htm?page=last&x-maxdepth=0

"Many of the classes in the Framework Class Library are wrappers on top of Win32 functionality. For example, Windows Forms puts a .NET face on classic Win32 features such as HWND, MSG, and WndProc. Likewise, the various classes in System.Net and System.Net.Sockets ultimately wrap the services provided by the Windows Sockets API in Win32. "

but funny, you seem to spout quite a bit yourself

##### Share on other sites
Quote:
Original post by captainfreedom
Quote:
Original post by Mike.Popoloski

Quote:
 Also, I heard that win forms was just a thin wrapper around the win32 api. That's hardly good for a cross platform api.

You heard incorrectly. Try doing a bit of research before spouting things off.

Oh, okay, here's the reseach you asked for:
http://www.ondotnet.com/pub/a/dotnet/2003/11/24/longhorn_01.htm?page=last&x-maxdepth=0

"Many of the classes in the Framework Class Library are wrappers on top of Win32 functionality. For example, Windows Forms puts a .NET face on classic Win32 features such as HWND, MSG, and WndProc. Likewise, the various classes in System.Net and System.Net.Sockets ultimately wrap the services provided by the Windows Sockets API in Win32. "

but funny, you seem to spout quite a bit yourself

Of course, the current implementation of the .NET Windows.Forms namespace (and indeed, many other namespaces in the .NET framework) delegate to Win32 counterparts. However, this does NOT mean that the underlying implementation cannot be rewritten for another OS. That's basically the whole point of having a standardized interface. It makes it easy to swap out the back end. Which is exactly what Mono did. The back end for WinForms in Windows is Win32, yes, but on other platforms other native GUI systems were used.

##### Share on other sites
Quote:
 Original post by captainfreedom"Many of the classes in the Framework Class Library are wrappers on top of Win32 functionality. For example, Windows Forms puts a .NET face on classic Win32 features such as HWND, MSG, and WndProc. Likewise, the various classes in System.Net and System.Net.Sockets ultimately wrap the services provided by the Windows Sockets API in Win32."

You are aware that sockets, networking, and GUI's all exist on other platforms, right? Sure the .NET classes are loosely based on the Windows' incarnations of these basic OS services, but the services themselves are not Windows specific.

##### Share on other sites
Quote:
Original post by captainfreedom
Quote:
Original post by Mike.Popoloski

Quote:
 Also, I heard that win forms was just a thin wrapper around the win32 api. That's hardly good for a cross platform api.

You heard incorrectly. Try doing a bit of research before spouting things off.

Oh, okay, here's the reseach you asked for:
http://www.ondotnet.com/pub/a/dotnet/2003/11/24/longhorn_01.htm?page=last&x-maxdepth=0

"Many of the classes in the Framework Class Library are wrappers on top of Win32 functionality. For example, Windows Forms puts a .NET face on classic Win32 features such as HWND, MSG, and WndProc. Likewise, the various classes in System.Net and System.Net.Sockets ultimately wrap the services provided by the Windows Sockets API in Win32. "

but funny, you seem to spout quite a bit yourself

.NET is implemented using Win32 calls.

Mono is implemented using Posix calls.

The Mono implementation of Windows.Forms calls into X11 on Linux and into Quartz on MacOS and Win32 on Windows. Mono even provides HWND, MSG and WndProc across all platforms.

The same for System.Net, we just call Posix APIs instead of calling Win32 APIs. I know this might come to a shock to you, but these are pretty simple programming techniques.

##### Share on other sites
Quote:
 Original post by captainfreedomOh, okay, here's the reseach you asked for: http://www.ondotnet.com/pub/a/dotnet/2003/11/24/longhorn_01.htm?page=last&x-maxdepth=0"Many of the classes in the Framework Class Library are wrappers on top of Win32 functionality. For example, Windows Forms puts a .NET face on classic Win32 features such as HWND, MSG, and WndProc. Likewise, the various classes in System.Net and System.Net.Sockets ultimately wrap the services provided by the Windows Sockets API in Win32. "but funny, you seem to spout quite a bit yourself
To bring the conversation back to the original question: C# is the language; it is a standard. .NET is the runtime; it is not a standard. Windows.Forms as the namespace for the items in dispute should tell an informed reader that the namespace is proprietary, much as anything inside the Microsoft.* namespaces.

If you are holding C#/.NET to the standards you claim to be, I dare you to find me a C++ application of any [substantial] size which has been written to function across all platforms and which does not use #ifdefine's to achieve it's "platform neutrality."

Hell, you'll be lucky to find an application that compiles cleanly on both Win32 and *nix platforms.

Edit: Added substantial to size. ;) (A :P to bubu LV, hehe.)

[Edited by - Talonius on August 4, 2008 3:29:13 PM]

##### Share on other sites
Quote:
 Original post by Taloniusfind me a C++ application of any size which has been written to function across all platforms and which does not use #ifdefine's to achieve it's "platform neutrality."
Here you go:

#include <iostream>int main(){    std::cout << "Hello, World!" << std::endl;}

:)

(sorry for offtopic)

##### Share on other sites
Quote:
Original post by bubu LV
Quote:
 Original post by Taloniusfind me a C++ application of any size which has been written to function across all platforms and which does not use #ifdefine's to achieve it's "platform neutrality."
Here you go:

*** Source Snippet Removed ***
:)

(sorry for offtopic)

The C++ "Input/output library" as defined by the C++ standard of which iostreams are a part of are not part of the set of libraries guaranteed to be available on a freestanding implementation of the C++ language as listed in ¶17.4.1.3.

Quote:
 From ¶1.4.7 of ISO/IEC 14882:2003A freestanding implementation is one in which execution may take place without the benefit of an operating system, and has an implementation-defined set of libraries that includes certain language-support libraries (17.4.1.3)

As such, your rendition of hello world lacks platform neutrality WRT handhelds, or even consoles.