Guids - love them or hate them? The simple fact is that you will find them practically everywhere you look. Especially if you're building a solution on top of SharePoint.
You need guids for Solutions, Features, Content Types, and so forth. Everyone knows that any SharePoint developer is going to working with Guids day in and day out.
What's the single biggest problem in working with using Guids? For most folks, they seem like a bunch of random digits and characters. The randomness makes sense... they is their intended nature.
Second worst thing about Guids? SharePoint's error reporting system sometimes will give you nothing more than Guid of the offending element.
So... You're left there with some cryptic error message staring you in the face. Right off the bat, confusion sets in because if you're like me, Guids aren't easy to remember. Worse yet, if your SharePoint project is fairly large, then the number of Guids that you've come in contact can be quite large. The entire experience can be frustrating because before you can even start to figure out what may have happened, you need to take time out to go figure out if that Guid is related to something you've specifically created or simply utilized.
It's time to take control of your Guids!
Over the past year, I've been working with a Guid classification system that tremendously aids both the construction and debugging phases of any development project. More to the point, when SharePoint throws you a bare bone error message, you can look at the Guid and immediately determine a lot of information from the Guid itself.
Let's first breakdown a Guid so that we can leverage its structure:
- There are 5 groups of numbers (8 digits, 4, 4, 4, and 12, respectively).
- The numbers are hexadecimal
- Guids are by design supposed to be both random and unique
The classification system I'll describe relies on each of these points, with the exception of the last where we will reduce the randomness yet maintain uniqueness.
The advantage of taking control of your Guid structure is …
- It's super easy to identify Guids as yours no matter where the error appears (on a page, custom app, ULS logs)
- General structure and dependencies are easy become easier to identify
- General editing of source data also becomes easier to maintain and track
Starting from the left group, I like to classify each group of numbers within a Guid as listed below and illustrated on the right:
View full size image
- Company ID
- Client ID
- Project ID
- SharePoint Category
- Item categorization
If you aren't too worried about tracking every aspect of your Guids, then the following image presents a partial system.
View full size image
The partial classification assumes the first 3 groups are left untouched (i.e. you use whatever is spit out by your Guid generator) but you can still take benefit by controlling the last two group of numbers.
For the both SharePoint Category and Item Categorization buckets, the final values use a combination of hex alpha letters (A-F) to identify entities and hex numeric values (0-9) to identify instances of entities. For example, if your project contains multiple Features, then the SharePoint Categorization group would contain values such as F001, F002, F003, etc. Note how the "F" represents a "Feature". You could likewise choose to represent Solutions (D for deployed), Event Receivers (E for event), etc.
The Item Categorization bucket would follow the same paradigm. For example, Content Type #1 would be represented by "0000000000c1", Field #11 would become "000000000fB", etc.
How does this relate to Content Type IDs? The classification system makes it easy to create and track Content Type IDs as well.
Content Type IDs are not nearly as mean and ugly as everyone makes them out. There are a few key rules when creating Content Type ID...
- Each Content Type must inherit from another Content Type. This inheritance is explicitly defined in the ID itself.
- Each ID length must by divisible by 2 (good info for double-checking anything you've created).
- Each child is defined by one of two methods...
- The ID is an extension of the parent plus 2 digits.
Example: Document inherits from Item. Item is 0x01 and Document is Item+01 or 0x0101.
- The ID is an extension of the parent plus 00+guid
Example: System Page Layout inherits from Document thus the ID is 0x01010007FF3E057FA8AB4AA42FCB67B453FFC1.
Best practices dictate that whenever creating a custom Content Type, you should use the 00+ method. Thus, your old friend the Guid immediately comes into play whenever a direct derivation of an out of box type is made (as illustrated with the System Page Layouts ID). Once you've stemmed your own branch, you can easily use the 2 digit inheritance model for your IDs as shown below.
As the diagram shows, it's pretty easy to determine the exact tree structure from the content type id "0x0102002A7FFAB099034B25F0040000000000C0c2c1". You can spot the branch guid (2A7FFAB099034B25F0040000000000C0) and the two descendants (c2, c1). And, of course, the ancestors (0102).
Tracking the errors in the ULS logs is made simpler too... it’s pretty easy to determine not only if the error is related to something you created (taken from “2A7FFAB0” signature - aka company signature) but you can rapidly determine
1. the physical location (feature #4)
2. the problem lies with a content type
At the source management level, I also find the categorization system makes it easier to track and edit items.
Give it a try... I hope that the categorization system works just well for you as it does for my team.
-Maurice