[Mono-dev] Type.GUID patch
Robert Jordan
robertj at gmx.net
Sat Sep 3 17:45:32 EDT 2005
Hi,
for the records: the automatically generated Type.GUID
is a Version 3 UUID, see
http://www.webdav.org/specs/draft-leach-uuids-guids-01.txt
To generate a MS compatible Type.GUID we'd need the so
called "name space ID" used by MS.
Rob
Kornél Pál wrote:
> This explains how GUIDs are generated but it doesn't mention the actual
> hash
> algorytm used to generate GUID from the mentioned components:
>
> http://blogs.msdn.com/adam_nathan/archive/2003/10/19/56779.aspx
>
> And GUID has a specification that should be followed when generating GUIDs.
> There are standard descriptions but this MS centric enough to can provide
> compatiblity with MS.NET:
>
> http://msdn.microsoft.com/library/en-us/dnnetcomp/html/PPCGuidGen.asp
>
> Kornél
>
> ----- Original Message -----
> From: "Kornél Pál" <kornelpal at hotmail.com>
> To: <sebastien.pouliot at gmail.com>; "Robert Jordan" <robertj at gmx.net>
> Cc: <mono-devel-list at lists.ximian.com>
> Sent: Saturday, September 03, 2005 9:51 PM
> Subject: Re: [Mono-dev] Type.GUID patch
>
>
>> Hi,
>>
>> Type.GUID is useful only when using COM interop. Of course there may be
>> other uses but I don't tink it is needed for anything else.
>>
>> GUIDs are identifiers in COM so I think we should not implement a
>> different
>> algorythm just to return some value. I think it's better to throw an
>> exception for type that have no GuidAttribute instead of returning some
>> forged value that is different from MS.NET type GUID.
>>
>> I think performance is not so important regarding this property as it is
>> called rarely. But if we want to speed up GUID property it can be cached
>> in
>> a private field.
>>
>> Kornél
>>
>> ----- Original Message -----
>> From: "Sebastien Pouliot" <sebastien.pouliot at gmail.com>
>> To: "Robert Jordan" <robertj at gmx.net>
>> Cc: <mono-devel-list at lists.ximian.com>
>> Sent: Saturday, September 03, 2005 7:09 PM
>> Subject: Re: [Mono-dev] Type.GUID patch
>>
>>
>>> Hello Robert,
>>>
>>> On Sat, 2005-03-09 at 17:00 +0200, Robert Jordan wrote:
>>>
>>>> The hash appears to change with the assembly name and type name.
>>>> Renaming gt.cs will return another GUID as well as renaming
>>>> "App". Renaming gt.exe doesn't change the GUID.
>>>> Applying an AssemblyVersionAttribute will change the GUID,
>>>> so I'm pretty sure, that Type.AssemblyQualifiedName is taken
>>>> into account while generating the hash.
>>>>
>>>> The following algorithm computes the GUID from
>>>> Type.AssemblyQualifiedName using a MD5 hash:
>>>>
>>>> Guid ComputeGuid (Type t)
>>>> {
>>>> byte[] bytes = System.Text.Encoding.UTF8.
>>>> GetBytes (t.AssemblyQualifiedName);
>>>> using (System.Security.Cryptography.MD5 md5 =
>>>> System.Security.Cryptography.MD5.Create ()) {
>>>> return new Guid (md5.ComputeHash (bytes));
>>>> }
>>>> }
>>>>
>>>> Is it a patch worth?
>>>
>>>
>>> I guess it depends on how it's gonna be used. This isn't the first time
>>> people talks about Type.Guid but I never seen any talk about _using_
>>> it ;-) at least not with Mono.
>>>
>>> MD5 will give you a 128 bits digest value, which match the required Guid
>>> length, and recent problems related to MD5 are pretty much irrelevant to
>>> such usage. So it's probably (if everything is included in the qualified
>>> name) a correct implementation - functionality-wise.
>>>
>>> But creating a using MD5 is kind of heavyweight - even more if a new
>>> instance is created each time. So anyone using this heavily will notice
>>> a big performance problem.
>>> --
>>> Sebastien Pouliot
>>> email: sebastien at ximian.com
>>> blog: http://pages.infinit.net/ctech/
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>
>> _______________________________________________
>> 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