Hi Sebastien,
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.
MSFT's implementation (actually an InternalCall) is 3 times slower
then the computation of an MD5 hash using an *unmanaged* implementation
of the MD5 algorithm. It's probably slower because it has to generate
properly formatted UUIDs which consists of only 122 random bits.
(see the 2nd link of Kornél's post).
Ok, I don't think it's worthwhile to provide an unmanaged InternalCall
for a property that obviously nobody uses.
Rob
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
