Alternatives to "Guid"

[Jack Brown]

Hi there,

I need to create a unique identifier for my own internal needs and am happy
to rely on "Guid.NewGuid()" to pull this off. I'd like to know if .NET
offers any competing alternative however. Perhaps there's something with a
richer set of functions for instance and it might offer potential advantages
over a GUID. Am just exploring the possibilities for now. Thanks in advance.

 

[Marc Gravell]

You haven't qualified the requirement very much...

If it for internal purposes, then a simple integer / long incremented
in a thread-safe manner (either lock or interlocked) would suffice
(although you haven't mentioned volume). Guid works for most other
scenarios. Avoid DateTime based solutions; the resolution is simply
not high enough for volume work. If you want bona-fide (verified)
uniqueness over either a persistant system or a cluster or servers,
then a database is the way to go; either with an identity column (if
guessing isn't a security issue), or a GUID with a unique constraint.

What "richer set of functions" are you looking for?

Marc

 

[Guest]

..NET Framework does not, to my knowledge, offer any "built-in" alternatives
to Guid. It really depends on "how unique" you want your numbers to be. A
Guid is a 128 bit number and the chances of a duplicate ever being generated
-- not just in your lifetime -- but EVER - is 1 in the billions.

If you want shorter numbers or strings that will be cryptographically unique
but not as "globally unique" as a Guid, you could use code like this:

private string GetUniqueKey()
{
int maxSize = 8 ;
int minSize = 5 ;
char[] chars = new char[62];
string a;
a = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890";
chars = a.ToCharArray();
int size = maxSize ;
byte[] data = new byte[1];
RNGCryptoServiceProvider crypto = new RNGCryptoServiceProvider();
crypto.GetNonZeroBytes(data) ;
size = maxSize ;
data = new byte[size];
crypto.GetNonZeroBytes(data);
StringBuilder result = new StringBuilder(size) ;
foreach(byte b in data )
{ result.Append(chars[b % (chars.Length - 1)]); }
return result.ToString();
}

-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net

 

[Jack Brown]

If you want shorter numbers or strings that will be cryptographically

unique
but not as "globally unique" as a Guid, you could use code like this:

private string GetUniqueKey()
{
int maxSize = 8 ;
int minSize = 5 ;
char[] chars = new char[62];
string a;
a = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890";
chars = a.ToCharArray();
int size = maxSize ;
byte[] data = new byte[1];
RNGCryptoServiceProvider crypto = new RNGCryptoServiceProvider();
crypto.GetNonZeroBytes(data) ;
size = maxSize ;
data = new byte[size];
crypto.GetNonZeroBytes(data);
StringBuilder result = new StringBuilder(size) ;
foreach(byte b in data )
{ result.Append(chars[b % (chars.Length - 1)]); }
return result.ToString();

Thanks very much. I'll take a look at this and "RNGCryptoServiceProvider" in
particular to see what it offers. Thanks again.

 

[Jack Brown]

Thanks for the feeback.

You haven't qualified the requirement very much...

I need to store a unique value in a (DataSet) file I'm creating. Each time
the file is created via "DataSet.WriteXml(), a unique ID will be stored in
one of the tables. This way, any and all copies of the file will contain the
same unique ID (so they're all linked via this ID).

If it for internal purposes, then a simple integer / long incremented
in a thread-safe manner (either lock or interlocked) would suffice
(although you haven't mentioned volume). Guid works for most other
scenarios. Avoid DateTime based solutions; the resolution is simply
not high enough for volume work. If you want bona-fide (verified)
uniqueness over either a persistant system or a cluster or servers,
then a database is the way to go; either with an identity column (if
guessing isn't a security issue), or a GUID with a unique constraint.

A random integer or the date/time actually works very well in practice.
Chances of a collision is very remote depending on the volume of activty (as
you pointed out). It will likely work in my case but space is cheap so a
GUID is clearly preferable.

What "richer set of functions" are you looking for?

I was just exploring the possibilities. If there was an alternative then it
might have offered something that could have proved useful either now or
later. Sometimes new and better ideas surface when you explore the latest
APIs. Anyway, thanks again.

 

[Marc Gravell]

Fair enough; personally, in this scenario I'd stick with guid and move
on ;-p

Marc

 

[Jack Brown]

Fair enough; personally, in this scenario I'd stick with guid and move

on ;-p

And I probably will. I find it takes me twice as long to develop in .NET
compared to the WinAPI so I have little time to waste. Thanks again.

 

[Marc Gravell]

You genuinely surprise me. I've always found it the other way. In
particular, it takes me significantly less time to *debug*,
particularly if I stick mostly to managed classes.

Marc

 

[Peter Duniho]

You genuinely surprise me. I've always found it the other way. In
particular, it takes me significantly less time to *debug*,
particularly if I stick mostly to managed classes.

But he wrote "develop", not "debug".

Fact is, I can relate. I've only been doing .NET stuff for about a year.
I've been doing Windows programming for almost twenty. I find that much
of my time writing .NET stuff is spent poring over the documentation
trying to figure out just what .NET class, method, and/or property I need
to use in order to do what I want. If I were doing the same thing in the
native Windows API, I would already know how to do what I want, and mostly
I'd just have to type it in.

Obviously this will change over time, as I become more familiar with
..NET. And obviously for someone with enough experience in .NET
programming, development can go much more quickly. Certainly for me, I
expect that once I've had a lot more experience writing .NET, development
will go much more quickly than the native Windows programming, since I
have found that writing native Windows stuff I spend an inordinate amount
of time just hooking up the UI, implementing all that stuff that goes into
a window proc. .NET has lots of other time-saving stuff in it as well,
but frankly the native Windows API has IMHO done a decent job of
simplifying a lot of the other stuff already. It's mostly in the UI stuff
that very little has changed and been streamlined over the years, and so
the ease with which a user-interface can be put together in .NET is a huge
boon and time-saver.

But for now, because of how hard it is to find what one's looking for so
often, I find .NET development goes fairly slowly a lot of the time,
relative to what would be possible for me in native Windows.

Maybe that's what he meant.

Pete

(sometimes I wish the .NET documentation had some kind of native Windows
cross-reference, where I could just look up the function I'd use in the
native Windows API and it would tell me the equivalent in .NET. Heck, if
they'd just add a .NET link to each of the regular Windows API doc pages,
that would be good enough for me).