Know Your 12 Hive – fields and ctypes

The 12 hive contains a wealth of information for the intrepid SharePoint developer. It is located on the disk at Program FilesCommon FilesMicrosoft Sharedweb server extensions12. All of the features installed on a given SharePoint server are located within the 12 Hive in the TEMPLATEFEATURES folder.

This example comes from a WSS install a MOSS server has many more features.

The two highlighted folders in the picture above are the features that implement the global site columns and field types available on every SharePoint site. The reason they are always available is that they are activated by the GLOBAL site definition and the GLOBAL site definition is always applied to every new site before the specific site definition’s instructions.

Here is a snippet of the piece of GLOBAL ONET.xml file that activates these two features. You can find it in the 12 hive too! It’s at TEMPLATEGLOBALXML.


 

<SiteFeatures>

<!– Fields –>            

<Feature ID="CA7BD552-10B1-4563-85B9-5ED1D39C962A" />

<!—ctypes –>

<Feature ID="695B6570-A48B-4A8E-8EA5-26EA7FC1D162" />

</SiteFeatures>

This means that you can safely assume that the columns and content types defined by these features are always available for your own use.

These files make great references when you begin creating your own field (site column) features and content types. This is especially true of content types because you can get the ID’s of any of the common fields directly from the field feature’s element manifest, fieldswss.xml.

For example, say you need to know the ID of the Comments site column. It’s right there in fieldswss.xml!

Want to create your own content type? Navigate in the 12 hive to TEMPLATEFEATURESctypes and open ctypeswss.xml.

Here is a bit of this file that shows the definition of the XMLDocument content type:

<ContentType ID="0x010101"

Name="$Resources:XMLDocument"

Group="$Resources:Document_Content_Types"

Description="$Resources:XMLDocumentCTDesc"

V2ListTemplateName="xmlform"

Version="0">

<FieldRefs>

<RemoveFieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" />

<FieldRef ID="{5d36727b-bcb2-47d2-a231-1f0bc63b7439}" Name="RepairDocument" />

<FieldRef ID="{11851948-b05e-41be-9d9f-bc3bf55d1de3}" Name="ShowRepairView" />

<FieldRef ID="{4b1bf6c6-4f39-45ac-acd5-16fe7a214e5e}" Name="TemplateUrl" />

<FieldRef ID="{cd1ecb9f-dd4e-4f29-ab9e-e9ff40048d64}" Name="xd_ProgID" />

</FieldRefs>

</ContentType>

You can tell from the ContentType ID that this inherits from System (0x), Item (0x01), and Document (0x0101). You can also see that this type removes the Title field it inherited from Item using the RemoveFieldRef element.

  

Author: Doug Ware

Free SharePoint Training at .NET-U

If you are a developer interested in learning more about SharePoint, but don’t know where to start, check out the free course over at .NET University.

There are four modules:

  • Installation
  • What’s New
  • Core Concepts
  • Web Parts

I am thrilled to have had the opportunity to contribute to this effort. If you’ve been thinking about taking one of our classes privately or attending the road-show, but need a little taste of my teaching style, check out the Core Concepts video. It’s very high-level, but I think it came out great and I hope you will agree!

–Doug Ware

Atlanta .Net User Group Monday, April 28, 2008 at 6:00 PM

6:00

Networking and Refreshments

6:30

Announcements

7:00

Technical Presentation


What’s New in CSLA .NET 3.5?

Speaker: Rockford Lhotka

CSLA .NET is one of the most widely used open-source development frameworks for .NET. Version 3.0 added support for WPF, WCF and WF, while version 3.5 adds support for LINQ, and perhaps more importantly, focuses on code reduction and simplification. In many cases a developer has to write 30-40% less code to create a business object than in past versions! In this session you will learn how CSLA .NET supports WCF for client/server and service-orientation, WPF for powerful new user experiences, WF for back-end workflow processing, LINQ for reshaping data and data access and more!

About the speaker:  Rockford Lhotka (www.lhotka.net) is the author of several books, including the Expert VB and C# 2005 Business Objects books and related CSLA .NET framework. He is a Microsoft Regional Director, MVP and INETA speaker. Rockford is the Principal Technology Evangelist for Magenic (www.magenic.com), a Microsoft Gold Certified Partner.

Meeting Location and Directions

Microsoft Corporation
1125 Sanctuary Pkwy.
Suite 300
Atlanta, GA 30004
Directions to Microsoft

WSS 3.0 SDK Rant

My previous post was a matrix of feature scopes.

Dan Attis pointed me to the SDK page on MSDN, to which I replied, ‘Not a handy matrix!’ That content on the page mentioned was, in fact, the source of the matrix, but I got it from the SDK itself (as in the thing you install). That’s too bad, because there in the comments section in the online version was a comment that ListTemplate can scope to Site. I’ve been working around that non-existent limitation for a long time.

Now, I was curious, when was this comment made? I checked the history on the comment and discovered:

That’s right! Joel Triemstra took the time over a year ago to correct this mistake in the online content and one year later the article is still wrong.

Lessons learned?

  1. Don’t use the SDK installation because it doesn’t include the community comments.
  2. Make corrections where you can, because people will read them, if only online.

I’m very disappointed that it’s still not correct in the article body, but I can testify that there have been many corrections made over the last two SDK editions. So, I give a lot of credit where there are improvements. But, my suggestion to the SDK maintainers is: if you can’t address every comment between releases, find a way to include the comments in the installed library.

Feature Element Scope Matrix


 

Edit: ContentTypeBinding can scope to Web. I updated the matrix accordingly.

Edit: ListTemplate can scope to Site. I updated the matrix accordingly.

In the past, I was often frustrated by feature scope incompatibilities in my solutions when using ActivationDependencies. These days I almost always use a feature receiver instead (not just to handle dependencies though). Either way, remembering the compatible scopes for each element is hard on my poor brain, so I made this matrix a few months ago that I use as a reference.

Element Type

Farm 

WebApplication 

Site 

Web 

Content Type 

   

   

x 

   

Content Type Binding 

   

   

x 

x

Control 

x 

x 

x 

x 

Custom Action 

x 

x 

x 

x 

Custom Action Group 

x 

x 

x 

x 

Document Converter 

   

x 

   

   

Feature/Site Template Association

x 

x 

x 

   

Field 

   

   

x 

   

Hide Custom Action 

x 

x 

x 

x 

List Instance 

   

   

x 

x 

List Template 

   

   

x 

x 

Module 

   

   

x 

x 

Receiver 

   

   

   

x 

Workflow 

   

   

x 

   

 
 

Enjoy!

–Doug Ware

Author: Doug Ware