Изучение C или более низкий язык уровня могут определенно быть полезными. Однако я не вижу очевидного преимущества в использовании неуправляемого WinAPI.
Как вы догадались, они оба представляют одно и то же значение. Разница в форматировании; DirectoryEntry.NativeGUID
отображается в порядке обратного порядка байтов (без тире), как он хранится «изначально» в службе каталогов, а UserPricipal.GUID / DirectoryEntry.GUID
отображается в большом -индийский порядок (с тире). Подробнее см. Статью в Википедии о Endianess .
Поэтому, когда вы распечатываете значение для NativeGUID (строка), оно не должно показывать дефисы (как в вашем примере), если вы не создаете новый GUID, используя строка как входная ( Guid ng = new Guid (de.NativeGuid);
). Это создаст некоторую путаницу ...
Важно не смешивать эти два идентификатора при сохранении идентификаторов GUID во внешнем источнике данных или хранении NativeGUID в качестве GUID с прямым порядком байтов.
Я бы выбрал UserPricipal.GUID / DirectoryEntry.GUID, потому что так атрибут objectGUID отображается с помощью большинства инструментов управления Windows (таких как Active Directory Users and Computers и ADSI Edit) и как он хранится и отображается в SQL Server при использовании типа данных uniqueidentifier
. Также; вам нужно будет перейти «ниже» UserPrincipal ( GetUnderlyingObject ()
), чтобы получить значение NativeGUID (или преобразовать свойство UserPrincipal.GUID в little-endian).
Так что, я думаю, вы необходимо решить, переносить ли существующие «внешние» данные в формат GUID или продолжать использовать формат NativeGUID. Прямо сейчас я