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

Jb Evain jb at nurv.fr
Thu May 1 03:30:15 EDT 2008

Hey Miguel,

On 5/1/08, Miguel de Icaza <miguel at novell.com> wrote:
> The problem with this discussion is that you guys did not understand the
>  reason for the current split.

That's not very fair, i think we do.

The main point was saying that currently, for the traditional .net
aware programmer, coming from windows, and being used to the Microsoft
terminology and versions, it's confusing to have assemblies from the
.net 3.5 release in different profiles. And we were just wondering if
we could improve one that.

And the small discussion we had, was mainly about finding a way to
reduce the confusion.

I understand that there's no way in moving Sys.Core around, which is
probably the biggest source of questions, (why Sys.Core is not in the
3.5 profile), because you would simply not be able to reference it.

The biggest issue I have right now with the 3.5 profile, is that I
have a bunch of libraries in it that should go to the 2.0 profile if
we want to be  consistent (but maybe my installation folder is bloated
with old stuff).

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

Somehow, this particular issue is not much related to the previous
issue. This one is about the confusion of using mcs/gmcs,
ilasm1/ilasm2, al1/al2, etc.

One suggestion was to have shell scripts that always launch the last
version installed. Like a ilasm script that would launch ilasm2 if
installed, or ilasm1.

I don't understand why you think it's an horrible idea, while last
time I heard, you were supporting the idea of having such a script for

Jb Evain  <jb at nurv.fr>

More information about the Mono-devel-list mailing list