i can certainly understand that behavioral compatibility isn’t easy, though i would prefer it that the BCL classes are fully compatible before new API’s (like Silverlight) are implemented. The same effort that goes into implementing new API’s might be better spent making sure that what is already there actually works. If both the BCL classes and new API’s have incompatibilities, then you can’t really expect people to use Mono for real stuff. Sure, people can try to work around those bugs, but they really shouldn’t have to.

as for filing bug reports… i’d do that if the software was actually usable for me and the bugs i’d run into weren’t preventing me from getting anything done with it. At this point, i can’t use it at all for the stuff that i’m working on. I’d have to spend time on filing bug reports, creating samples that reproduce the problem, and then wait a few weeks/months before i can try again? I once filed a bug report (bug number 62293, though i can’t find the details of it anymore) on a regex memory leak in Mono a couple of years ago with a reproducible sample and it was ignored for a long time. Just as your time and resources are limited, so is mine and i prefer to spend it on stuff that doesn’t feel like a waste of time.

* MD’s C# formatting options are “policies”, which means they’re per-solution (and can be overridden per-project). You can set the default format in the “Default policies” dialog. The formatting options panel in your screenshot is a vestigial panel for the smart indenter options that hasn’t been merged with the new system.

* When complaining that Mono doesn’t behave exactly like .NET, please consider that Mono is a cleanly reverse-engineered implementation of a HUGE framework, on top of different operating systems than it was designed for, and DOES try to be bug-compatible. However, complex software can turn up bugs or behavioural incompatibilities from time, and they’ll only get fixed if you file bug reports. It’s an open-source project, and is dependent on such contributions.

* To be fair to VS, the main reason the “add reference” dialog starts up so slowly is the COM tab, which MD doesn’t have. No idea why they didn’t background-load that tab’s contents though.

* The soft debugger is new since October, and there are still a few issues. Please file bug reports for any issues you encounter.

* If MD hangs, please issue a “kill -QUIT” against the MD process, which will cause it to write stacktraces of all threads to the MD log, then file the log in a bug report.

* The version of GTK+ that’s bundled with Mono on Mac (a heavily patched 2.17.4) has a number of issues, and losing track of mouse grabs is one of them. We’re in the process of rebasing the GTK patches on top of 2.18.x and trying to make sure there aren’t any regressions.

* We dogfood MonoDevelop 100% of the time when working on MonoDevelop, and it has over 600kloc, so is certainly a nontrivial app. It also works well on .NET on Windows.

as for the issues with Mono itself, that’s another story…