[Mono-devel-list] [PATCH] Profile 2.0 assembly versions

Kornél Pál kornelpal at hotmail.com
Thu Jul 28 18:41:36 EDT 2005


I agree with you that this a better idea but I will never try to submit such
a big patch for proposal because it would change too much code and it
figured out that it is nearly impossible to make any major change to Mono
because if there are no mistakes and errors in the patch itself an endless
list can be created about things that should be done before the patch can be
comitted altought they don't block the patch in fact.

I see a lot of things in Mono that sould be made more reliable using some
centralization but I don't want to create n+1 wariants of this patch.

I reported the problem, I proposed a patch, the patch seems to be correct
(because no notices were provided regarding the patch itself). If you want
to do hundreds of things that are not required to apply the patch before
applying the patch it's up to you but I don't want to solve all the problems
you can imagine just to commit this patch.

Anyway I think having different verion numbers than MS.NET is a more
critical issue than having a weakly centralized assembly referencing

Note that the references in System.Web.UI.WebControls are in NET_2_0 only
code blocks and these references are not in other versions. This seems to be
consistent practice in System.Web.UI.WebControls. Centralizing the assembly
reference could save some disk space but currently it is not required. It
will be required when a new (post 2.0) .NET Framework version will be
released but currently even 2.0 was not released yet so it will be in the
distant future.


----- Original Message -----
From: "Ben Maurer" <bmaurer at ximian.com>
To: "Andreas Nahr" <ClassDevelopment at A-SoftTech.com>
Cc: "Kornél Pál" <kornelpal at hotmail.com>; "Miguel de Icaza"
<miguel at ximian.com>; <mono-devel-list at lists.ximian.com>
Sent: Friday, July 29, 2005 12:11 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions

> On Fri, 2005-07-29 at 00:07 +0200, Andreas Nahr wrote:
>> No Consts.cs aren't automatically generated.
>> The problem is, that several Attributes of classes in System.Web do not
>> use
>> the consts scheme, and about one third of your (BIG) patch is just for
>> changing these Attributes.
>> We will then have to change these again later, so it might make sense do
>> do
>> it now instead of doing it twice (and adding lots of changelog entries
>> twice).
> If we really want to be clever, and avoid doing things twice, we can put
> this:
> internal class MonoConsts {
> #if ...
> public string FXVersion = ...
> #elif ...
> ...
> #endif
> }
> in the common build directory. This way, the next time we need to target
> another FX, we don't have to do it in 100 places.
> The Const.cs is probably still a good idea, since it is really ugly to
> have those magic names lying around the source code.
> -- Ben
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

More information about the Mono-devel-list mailing list