tags:

views:

591

answers:

7

I'm looking into Mono and .NET C#, we'll be needing to run the code on Linux Servers in the future when the project is developed. At this point I've been looking at ASP.NET MVC and Mono I run an ubuntu distro and want to do development for a web application, some of the other developers use windows and run other .NET items with Visual Studio.

What does Mono not provide that Visual Studio does?

If running this on Linux later shouldn't we use Mono Develop ?

Is there some third party tools or addin's that might be an issue with Mono later?

+1  A: 

You're aiming to always have support, and/or primarily use the software on Linux, correct? This is actually a question I asked the Mono developers at a conference a little while back, and it basically boiled down to what you want to do with it.

If you want it to always work on Linux, then use Mono. If you only care about Windows, then use Visual Studio.

If you're using Mono, then use MonoDevelop across all developers. It'll just make life a lot easier later on, and it'll make sure that whatever you write in the one will work for everyone.

Unfortunately, I do not know the answer to the exact limits/advantages of Mono vs. .NET, aside from .NET being further ahead, and Mono playing catch-up, nor about different addons.

Slokun
+1  A: 

I don't have much experience in this area but...

The Mono Project Roadmap has an overview of features that are new, upcoming, and not present in Mono compared to MS.NET. Even where Mono has the same classes as .NET, note that compatibility is not 100% (although that is generally their goal). I'm not sure if there exists a comprehensive list of things missing in Mono.

MonoDevelop is now available on both Windows and Linux so you're probably best off using it. However, MonoDevelop does appear to use the same project file format as Visual Studio and SharpDevelop, so you could make an attempt at mixing IDEs.

Of course, when using 3rd-party .NET libraries, note that many of them have not been tested with mono, and in particular anything that uses P/Invoke will not work on Mono for Linux. However, most incompatibilities with mono are minor, and if you stick with open-source libraries you can always fix any incompatibilities you run into.

Qwertie
+4  A: 

You might also take a look at Mono Tools for Visual Studio. It lets your visual studio developers target and test with the mono platform.

Joel Coehoorn
+1  A: 

If you can help it, it'd recommend avoiding the Mono implementation of Remoting. There seem to be some unexpected hiccups and debugging it is not straight-forward.

We had a very Remoting heavy product that we tried to port to Mono so we could support Linux. Due to being unable to resolve the Remoting issues, we eventually had to abandon our attempts at supporting Linux altogether.

Caveat: my experiences may be outdated. See comments below

Dinah
Ok this is exactly what kind of answers I was looking for, real experiences in what Mono is having problems with.
jason
How long ago was that by chance? I am curios if it has been fixed since, that is if it was a few years ago.
percent20
@percent20: 1-2 years ago. If you find my experiences to be outdated, please comment here and I'll update my answer.
Dinah
I concur, there are manny hiccups, esp. prior to Mono 2.4. Before, in order to transport DateTime in Remoting, you have to cast it to string(preferably yyyymmdd), then cast it back in Remoting to DateTime. But those are solved now. Though recently I encountered another bug in Mono 2.4, it can transport any type(string,datetime,decimal,etc) in DefaultValue on datatable.Columns, except Guid. The work-around I do is I just put the Guid default value in another DataTable, representing it as DataRow; then on front-end side, just assign the DefaultValue from that another DataTable
Michael Buen
I run my Remoting and ASP.NET program in Mono and Ubuntu since 2006. Important thing is, test early and often so you can pinpoint exactly where the exact error occured and make necessary adjustments
Michael Buen
A: 

If none of your developers need to develop on Mono for certain features, I suggest you all use Visual Studio on Windows. Then test the applications on Mono via

  1. Mono Tools for Visual Studio
  2. manually copy the binaries over
  3. check out the code on Linux and build in MonoDevelop.

Personally I experienced a lot of small troubles when I tried out the third way, but luckily I am capable of finding workarounds.

It is only when you touch Mono, you know which part of your application needs to be tuned.

http://www.mono-project.com/Start

Lex Li
A: 

You don't need MonoDevelop in order to run ASP.NET program in Linux, make a shared folder on your development server (VMWare'd or real one), test often so you can easily work-around what's missing from Mono

That's the same approach I'm using in my .NET Remoting program I host on Ubuntu server. But I do the reverse, since I'm a solo programmer, I make a shared folder on my Windows development machine, then access that shared folder on my Ubuntu test server (vmware'd). On ASP.NET stuff, if the changes don't reflect on your Ubuntu test server, in Terminal just touch the Web.Config file in your Ubuntu test server. i.e. touch Web.Config, then refresh the page

Michael Buen
+1  A: 

What does Mono not provide that Visual Studio does?

MonoDevelop is presumbly what you mean here. MonoDevelop offers cross platform development on Linux, Mac OS X, Windows based on GTK. However it is not as polished as Visual Studio for obvious reasons - it's 3 people making it, not hundreds. It has some nice features, especially its source control plugin architecture. However as Visual Studio Express is free there aren't many advantages on Windows to using it.

It uses the same .csproj and .sln format as Visual Studio, however the Xml docs format is different.

If running this on Linux later shouldn't we use Mono Develop ?

As I mentioned above, the project formats are interoperable.

Is there some third party tools or addin's that might be an issue with Mono later?

Unlike Visual Studio, there aren't a huge wealth of addins for Monodevelop. The ones that you use in Monodevelop won't effect your .csproj files at all, as anything Visual Studio cannot read it generally ignores.


As people have said don't confuse Mono for MonoDevelop. MonoDevelop is an IDE for Mono that originally came from (forked) SharpDevelop.

Mono is the cross platform framework that 'apes' the Microsoft CLR and framework libraries.

Chris S