Thanks Zac, so in short, you're saying that if I pick up my .NET compiled DAL
dlls I can move them over to my Ubuntu installation,
and code some mono code utilizing them without a problem? That would indeed be
great.
Frans
> 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 DevelopMentorR http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
