[Mono-list] mono / .net framework 1.1 / roadmap
12 Feb 2003 15:36:20 -0500
One of Microsoft's aims with .NET was to eliminate "DLL Hell." In
essence, they want things to be more Mac-like: once you install an
application, it will *always* work, regardless of what other software
you install/remove afterward.
This is why XCOPY installation works for .NET apps.
This is why there is a separation between "shared" and "non-shared"
assemblies, and why "shared" assemblies need to follow careful
versioning procedures (e.g. no major changes unless you change the major
version number of the assembly).
This is why you need to explicitly specify when you're overriding a
virtual function (the "override" keyword), so that if the next version
of an assembly introduces a new virtual function, your existing classes
won't override it by mistake. (The Fragile Base Class problem.)
All of this effort would be wasted if, as soon as you upgraded .NET, all
your applications broke. :-)
Consequently, each program that is built under Windows has the .NET
version it was built against compiled into the assembly. This way, if
multiple versions of .NET are present on the machine, the runtime that
most closely matches what the assembly was built against will be used.
Hence their statement:
If an application written with the .NET Framework 1.1 Beta is
installed on a system with only the .NET Framework 1.0
Redistributable, it will not run (unless configured to do so).
This is because the installed .NET version doesn't correspond to what
the application was built against.
It's actually rather sensible, if also conservative and draconian. :-)
(The same can be said for Macs, where most dependencies must be bundled
with the application, leading to duplicated libraries...)
In other words, this is all by design, and isn't likely to change. At
least not on Microsoft's part.
There are workarounds. If your program is compiled with .NET 1.1 but
should work on .NET 1.0, you can change the app.exe.config file to
specify an alternate runtime to use.
How does this effect mono? It doesn't. Mono doesn't currently have the
infrastructure in place to pay attention to versioning info, much less
follow it. :-) Consequently, if .NET v2 were released tomorrow, with
blatant API changes everywhere, mono would still run the program without
any problems...until a non-existent API was called, causing mono to
crash and burn. :-D
So, *long-term*, this should effect mono (because -- hopefully -- mono
will follow "standard procedure" with regards to assembly/runtime
versioning). At this point, we'll either have to introduce "hacks" into
mono to "thunk" the .NET runtime version to a corresponding mono version
and execute that. Or, we'll have to have developers modify their
app.exe.config file to specify the mono runtime.
Hopefully this clears things up.
On Wed, 2003-02-12 at 15:03, Chris Turchin wrote:
> Having just read the overview for MS's .NET framework 1.1beta, I was
> wondering what the Mono teams's position is regarding such further
> technology developments like this.
> I don't mean with regards to the specific new features like
> System.Data.Oracle etc. but more in general, for example, whether the
> development on a 1.0 mono will continue regardless of changes brought
> about in 1.1 or if there is even a correlation here. Is there a roadmap
> related to the development of mono in relation to the development of the
> .NET framework in general?
> I am also wondering to what extent people see this development as another
> MS attempt to keep things incompatitible. In particular, I am troubled by
> the following statement:
> * If an application written with the .NET Framework 1.1 Beta is installed
> on a system with only the .NET Framework 1.0 Redistributable, it will not
> run (unless configured to do so).
> Am I reading too much into that statement? Probably... ;-) There is not
> even a mention of mono - but to me it sounds like as soon as 1.1 gains
> acceptance, any apps developed with it would no longer run with mono
> (which would make sense, assuming they are using 1.1 specific features,
> but not necessarily in general - although "if configured to do so" it
> might work either way...).
> I dunno... its all starting to get pretty confusing to me, what seemed
> so simple and elegant at first... Interested in hearing all of your
> feedback on the issue.
> Best Regards,
> Mono-list maillist - Monofirstname.lastname@example.org