I am trying to decide upon using Mono with C# or Python (Django) for a Linux based Web Site. My concern with C# is that Mono may not be as reliable as .NET. Does anyone have any experience with this?
i do a variety of things using mono/c# on linux - all projects compiled on a windows machine, no less.
i've done services, web sites, console apps, you name it. unless you're doing real edge-case things, you should have no problems.
i also run sites using lighttpd + fastcgi + mono with no problem. i love it
I think it's a given that Mono is less reliable than .NET on Windows, given the resources available for development, and the size of the user base. How much less is a moot point.
This blog post from Miguel de Icaza illustrates the sort of problems that would concern me when using Mono.
However I can't give you any comparison of Mono and Python.
This depends what you are doing. If you are creating a non-enterprise website, you should do fine with ether. I've heard good things about Mono. The problem with using Mono is that it is constantly playing catchup with MS and that it has to support multiple platforms, whereas MS does not. I have written desktop applications with mono, but I have never done website related things with it. With C# and the Windows platform, your best bet is the MS implementation. My recommendation would be to use Python.
I can not speak for the supportability, reliability, etc of Django, but Python has been arround for a while, and it has a long track record for working well on Linux/Unix.
Personally, I would steer you away from using C# (Mono) if you are targeting Linux.
Your development community could be very small for any platform issues; while there are obviously a lot of C# developers, the number who use Mono is relatively tiny1.
In my experience, there are a lot of issues with even finding a recent version of Mono for Linux, unless you run SUSE2.
While Mono may have the features you want, and may have the reliability (I can't comment, I'm still using 1.x!) you may also want to look into the speed if you expect heavy usage.
If you plan to deploy to more machines (especially if you can't clone them) these are much more of an issue; they matter somewhat less if it's just one server.3
There are some who have concerns about the threat of lawsuits over Mono technology, and what might happen to the end users (you and your users) if those occurred. From what I've read, I'm not overly concerned, but I am not a lawyer.
Good luck.
I could be mistaken; I didn't look at download numbers for Mono although that'd be the
upper bound.
Ubuntu Karmic (9.10) has Mono 2.4, but I regret I upgraded from Jaunty (9.04) which had 1.9.
Building from source can be taxing. And there are other sources for the Mono 2.X binaries, but they aren't easy to locate.
This might be pure speculation, but here is my experience. I'm using ubuntu and mono (as well as monodevelop) is shipped 2 years behind current version. You could compile newer one, but that's pain. I've used it in 3 hobby projects, here is my conclusion: comparing to microsoft implementation it's buggy and has memory leaks and slower. Well, most of the time it will work, but should you stress your software and you'll see. I wish I knew C++ as good as C#, so I could go with it on linux. All applies to v. 2.10 and below.
Related
Alrighty guys, I'm writing an application that I want to be cross-platform. Up until recently I've been trying to do this in Silverlight with C# because it also runs on OS X, but with me being fairly rusty with C# in addition to being new to Silverlight I've run into headache after headache. Most of this stems from the restrictions that come along with an application that's intended to run in a browser, issues with it running differently when running from my development sever vs directly from a file://, etc.
I'd rather completely abandon the whole OS X support idea than have to completely rewrite the app for OS X, especially since I have utterly NO experience writing for it. What I'm hoping to be able to do is write a regular app in C# .NET with Visual Studio for Windows and then easily port it to OS X with Mono.
How difficult is it to bring a .NET app over to OS X with Mono? My app is fairly straightforward, there's nothing exotic going on with the forms or anything, so I'd have to assume that it'd be supported in Mono's WinForms implementation.
Are there any good resources out there on how to port an app using Mono? Or, perhaps, am I missing the entire point and it simply lets you run .NET apps on OS X and I don't need to bother with porting?
Forgive my utter ignorance on the subject, I only started considering going this route like 10 minutes ago after running into yet another annoying restriction in Silverlight.
I'll be the first to admit that I don't know my head from my ass about this subject, so be gentle.. :)
Appart from MoMa as mentioned in the other answers you might be interested in MonoMac.
With the success of MonoTouch (writing c# for iPhone), there is now also a project called MonoMac to create native UI's for OSX while using .net/mono in the background. Might be interesting for you http://www.mono-project.com/MonoMac, article on Miguel de Icaza's blog: http://tirania.org/blog/archive/2010/Apr-19.html
In addition to what has been said already, considering that Mono supports a subset of the full .NET functionality, I would probably prefer to develop on Mono, then test against Microsoft's runtime, if the aim is to run on both of those. Otherwise, you run the risk of inadvertantly using some functionality that isn't available in Mono, and have to throw a large chunk of code out the window by the time you get around to doing the cross-platform build and testing.
Mono project has a page dedicated to how to port applications,
http://mono-project.com/Guidelines:Application_Portability
However, it is never enough as your application can be unique in so many ways.
Try to port it and report issues to Mono guys whenever necessary. Besides, if you work for a firm, consider Mono's commercial support service,
http://mono-project.com/Support
There are several things you should keep in mind.
you'll have to port any usage of platform depedendent UI code
don't use platform dependentent OS calls (win32 api)
don't use "exotic" libraries (like workflow, sadly ef)
In general: abstract dependencies to such code away, so you can easily replace them with mono-specific libraries. (an adviseable pattern would be MVVM).
There is a tool called MoMA that will help you with all that. However, take the results with a grain of salt. In any case, just try it.
I'm an inquisitive .NET student without any commercial working knowledge and I have been puzzled by what exactlty are .NET languages meant for?
Q1.If you look on job websites, .NET seems mainly used for web applications, not much for Windows applications? (My dream job is to develop standalone small Windows applications.)
Q2.Are most "major" Windows applications developed using C/C++? e.g. word processing applications like MS Word or OpenOffice; photo editing software like ACD See or Photoshop; MSN or Yahoo Messenger; disc burners... Is .NET too slow and too indirect to handle these kinds of tasks?
Q3.Are .NET languages mostly only used in SIMPLE business applications involving database backend? E.g. payroll or GPS applications Because it's too slow and too indirect for major software applications?
Q4.I thought for the last few years .NET was the only development tool encouraged by Microsoft for Windows applications and C/C++ are outdated languages? Do they use MFC to access Windows API which is also outdated in new versions of Windows(backward compatible but not encouraged by Windows)?
Q5.If C/C++ are the main tools for major standalone Windows Applications, then the (slow) managed code approach is only a joke? Or the dominance of C/C++ is due to most major applications are older than .NET? Can you give me some famous names of software developed using .NET?
Thanks a lot for your industrial insight!
If you look on job websites, .NET seems mainly used for web applications, not much for Windows applications?
1) .NET is not very common for "mainstream" desktop applications, if you consider mainstream to be Photoshop, etc. This is often more due to the fact that mainstream applications are based on code that was written long before .NET came around, and those applications are never rewritten, only grown. They carry a huge amount of legacy code from previous versions.
Are most "major" Windows applications developed using C/C++?
2a) See #1.
Is .NET too slow and too indirect to handle these kinds of tasks?
2b) Absolutely not. .NET can be blisteringly fast or dismally slow. Like with any tool, it depends on who is using it.
Are .NET languages mostly only used in SIMPLE business applications involving database backend? E.g. payroll or GPS applications
3) Payroll or GPS are hardly simple. Line of Business (LOB) applications can be immensely complex and .NET is often a good match for these precisely because they are so complicated.
I thought for the last few years .NET was the only development tool encouraged by Microsoft for Windows applications and C/C++ are outdated languages?
4) That is wrong. C/C++ are not outdated, they are just different. They provide a more precise level of control over the machine in exchange for longer and more difficult development time.
If C/C++ are the main tools for major standalone Windows Applications, then the (slow) managed code approach is only a joke? Or the dominance of C/C++ is due to most major applications are older than .NET? Can you give me some famous names of software developed using .NET?
5) Dominance is very much inherited. Again, .NET is not slow. Mainstream applications are well-known in large part because they have been around longer than .NET, so there's no reason to expect many, if any, .NET applications as well-known or popular as Word or Photoshop. Several years in the future, it's not unreasonable to expect some famous applications to arise that are .NET-based.
Edit:
Some people seem to be confused and believe that somewhere in this answer, it is asserted that .NET is as fast as c++. The only argument present is that both .NET and c++ are fast enough to run most mainstream applications. And anyone who thinks development time in c++ and .NET are equal, all other things being equal, hasn't done much development in one of the two :)
.NET is increasingly becoming the language of choice for most Windows development, including standalone desktop applications.
That being said, C/C++ are still used heavily in this space. However, on Windows, much of the "cutting edge" work is done in .NET, or a mix of .NET with native code.
The latter is, frankly, probably where the most exciting work is happening. It allows you to have the "close to metal" feel of native code when required, but still have all of the power provided by the newest .NET framework (such as WPF) for the user interface layer and non-performance critical sections. This is becoming more common over time - for example, Visual Studio is still largely native (C++) code, but the entire user interface was written using WPF (.NET).
I do nothing but desktop Windows development. I personally prefer to use .NET for everything I possibly can - and revert to C/C++ for the very small (and increasingly smaller) portions where .NET doesn't make sense.
One issue I take with your question is that you ask a factual question ("Are most "major" Windows applications developed using C/C++?") and judgmental/causation question ("Is .NET too slow and too indirect to handle these kinds of tasks?") in one go.
It is indeed true that most Windows desktop applications (e.g. Microsoft Office, Adobe Photoshop and the likes) are written in native code. However it is also quite true that on server side, at least in Microsoft stack, it is all ASP.NET, i.e. managed code.
Consider now that performance requirements of a typical web application are much more strict than that of a typical desktop application - after all, a desktop application only have one user, when a server application may have thousands and thousands. So the causation link you imply sounds weak.
As the others have pointed out, there are many requirements at play when choosing implementation technique for your desktop app. It might be portability, tradition, existing code base, training of your developers, existence of managed wrappers for particular APIs (historically Windows was often lacking in the latter) and many other factors.
For the specific examples of "all managed" desktop apps I would cite ReSharper - it is a fully .Net desktop application with non-trivial user interface and logic. Visual Studio 2010 also have considerable portions (including UI/presentation layer) written in managed code.
There are a few main issues that, I believe, still contribute to the relative lack of commerical .NET applications (the type you buy in a box at your local software store):
Requiring customers to (possibly) download the correct version of the framework runtime and/or install it before running your app.
Where ultra-high performance is required, .NET array/collection bounds checking (managed code protection in general) is obviously slower than languages/tools that don't do this for you.
The view that JIT compilation causes slower startup times.
There is often little business value in re-writing 1000's of lines of working C/C++ code in .NET.
I'm not saying whether these issues are valid or not, just trying to answer your question as to why there is still a relative a lack of commerical (shrink-wrapped) .NET software.
.NET is certainly used for standalone applications, though determining exact percentages is next to impossible.
Yes they're mostly done with older languages. Many certainly could be done with .NET, but you'd need a lot of incentive to rewrite something as large as Word, Photoshop, etc., from the ground up.
Not necessarily, but it can look that way simply because a huge percentage of business applications can be (and are) written as database front-ends.
I don't think MS has a really unified message here -- they've certainly put a lot of work into .NET, but they also continue to develop and improve alternatives such as MFC (probably at least in part because they use it themselves).
Some of both. More than speed, C++ and C give flexibility, portability (e.g., Office for the Mac) and greater ability to distinguish your application from the others.
Most large Windows applications are C++ because they were written before .NET existed. It would be pointless spending 2 years of development time rewriting Microsoft Office (say) in .NET, only have exactly what you started with two years ago as the result.
Instead, most large software application build .NET into them slowly. Look at VSTO, for instance, for a great example of .NET interoperability in a C++ app.
On the other hand, Microsoft have released a number of software packages that were written entirely (or primarily) in .NET languages. Expression Blend was probably their first. Visual Studio 2010 (which is largely WPF-based) is the latest.
ASP.NET is very large because you control the hardware. It dosen't matter if your users are on linux or on mac. The page renders and works. When you have the hardware as a parameter, people are wary of .NET which (mono-aside) is prettymuch windows exclusive. (Mono 'works' but it's less accepted than other x-platform approaches).
.NET also requires a download to be installer (.NET Framework). There's a lot of friction for users installing things to USE your thing, it's been a small barrier in XP, but now that 3.0/3.5 is baked into vista/win7 it's becoming a non-issue.
In the past, yes. These days, not as much. (Correct me if i'm wrong, cuz it's very possible i am) I believe VStudio 2010, and Office 2007+ are now developed in .NET since they don't heavily require on maximum performance. C/C++ is still faster for games, but even some indie developers are building games for xbox/pc on XNA (DX for .NET, sorta)
No. .NET isn't as slow as it used to. There are Lots of big big applications built in .NET now because it offers a wide variety of features to develop BIG applications FASTER, BETTER, and MORE STABLE.
.NET does not use MFC. Winforms hook GDI+, and WPF hooks the Windows Presentation Foundation to do it's api calls. .NET is for the most part a re-write, but some things (like direct file-i/o, are wrapped down to the windows API)
Software is developed in C/C++ because it's a) fast b) commonly known. But with today's new programmers, it's shifting I think. I also believe the new versions of Sony Vegas have been re-written for .NET, but once again I may be wrong. The key to remember is that .NET isn't as slow as it used to be, MS has bee working on the performance issue hard because they want to sell .NET for windows development.
Windows itself is not written in .NET. There's good reason for that...
One of the major problems for .NET in mainstream applications is that the ISV's producing them would like to have portable code. Photoshop for instance has a very succesful Mac OSX version. Of course, such portability is precisely not the goal of Microsoft.
Now, for the Web this doesn't matter too much. You can use .Net on the server-side and still produce a Safari-compatible website.
IMHO the tide will come whenever IE will become a managed application.
If you want to develop LOB apps for small shops that can't afford to hire programmers, and you wish to offer max features for minimum work, write them in MS-Access. Serious.
https://stackoverflow.com/questions/2437387/is-ms-access-still-the-most-efficient-rad-tool-for-small-scale-custom-apps
in other words, now that we have Mono, has C# become just as OS-agnostic as Java when it comes to server-side web applications? Or are there still big limitations having to do with what Mono can/cannot do or maybe with what libraries can be made available to a C# server-side app on Linux?
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.
Yes and no... yes, you can now run asp.net on Linux via Mono.
However, I think in practice you will find many more platform specific limitations than you would with similar Java applications. I rarely see major platform specific issues even in average quality software written in Java.
With ASP.Net, you'll routinely see apps and third party libraries that barely work on Mono, or just don't work at all. The porting effort may not be high, but its much higher than similar Java applications, in my experience.
Not every application:
The Mono API today is somewhere in
between .NET 2.0 and .NET 3.5 see our
Roadmap for details about what is
implemented.
From Can Mono run binaries produced by Visual Studio? in the Mono Faq General. You can view the detailed state of ASP.NET in Mono in the ASP Tests page.
A lot of useful information here from the Mono Team.
http://www.mono-project.com/ASP.NET
Is it worthwhile learning C# if you are a Linux user? There is Mono but it seems destined to always be behind the curve with the constant threat of MS action if they start to lose money.
Currently I am leaning more towards Java as its is fully GPLed and there are no major threats of software patents. It already has a big oss community behind it and has a solid reputation on the server whereas C# still needs to prove itself there.
The big advantage for C# programmers is that they are cheaper than Java developers. I also wonder exactly how portable C# code is though. Can one simply take a C# app written to target Mono and run it on windows?
I've written a number of C# command-line programs, specifically to run as distributed simulation engines, that were targeted for Ubuntu. They work perfectly there or on Windows.
It's hard to say what the future holds, but C# is a powerful language and I think it's worth learning even just for our personal growth. I despise Windows myself but have been writing C# for a while (for Windows mostly) since it pays the bills.
Novell uses Mono extensively for their Linux applications and I think that their relationship with Microsoft adds some weight to the idea that .NET for Linux will stick around.
Here's a list of some of the companies using Mono.
"on the server whereas C# still needs
to proof itself there"
You do know MySpace is built ontop of ASP.NET, right? Millions of hits a day running off a C# backend.
Sorry for the flame-bait, but I've personally had more portability success with mono, than java. Not a blanket statement, just my experience.
This question has already been asked and answered many times on SO.
Is Mono ready for prime time?
Why Use Mono?
Given your scenario, me personally I would learn Java, as you will find the transition into C# further down the line, quite smooth. Also having Java under your belt is a very good thing. I would say Java is much more portable than C# although you have the option of using the Compact Framework, which will be quicker to bootstrap with your program.
I work for a company that uses both Java and C#. I prefer C# because I think Visual Studio blows away Eclipse, and I just like the language better. However, I think you might do better learning Java in your case. You have more flexibility both for your project and career-wise. You can learn C# anytime.
C# is a nice language, and I find it much easier to work with than C/C++, especially for GTK applications.
I also think that learning C# would be a much better investment than learning Java. I'm saying this for no other reason than my personal taste, but I also honestly and objectively believe that C# will have a better future than Java.
As for running Mono apps on Windows, you can usually do this without a hassle, but if it's a GUI application, you will either have to create a Windows version that uses Winforms, or your users will have to install GTK for Windows. Either way, your applications will have a much better look and feel than Java applications on both platforms.
Finally, I don't think M$ will take legal action against Mono anytime soon.
It works very nice. IMHO you should use Mono from the development site (www.go-mono.com) rather than version provided with your distribution.
Also you could try dry-running it with VMWare machine that is also avaliable on the official site.
Writing fast native applications, with API calls and etc, in a modern cross platform programming language like C# would be awesome, wouldn't it? For example if you want to write a simple utility for helping IT people with installing things, which wouldn't need another components, in an easy and modern programming language? or if you want to write a 3D game, it should be fast, and JIT would just make it slower...
Why, why isn't it possible? Why there are no native modern programming languages for these things?
C# and .Net are native code. I think you misunderstand the JITter. It's not a VM. A C# program is compiled to fully native code before any of it is executed.
Now, the "needing other components" part is a concern. Give it time, though. You'll be hard pressed to find a windows installation these days without at least .Net 2.0, and even a couple mainstream linux distros include mono out of the box.
Don't assume the JIT makes things slower. The JIT can optimize for the exact computer running the application rather than a generic computer like a 386 or Pentium. It can even make better speed/memory trade-off decisions when generating code because it knows exactly what's available. And if JIT still makes things slower, you can NGEN them so that JITting is all done beforehand.
As proof of this, consider that Quake has been ported to the CLR a couple of times, and in my personal tests, the frames per second have been faster when Quake runs on the CLR about half the times I demo it.
Compiled .NET programs have been shown to run just as quickly as C. If you want it ultra-lean write it in assembly for your native processor.
You can use the Microsoft NGEN.EXE tool to create a native image of a .NET assembly.
See MSDN NGEN documentation. Microsoft already though about what you're getting at here.
Microsoft also makes ILMERGE.EXE tool to merge multiple assembly files into one. This might border on optimization and speed too.
As a side note, Mono has full ahead of time compiling, eliminating the runtime. (I think that's how they get away running on iPhone, which prohibits any JIT.)
So, does this mean that we could fully compile and link a C# program using (limited) .NET calls into a standalone EXE that would run without .NET being installed at all?
FYI: Checking a server estate of some 5000 servers revealed about 200 without even .NET 2.0.
This causes problems for code that must run on "all Windows instances". With .NET 4.0+ not including 2.0 this gets worse as both new AND old Windows machines might not have the 'right' .NET
there is, C. C can be used to write any application , ever !!!