Guid Byte Order in .NET

It appears that MS are storing the five parts in a structure. The first 4 parts are either 2 or 4 bytes long and are therefore probably stored as a native type (ie. WORD and DWORD) in little endian format. The last part is 6 bytes long and it therefore handled differently (probably an array).

Does the Spec state that the GUID is stored in big-endian order, or that the storage of parts are in that order but the indiviual parts may be implementation specific?

EDIT:

From the UUID spec, section 4.1.2. Layout and Byte Order (emphasis mine):

To minimize confusion about bit assignments within octets, the UUID
record definition is defined only in terms of fields that are
integral numbers of octets. The fields are presented with the most
significant one first.

...

In the absence of explicit application or presentation protocol
specification to the contrary, a UUID is encoded as a 128-bit object, as follows:

The fields are encoded as 16 octets, with the sizes and order of the fields defined above, and with each field encoded with the Most Significant Byte first (known as network byte order).

It might be that MS have stored the bytes in the correct order, but have not bothered to network-to-host order the WORD and DWORD parts for presentation (which appears to be ok according to the spec, at least by my unskilled reading of it.)

I'm no expert here, but the Wiki page you mention, also says:

However, the reference for a commonly[4] used structure of the data type doesn't mention byte ordering

That citation ([4]) points to http://msdn.microsoft.com/en-us/library/aa373931(VS.85).aspx which subsequently identifies how Microsoft implement a GUID as

typedef struct _GUID {
  DWORD Data1;
  WORD  Data2;
  WORD  Data3;
  BYTE  Data4[8];
} GUID;

since the last 8 bytes are stored as a byte array, I think this identifies the behaviour you are seeing.