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

Raja R Harinath harinath at hurrynot.org
Wed Apr 30 15:36:14 EDT 2008


Hi,

"Gert Driesen" <gert.driesen at telenet.be> writes:

> 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.
>
> 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.

This is partly due to the way we implement linking inside the build
tree.  We use a 'MONO_PATH=$(topdir)/class/lib/$(PROFILE)' override
to bypass the GAC and force the use of the just-built dlls.

GMCS can refer to these C# 3.0ish libraries, thus requiring us to build
them in the 2.0 profile.

> Currently some .NET 3.5 assemblies are part of the 3.5 profile directory
> (eg. System.Web.Extensions.Design, and all of olive), and some are part of
> the 2.0 profile (see above).
>
> 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).

My understanding is that the 3.5 profile is not complete, but is an
add-on to the 2.0(sp1) profile (except for System.Web.Extensions).

> 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 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.

I would rather totally avoid (most of) the net_3_5 profile in the mcs/
tree, and build everything in the net_2_0 profile -- use net_3_5 _only_
for System.Web.Extensions.

- Hari



More information about the Mono-devel-list mailing list