Developing a Web App with Mono (Opensource .Net) Any Examples

can any ASP.net app (or most of them) be made to run under Linux using Mono?

The answer to 'can any (or most of) the ASP.NET apps be made to run' is YES. There's a page with some common pitfalls: Mono: Porting ASP.NET Applications (also of interest the Porting WinForms applications page)

The most common problems I've seen in the field[1] are, by number of occurrences:

Code that is not aware of case-sensitive filesystems or careless about file/path handling. These ones require work.
P/Invokes: there are a lot of P/Invokes to Windows native functions. Most of them are not supported in Mono (nor they make sense in a unix environment). However, we have mappings for a few or the most common ones (CloseHandle and such). These ones require redoing the same things using a .NET API.
Bugs: believe or not, there are still bugs in the 3M+ lines of code. We try to be responsive and fix bugs as soon as possible (and we'd love to do more, blame it on the 24h rotation period). The simpler the test case to reproduce the problem, the faster it gets fixed. File a bug report and we'll try to fix it ASAP.
Missing or unimplemented APIs: we still have these and try to focus on the most used ones. Some times we use the Moma Reports (see link below) to prioritize.

Take a look at the Moma Reports page, which contains user-submitted data about applications on which Moma has been run.

[1]: the field ranges from one of the largest ASP.NET deployments in the Western Hemisphere to small open source applicatoins.

.NET 5 and Mono

I would answer the question this way...

The .NET Framework was written by Microsoft and they have released many versions of it ( currently at 4.8 ).

There are lots of ways to think about the .NET technology stack but, for this post, .NET contains the following components:

A compiler suite ( C#, F#, VisualBasic .NET )
the Base Class Libraries ( BCL )
the runtime ( the bits needed to execute the compiled CIL )

The Mono project was created to implement a fully Open Source .NET Framework clone.

Initially, Mono implemented all of the above itself. For example, there is a Mono native C# compiler ( mcs ), a Mono implementation of ASP.NET, and even a Mono implementation of Windows Forms. Over time, Microsoft began releasing stuff as Open Source. Mono began incorporating this and so Microsoft .NET and Mono started to share a lot of code in common ( eg. the Roslyn C# and VB.NET compilers, ASP.NET MVC and the DLR ). Even some of the BCL code was opened up and shared between Mono and .NET. Not the runtime though.

Some of the contributors to the Mono Project formed a company, Xamarin, with the goal of using Mono to create applications for mobile operating systems like iOS and Android. They enhanced and re-used the Mono runtime ( adding a sophisticated Ahead-of-Time compiler for example ). They also re-used the Mono BCL although some parts of the BCL could not be used and new APIs were added for platform specific elements, especially GUI stuff. A "cross-platform" mobile GUI API was created as well ( called Xamarin Forms ). So while Microsoft .NET remained Windows only, Mono could be used to create applications for Mac, Linux, Windows, iOS, Android, and others.

More recently, Microsoft created their own parallel re-imagining of the .NET ecosystem. They called this new version .NET Core. Like Mono, .NET Core was Open Source and multi-platform. To differentiate the two Microsoft implementations, the original .NET was re-named to .NET Full Framework or just .NET Framework. While .NET Framework continues to be Windows only, .NET Core allows applications to run on Windows, MacOS, and Linux.

.NET Core shares a lot with .NET Full Framework. Like Mono, .NET core uses the Roslyn compiler suite for example. The BCL however was new ( partially incompatible with .NET Full Framework ). The runtime was totally new ( using RyuJIT for example ).

.NET Core did not "replace" .NET Full Framework. For example, Windows Forms and Windows Presentation Foundation ( WPF ) applications cannot be created with .NET Core.

The Mono Project ( eg. the most recent 6.12 release ) remains a clone of .NET Full Framework and, even where it has taken code from .NET Core, the goal remains .NET Framework compatibility.

So .NET found itself with multiple implementations: .NET Framework, .NET Core, Mono, and Xamarin. All of these versions were very similar but incompatible to some degree. Microsoft tried to address this by creating the idea of ".NET Standard" with the aim of specifying a shared subset of features that could be expected to execute on any of the above .NET versions.

In fact, there is kind of another branch of .NET now in that Microsoft created something called Blazor which compiles .NET applications to web assembly ( WASM ). Blazor uses the Mono / Xamarin runtime.

As another level of confusion, the .NET Core initiative produced some bits that can run on either .NET Core or .NET Full Framework. For example, ASP.NET Core is a re-imagining of ASP.NET MVC. ASP.NET Core is the only version of ASP.NET on .NET Core but both Mono and .NET Framework developers can choose from ASP.NET Web Forms, ASP.NET MVC, or ASP.NET Core. Outside of ASP.NET Core itself though, the BCL between .NET Core and .NET Framework is different and so it is quite possible to create an ASP.NET Core application that will not run on .NET Core. There is also Entity Framework Core with a similar story.

All and all, while a fantastic bucket of tech, the jumble of versions and what works with what has become a complete mess.

.NET 5 and .NET 6 (note the drop of the term "Core" in the name) are an attempt to unify and massively simplify all of the above.

By most meaningful measures, .NET 5 is a continuation of .NET Core and you could think of .NET 5 as the most recent .NET Core release. Unlike .NET Core though, it is not considered an "alternative" implementation to .NET Full Framework. Rather, it is the future for both .NET Core and .NET Full Framework. There will not be another .NET Core ( by name ) or .NET Full Framework release. Microsoft dropped "Core" from the name to signify that there is meant to be only one .NET and also skipped version 4 ( of .NET Core ) to stress that version 5 is the upgrade path for both .NET Core 3.1 and .NET Framework 4.8.

As .NET 5 is meant to replace .NET Framework, it includes things .NET Core did not like the ability to create Windows Forms and WPF applications. With .NET 5, developers will now use the same BCL for both a WPF app and a web app ( where before .NET Framework and .NET Core had different versions of the BCL ). In .NET 5, there is only one version of ASP.NET ( ASP.NET Core ).

Sadly, Microsoft was not able to finish the job of unification and, with .NET 5, you still require Xamarin ( and Mono ) to create applications for mobile operating systems like iOS and Android. This means that you still need .NET Standard as well to write code that can run on both.

The goal for .NET 6 is to bring Xamarin into the fold. To do this, .NET 6 will contain two different run-times: the one from .NET Core ( eg. RyuJIT ) and the one from Mono ( eg. MonoJIT ).

Going back to our list above, we said that .NET was a few things:

A compiler suite ( C#, F#, VisualBasic .NET )
the Base Class Libraries ( BCL )
the runtime ( the bits needed to execute the compiled CIL )

In .NET 6, you use the same compilers regardless of your target ( Linux, Windows, MacOS, iOS, Android, Blazor / WASM, etc ). Importantly, you also use the exact same BCL. A new cross-platform GUI API has even been envisioned to replace Xamarin Forms ( MAUI ) which will work across all targets. So, to a developer, .NET 6 looks the same no matter what you are building. This means that you do not need ".NET Standard" anymore. With .NET 6, there is only one .NET version ( that is not legacy ).

However, their are still two run-times in .NET 6: the .NET Core one and the one from Mono / Xamarin. Windows, Linux, and MacOS will use the .NET Core runtime to execute .NET Code. On iOS, Android, and WASM, .NET applications will run on the Mono run-time. Mono lives on in .NET 6 but it is only the runtime. The Mono BCL is legacy because the .NET Full Framework BCL is legacy.

So, the question "is it fair to assume that Mono will essentially become obsoleted" has two answers:

1 - Mono is not going anywhere. In fact, it is ( incredibly ) going to be part of the official .NET release from Microsoft in .NET 6 and beyond. That is, the Mono run-time is a core part of .NET 6.

2 - The full Mono Project release ( most recently version 6.12 ) is legacy as it mimics .NET Full Framework and its now legacy BCL ( eg. the old ASP.NET design -- including Web Forms ).

Microsoft has copied the Mono runtime into a different GitHub repository ( outside of the GitHub projects managed by the Mono Project ). To my knowledge, all official development is done in the Microsoft repository. As it is still Open Source however, the code can be incorporated into the Mono Project projects as well.

I have no idea what the future plans for the Mono Project are independent of the Mono runtime that is now maintained by Microsoft. As of this writing, the Mono projects at GitHub remain very active.

Is .NET/Mono or Java the better choice for cross-platform development?

Well....Java is actually more portable. Mono isn't implemented everywhere, and it lags behind the Microsoft implementation significantly. The Java SDK seems to stay in better sync across platforms (and it works on more platforms).

I'd also say Java has more tool availability across all those platforms, although there are plenty of tools available for .NET on Windows platforms.

Update for 2014

I still hold this opinion in 2014. However, I'll qualify this by saying I'm just now starting to pay some attention to Mono after a long while of not really caring, so there may be improvements in the Mono runtime (or ecosystem) that I haven't been made aware of. AFAIK, there is still no support for WPF, WCF, WF, of WIF. Mono can run on iOS, but to my knowledge, the Java runtime still runs on far more platforms than Mono. Also, Mono is starting to see some much improved tooling (Xamarin), and Microsoft seems to have a much more cross-platform kind of attitude and willingness to work with partners to make them complimentary, rather than competitive (for example, Mono will be a pretty important part of the upcoming OWIN/Helios ASP.NET landscape). I suspect that in the coming years the differences in portability will lessen rapidly, especially after .NET being open-sourced.

Update for 2018

My view on this is starting to go the other way. I think .NET, broadly, particularly with .NET Core, has started to achieve "portability parity" with Java. There are efforts underway to bring WPF to .NET Core for some platforms, and .NET Core itself runs on a great many platforms now. Mono (owned by Xamarin, which is now owned by Microsoft) is a more mature and polished product than ever, and writing applications that work on multiple platforms is no longer the domain of deep gnosis of .NET hackery, but is a relatively straightforward endeavor. There are, of course, libraries and services and applications that are Windows-only or can only target specific platforms - but the same can be said of Java (broadly).

If I were in the OP's shoes at this point, I can think of no reason inherent in the languages or tech stacks themselves that would prevent me from choosing .NET for any application going forward from this point.

Continuous Integration for a small .NET open source project

I know the thread is quite old, but for the people still looking for the answer I recommend taking a look at AppHarbor

It is pretty easy to setup integration with Github and Bitbucket, and you have basic db connections for free through "addon" options.

Quite convenient for startups.

Web hosting for Mono?

Mono Project Web Hosting should do:

The Mono Project (a.k.a. mod_mono) is an open-source .NET Framework emulation tool for Linux sponsored by Novell. Through Mono, we have assembled a simple and easy-to-use web hosting platform which bridges the gap which previously existed between Windows and Linux hosting providers. What was once properietary Microsoft technology has been made available to the open-source developer community, and supplied right here with our premium Linux hosting service.

Is Mono is Matured for Live Websites?

Look at this list from the mono project (Companies using Mono) and make your own mind up.

Should you use it? That depends on what features you need and whether they are supported.

Should I Open Source my MonoTouch .NET iPhone application?

I open-sourced my first iPhone application under the BSD license and haven't regretted that decision one bit. I wrote it to teach myself the particulars of developing for the iPhone, and figured that I'd release the code to help others doing the same. I've even written a couple of posts about what I learned in the development of this application. I also made this application free and open source because it relied on a taxpayer-funded scientific resource and it felt wrong to me to charge for anything connected to such a facility.

One benefit you will see from this is traffic to your website. First, having a free application will get you a lot of downloads and a significant number of visits from curious users. Since the launch of the App Store, my application has been downloaded over 500,000 times. Second, there are a lot of iPhone developers out there who are hungry for information (and that number is growing by the day). The source code has been downloaded tens of thousands of times and my articles about developing the application have been read by over 60,000 unique visitors.

That website traffic, and the links to your site from various places, will help you in the long run by providing exposure and dramatically increasing your Google page ranking. My second application, which I charge for, would not have done as well as it has if I hadn't built up the kind of recognition I did with my open-sourced application.

However, don't expect significant contributions to your open sourced application. From the tens of thousands of downloads of the code that I've seen, only three people have contributed anything back. With the exception of a French localization, those contributions have only been minor bugfixes.

As far as the practical matters of opening the source code, I haven't had too much of a problem with just hosting a tarball of the code for the latest version on my site. No one has complained about the lack of a repository for it. License-wise, I recommend a BSD-style license due to the problems with GPL and LGPL licenses on the iPhone, as well as my belief that GPL and LGPL licenses hold many open source projects back (as Daniel Jalkut articulates here).