From: Vladimir Lushnikov
Can I ask a slightly unrelated question - does Mono actually generate
unique GUID's at the moment? I use them for a generic collection of
"worker" sockets in a server, so wondering if they are unique enough to be
used there in Mono (I know it works in .NET).
GUID's are generated using the same concepts as in MS.NET. So you can use
Guid.NewGuid() in Mono as well. Note that we are talking about Type.GUID
property that is generated based on the type not randomly.
From: Robert Jordan
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.
If you can figure out the exact algoryth used by MS.NET we can generate
Type.GUIDs. And I think performance isn't important for this property.
Kornél
----- Original Message -----
From: "Robert Jordan" <[EMAIL PROTECTED]>
To: <mono-devel-list@lists.ximian.com>
Sent: Saturday, September 03, 2005 11:45 PM
Subject: Re: [Mono-dev] Type.GUID patch
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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Robert Jordan" <[EMAIL PROTECTED]>
Cc: <mono-devel-list@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" <[EMAIL PROTECTED]>
To: "Robert Jordan" <[EMAIL PROTECTED]>
Cc: <mono-devel-list@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: [EMAIL PROTECTED]
blog: http://pages.infinit.net/ctech/
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
