On Mon, 2006-06-05 at 10:18 +0200, Frans Bouma wrote: > the thing is: is Mono 'another platform' or is Mono .NET which runs on > Linux (and other platforms)? This is significant. If > it's the latter, you could just develop on .NET, and run the binary on > Mono. If it's the former, it will take time, effort and thus > money to make a project's software run on Mono and _KEEP_ it running > on Mono. The porting alone will introduce bugs in the software > which have to be debugged. How? Is the development environment of Mono > on par with tools available for .NET? I'm sure there's a > debugger, but is it on the level of gdb or more usable? Will the team > be able to utilize the tools available to debug the code > ported to mono that it will keep on running on Mono? > Assemblies in .NET are defined by the CLI standard. They are not traditional exes and dlls. They contain a PE header but past that they contain CLI bytecode if you will. If you compiled under a compiler that doesn't mix CIL and native machine code (only Managed C++ does this) then the binary this produced will run under Mono, .NET, PNET, IBMs internal CLI implementation they tinkered with. That means if you compile with Microsoft's C# compiler it will run on Mono, or if you compile with our C# it will run on Microsoft's platform. The bytecode is unversial. Microsoft published that as a standard with EMCA back in 2001. We implemented that. Its just liket hat.
> And don't think lightly about this. Every method of every class >can behave differently. I admit it was about 1.5 years ago I >ran my last mono program, but back then SqlDataReader.GetValue() >returned null instead of DBNull.Value if the field in the row was >NULL in the db. Small detail, but it's a difference between Mono >and .NET, porting code over will in such a situation be a problem, >as you've to test through and through again every detail of your >application on Mono because it's not equal to .NET in _that_ >situation. I know those libraries very well, and I don't recall when it ever returned anything different in that respect. That part has been heavy regression since 2004 but if you know of any source that runs differently we would love to see it. We have thousands and thousand of nunit tests that we use to compare our results with the results we get with MS.NET. We even replicate a ton of .NET bugs just to keep things compatible. We regression constantly. If you read our mailing list, we tackle as many inconsistencies as we can, we follow the docs as closely as we can, we run software we know that beats the crap out those apis and we write tons and tons of regression tests. Its not easy by amount but we do it. The number of bugs that most people have when they run on mono is almost down to nothing. In a few .NET user group meetings I've been speaking at, I challanged people to try their programs on mono and all but 7 of 10 times it ran out of the box without issue. 2 of them normally required a little bit of tweaking (normally around their pinvokes but rarely where we do something different) and 1 of 10 dedicates itself to a 3rd party library that was written with managed C++ or something similar. The cases where you have issue even having trouble running binaries on mono is getting closer to nothing everyday. Dondus, the graph components company, their software is even starting to work on our System.Windows.Forms. DotNetNuke works, ASP.NET forums works (even got a version that runs on postgresql), Community Server works, Luis Roders Reflector works, even a bunch of MS dlls that were not even meant for Mono will run on Mono. In the way of debugging and IDEs, we have our own IDE called MonoDevelop ( http://www.monodevelop.com/ ) and our debugger which integrates into it or can be access via the command line like gdb. Other IDEs even integrate into it like XDevelop and a few unreleased ones. We are even getting better in the way of RAD with our GUI designer stetic and our ASP.NET editor based on Mozilla's editing interfaces. We support a full range of debugging visualizers and trace tools as well right into the runtime. I'm really excited about this part. We have been working on a new compacting GC instead of one based on the industry standard bohem (which is the same one as in almost all the JVMs out there) so now we can interactively shrink memory usage as it runs. That feature will be an unsupported feature in the new upcoming Mono 1.2 release but will become the default in the 2.0 release. Benchmarks between .NET and Mono are getting closer and closer each day. Our ASP.NET side is not as optimized as it is on Windows, and our XML API could use some enhancements in a few areas. However some other areas, including our MSSQL data adapter for a few features we beat even Microsoft's (in-fact I know of one company that is using our driver in MS.NET for that fact right now because of something special he is doing with blobs). In short, Mono is an implementation of the CLI standard that Microsoft published to EMCA in 2001. It's not a "clone" and the binaries are compatible. In essasance, you can still use Visual Studio, you can still do you what you always do, you can release in the sameway, you distribute in the same way, the most work you will mostly have to do is run it a few times on mono (even on the mono win32 builds) before release (maybe by your QA staff) just to make sure it does work before shipping. Little more effort is really required past that. Here are a few tips to keeping your code portable: - avoid the windows registry (we emulate one but its good to avoid it) - remember that some OSs are case sensitive with filenames - some OSs use "/" in their file names and some use "\" so use the System.IO.Path.DirectorySeparatorChar and System.IO.Path.PathSeparator constants where you have to directly generate a filepath in your code - avoid COM (no brainer) with the exception of the MS IE control which we are going to offer something compatible for - avoid pinvoke unless the library exists in both Unix and Windows both You follow those steps, and I can almost gaurentee that you will run into little to no trouble running your binary on Linux. SourceGear's Valut even runs on Mono just by copping the exe over and all they did was check the their file paths in their code. Pretty simple :-P ---- Zac Bowling <[EMAIL PROTECTED]> Mono Project Contributor http://zacbowling.com/ =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
