[Mono-list] Quick Question...

[Guenther Roith]

Hi!

> I have a question and I haven't seen it come up previously.  One thing
that
> has been stated in the past is that part of the rationale for creating
Mono
> was that it would make it easier for the developer and end user as they
> won't have to worry about dependency issues.  How can this be true?  From
> what I have observed, Mono is currently just making calls to various GNOME
> libraries to get most of the work done.  If that is the case, Mono is not
> the platform that it is claimed to be, just another wrapper like Gtk--,
> Gnome--, PyGtk and others.  Would it not me more appropriate to have the
end
> goal being to have wrappers for only the GUI portions as to maintain the
> look and feel of GNOME apps?  Eventually all classes in Mono should have
> their own code, should they not?  If they do not, won't the dependency
> problem still exist, only worse?  If I have Mono version X installed and
it
> is built against libABC version 1.0 and I have an app that needs libABC
> version 1.5 which breaks compatibility, it will also break Mono which
will,
> in turn, break every app that relies on it.  How can this be considered as
> advancement for development on Linux?  This could be a real nightmare.
> Please tell me I am wrong about this!

Yes, you are ;-)

First, mono is _not_ a wrapper around GNOME libs.
Most parts of the class library work without it.

Then, the GNOME API is finally frozen and will be back-wards compatible.

Now, the benefit of solving dependency issues was really not the biggest
reason for creating mono, but still the feature exists. It doesn't mean,
that if you call native libs, they can exist in various versions, but if you
write your application in "managed code"/IL , mono can handle different
versions of that code, by using the "Global Assesmbly Cache".

So, the conclusion is, if you write in C#, your program won't have that
problems or cause them, the mono class lib/runtime, theoretically still has
them.

Johannes