We Keep Coding

Should I rewrite GUI with GTK+ instead of WinForms for Mono?

I was making an application with Visual Studio, winforms and I'm using openTK. Recently I thought about making it cross-platform. I'm going to use Mono, because I don't know anything else similar. And I have totally no experience with GTK+. In my application, currently there are 4 windows(of course there will be more in future). I want to make application fast in Windows, Linux and OS X. I have read, that GTK+ is better than WinForms, but still not sure which to choose. So, should I remake everything for GTK+ or stay with WinForms and why? Also, is there any tool, which would do this work for me?

Honestly, you're going to need to tell us more about your audience/intended market to provide a great answer, but my $0.02 from some experience developing there is that GUI development for Mono on the desktop is a multi-target affair if you want to do it "Right". You're going to need to develop the shared backend exceptionally modularly, and then write UI once per platform.
Windows
Windows.Forms as implemented on Mono is a great crutch if your app's in its infancy, allowing you to target Windows immediately and deploy in a somewhat crippled fashion on OS X and Linux. Note, however, that I've been told on IRC that Windows.Forms development on Mono is essentially dead. Old bugs don't get updated, and, as a for instance, I ran into SelectionBackColor not working in RichTextBox on OS X (it's a problem in a lib Mono uses for Windows.Forms on OS X) within a few minutes of testing. Neat that it's there, perhaps good for quick utilities where you can code around its limitations (see question here for an example).
OS X
For targeting OS X, if you have a real, commercial, end-user app, you're going to need to get used to, um, interfacing with Interface Builder. I should make clear here that using XCode and Interface Builder absolutely requires that you have access to a box running OS X. Otherwise, you're stuck with Windows.Forms or, preferably, I think, Gtk#.
Xamarin has done a great job making its IDE stub out connections to native UIs built in XCode. That's how they do it for iOS development as well. It works fairly well, though the documentation is weak. There's a great video from 2011 from Michael Hutchingson describing this process, though I suppose it's getting long in the tooth (ie, "old"). (Direct link to video)
I'm assuming Interface Builder is also your only real choice if you want to target the Mac App Store. But look, it's a native UI that's stubbed to your C# code, which is, all things considered, a great compromise.
Linux
I haven't really targeted Linux. Seems like Gtk# would be a natural fit, but I'm not much hands-on help there. My stuff builds in Windows.Forms, and there are rough edges, just like in OS X. If I got more serious, I would start with Gtk#, and that's where MonoDevelop has its GUI RAD as well.
Example of a serious, mature, crossplatform Gtk# app
Quick note: Banshee uses Gtk# to target OS X, Windows (alpha), and Linux. You can get some great context for how difficult it is to use Gtk# on a large application cross-platform by checking out its mailing list and other resources.
Sorry the news isn't any easier. There is no silver bullet/single right answer.
201607 UPDATE: I think the answer is slowly becoming to use Xamarin.Forms to target cross-platform. You might still be stuck writing a separate Mac interface for now, but there's reason to believe that'll have Xamarin.Forms support at some point too; see below.
Unfortunately, if you're targeting Linux, I think you're still in the same boat as you were before for now.
Windows: You can now use Xamarin.Forms and UWP.
macOS: You're still in essentially the same place, but I had a Xamarin employee tell me last weekend that Xamarin.Forms is unofficially in development for OS X. I believe this is the repo on GitHub. (There's even a branch for tvOS.)

I would suggest that you consider what your target audience is. Writing UI using a framework like GTK# might seem a good idea but to the average user your application won't look like their other Windows/OSX applications which easily can stop people from using it (unless it's really exceptional in some other way).
The best way to do this (which might not be possible due to time/budget constraints) is to put your application logic in a separate assembly and then write UI for each platform, using Winform (or WPF) for Windows, MonoMac/Cocoa for OSX and GTK# for Linux. It also won't limit you to using features that are available on all platform which would degrade the user experience a lot.

I'm facing a similar problem now - but what Karl-Johan said about keeping application logic separate will make the task much easier. Look into a ViewModel pattern (MVVM), and you'll have much less code to rewrite and test for each platform, as the central logic becomes UI agnostic.

On what factors should we opt Java or .Net technology for a windows application?

I am quite aware of both java and C# .Net .when i try to create a new windows application which are the factors that decide which technology should be opted?
I know of one thing ,for great and faster UI development Visual studio helps a lot.

There are several factors I would consider...
What are your programmers used to working with already? What third party libraries are you likely to need, what's available on both platforms?
Does platform independence matter to you?
Would LinQ be advantageous?
If you're starting from scratch, costs for the platforms?
Both platforms have strong communities around them...
Hope this helps...

Dotnet is pretty much native in Windows which obviously makes it more suited to writing Windows programs. Using Java in a Windows-only environment makes it much harder for you since it effectively just adds another unnecessary API layer.
You will soon realise that all integration points between your Java code and Windows are a bit problematic. For instance, creating installation programs, access file system, reading/writing the registry, starting/stopping services, task bar icons, using Windows GUI components (media player, IE...), help file system...
It all boils down to this imo: The Dotnet framework is much richer in terms of functionality than the Java dito, mainly becuase Java is cross-platform and thus needs a "one-size-fit-all" approach to its API. My experience is that you will only get frustrated trying to "emulate" a Windows native program in Java.

Choose the one with which you are most familiar. The two platforms are different enough that skills from one does not transfer easily to the other.
In any case, try making a trivial application in both your scenarios and see how it works for you. The initial impression is important as it is probably indicative of how well the rest of the work will be.

It also depends on what kind of windows application you want to build. If it's just a question of building a simple standalone application then, considering you know both languages equally well, I wouldn't hesitate and would go for a 100% microsoft solution, especially if you have to do specific things like accessing ActiveDirectory, the windows registry, etc.
Not that you can't do it in Java : you can always use AD through LDAP in Java for example, but the APIs are just "a bit" more complicated than the .Net ones (try to decode objectSIDs in Java without a few tricks).
Now if you have to build an enterprise app. I just feel that popular frameworks like Spring and Hibernate are always coming out after their Java counterparts (disclaimer : this is a personal opinion; I didn't do any research on this, thoroughly comparing frameworks in both languages, but that's just the feeling I have). I don't know how good the .Net implementations are though, so I don't have a point of view on that. I just remember writing .Net 2.0 apps and not liking ADO.Net at all.
My view is that the frameworks I like do exist in both languages, but they are first developed for Java, then ported to .Net.
Now I'm not the kind of developer trying to defend his favourite language over the others. If I don't have external constraints to develop, then I choose whatever language gets my app up and running faster and in the most efficient way.

...But with java you will have crossplatform application on scratch.
Also coding UI in java is not difficult - if you read some guides before and use some frameworks as swing application framework or SWT framework.

If its Exclusively for Windows then .Net is best bet.

Yeah for a pure cross platform application Java can't be beat, but if you can manage it Silverlight is a subset of WPF and a pretty compelling cross-platform proposition on its own.
Productivity-wise I think WPF has an edge as it has a nice XAML markup language that can be easily created with the built-in designer in VS.NET or integrates nicely with MS' suite of expression products.

How Reliable is Mono on Linux vs .NET on Windows?

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.

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

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

C# on Linux - Anyone got an opinion based on experience using mono?

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.