[Mono-dev] [PATCH] Assembly version with centralizedassembly references

Kornél Pál kornelpal at hotmail.com
Thu Aug 18 04:39:01 EDT 2005

>* Is there any reason why you did not include the comments from my original
> Consts.cs files?
> I think it should be in there, because it helped me more that one time to
> explain somebody how to use the Consts scheme in Custom Attributes.

Feel free to modify the common Consts.cs and post it to the list.

> * Moreover afaik (at least it was this way when the files were written in
> the first place) it is possible to compile with no symbols specified. Your
> patch breaks building in this case. Again please look at the original
> Consts.cs file.

I know what your version does but I don't think it's a good practice. I
added #error to break build when no version symbol is defined. If you build
the class library without any of these symbols it will result in serious
lack of code and probably other build errors so I think there is no use to
allow build without version symbols. #error is good because it explains the
reason as well. I don't see any reason to allow build without version
symbols, I treat it as a mistake.

> * Is the differentiation for static vs. sealed worth the #if code? Do we
> gain anything by using static for .Net 2.0?


static class results in no constructor and sealed abstact class in C# 2.0
that is suitable for Consts class. There is no special reson but the
resulting class will look better (there will be no private constructor). So
I don't think it should be removed just because the class library can be
compiled without this syntax as well.

> Andreas
> P.S. Do you think that currently the location for the shared files is
> suitable? imho it would be better for them to be in a directory in the
> "class" directory. Otherwise it makes the download tarball function in a
> directory absolutely useless if you just want to get the class libraries.
> (This should NOT affect this NOW)

The current location wasn't introduced by me, I originally created
mcs/class/common for Locale.cs but the patch was adapted as
mcs/build/common. Maybe it was Ben who introduced it. I agree with
mcs/build/common because it is a better location as these common files are
not just common to the class library, they are common to the entire mcs tree
(for example tools as well). So I think this directory should not be moved.


> ----- Original Message -----
> From: "Kornél Pál" <kornelpal at hotmail.com>
> To: <mono-devel-list at lists.ximian.com>
> Sent: Thursday, August 18, 2005 2:36 AM
> Subject: [Mono-dev] [PATCH] Assembly version with
> centralizedassembly references
>> Hi,
>> This patch is quite big. The patch was much smaller but you
>> wanted
>> this bigger one.:) It may be more difficult to review but will result in
>> a
>> much reliable class library.
>> It contains only assembly version related things nothing else. Note that
>> I
>> corrected all the version issues I found in any file type. For example:
>> v2.0.40607 -> v2.0.50215 (config)
>> 1:0:33000:0 -> 1:0:3300:0 (comment)
>> 1.0.3102.0 -> 1.0.3300.0 (resx)
>> I did not modify any InformationalVersion or FileVersion attributes but
>> they
>> should be modified at a later time.
>> I did not modified tests to use the common Consts.cs because they are
>> designed differently but I updated the version numbers to
>> I did not added any ChangeLog entry and I'm not going to do it by hand.
>> If
>> you want to have ChangeLog entries please let me know how can I generate
>> them.
>> To Ben:
>>>I am sick of explaining that this task is in fact quite easy.
>> The idea behind this task is easy to understand but actually it took a
>> lot
>> of hours to create this patch as all the results has to be examined even
>> with regular expressions matching only the right version numbers.
>> Kornél
> --------------------------------------------------------------------------------
>> _______________________________________________
>> 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