Does LurchTable depend on the implementation of new Guid(byte[]) and guid.ToByteArray()?

[NightOwl888]

I am upgrading my project to .NET Core 2.0 and discovered that the LurchTable tests have a method that depends on the implementation of new Guid(byte[]) and guid.ToByteArray():

        private static Random random = new Random();
        private static int iCounter = 0x01010101;

        public static Guid NextHashCollision(Guid guid)
        {
            var bytes = guid.ToByteArray();

            // Modify bytes 8 & 9 with random number
            Array.Copy(
                BitConverter.GetBytes((short)random.Next()),
                0,
                bytes,
                8,
                2
            );

            // Increment bytes 11, 12, 13, & 14
            Array.Copy(
                BitConverter.GetBytes(
                    BitConverter.ToInt32(bytes, 11) +
                    Interlocked.Increment(ref iCounter)
                    ),
                0,
                bytes,
                11,
                4
            );

            Guid result = new Guid(bytes);
#if !NETCOREAPP2_0
            Assert.AreEqual(guid.GetHashCode(), result.GetHashCode());
#endif
            return result;
        }

The assert fails in .NET Core 2.0 because the underlying implementation has changed. What I am wondering is if there is some dependency of LurchTable on the Guid generation algorithm, or if this is just for testing? What reference you were following to come up with this logic?

Removing the offending assert and the TestNextHashCollision test seems to have no effect on the results of other tests, but I just wanted to be sure there isn't anything special about the design of LurchTable that relies on the Guid creation algorithm.

[csharptest]

I don't recall any explicit dependency on Guid at all... The test above is using the Guid class to create duplicate value for .GetHashCode() while keeping the .Equals() false. This could be just as easily coded as an independent class instead of leveraging Guid.