[Mono-dev] Mono profiles / .NET Framework versions

[Miguel de Icaza]

Hello,

> On #mono, we (jb, grendel and myself) briefly discussed that way we're
> currently splitting up assemblies and tools in profiles, and how we're
> making specific profile versions of our tools accessible.

The problem with this discussion is that you guys did not understand the
reason for the current split.

The runtime consumes assemblies from the GAC, its the only place that is
looked up at runtime.

At compilation time, the compiler loads assemblies from the same
directory where the compiler is located.   Assemblies from this
directory have one trait in common: they all share the same mscorlib at
their foundation.

The "1.0", "2.0" and "2.1" directories merely reflect the mscorlib
"foundation" and should only be used for libraries that are part of the
core runtime, not libraries that we produce and that could run on more
than one profile (1.0 libraries that can be reused on 2.0 for example).

"3.0" is a different beast, as there was no new mscorlib, it is merely a
"package" in Mono's gacutil parlance.    It is used to put a family of
libraries in the same directory, just like gtk-sharp-2.0, mono-zeroconf
and others use "packages" in this way.

This is why -pkg:dotnet works, it merely references libraries that come
from the same path where the compiler lives.

As long as there is not a new mscorlib version (not API, but version) we
will continue to keep libraries packaged in this way.

This means that all the new 3.5 libraries end up in the 2.0 directory.

> For assemblies, the consensus was to either have our profile versions
> exactly match corresponding .NET Framework versions (eg. move System.Core,
> System.Data.Linq, ... to the lib/mono/3.5 directory), or avoid confusion by
> discarding the 3.5 "profile" altogether.

There the following sets of assemblies in 3.5:

	(a) Assemblies that existed in 2.0
	(b) New Assemblies introduced in 3.0
	(c) New Assemblies introduced in 3.5
		(d) General purpose assemblies
		(e) Extensions to 3.0 (they depend on it).

Upgrades to 2.0 should go into 2.0 as we do not have any plans to
support 2.0 and 2.0 SP1 (3.5) at the same time. 

I do not particularly mind the current split, but if we want to
rationalize it, we could:

	* (d) go side-by-side with (a).
	* (e) go side-by-side with (b)

Which leaves us with 1.0, 2.0, 2.1 as foundations, and 3.0 as a
"package".

At this point though, we could just make sure that all 3.0 libraries go
into the "3.5" directory, there is no reason to keep 3.0 as a version
around anyways.

> I think it's safe to say that we'd prefer to have a real 3.5 profile (jb and
> grendel, correct me if I'm wrong).

There is no real "3.5" profile, 3.5 (or what today we call 3.0) is not a
profile, its a package.   Just like gtk-sharp is a package.

> For tools, grendel proposed to have our wrapper scripts accept a profile
> version parameter. When the parameter is not specified, the scripts would
> default to the lastest profile version. Both jb and myself liked this idea.

This is a horrible idea, but its understandable that you guys
entertained the idea, because you guys did not understand profiles
(which are foundations) vs packages. 

> This would make it easier to have a toolchain that matches MS (eg. compilers
> for both 1.0, 2.0 and 3.5 profile, instead of mixing 3.5 features in our 2.0
> compiler), without having confusing script names.

You are confused, we are not going to have 1.0, 2.0 and 3.5 compilers.

The only reason why we have 3 compilers today has to do with our
dependency on Reflection (the startup mscorlib governs the kind of
executable generated, and also because its not possible to load 2
mscorlibs at the same time plus its side effects).   

The rest of the tools should not have any problems with this, and having
a version is unnecessary (other than when the tools have actually
changed in some important behavioral way). 

> This post is only here to start the discussion.

Good idea, but other than cleaning up and rationalizing where assemblies
for 3.0/3.5 go, we are not going to make any larger changes.

Miguel.

> Hopefully this will lead to a well thought through solution.
> 
> Gert
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list