Archive for April, 2009

Musings on Site Columns

April 15, 2009 Leave a comment

For some reason it doesn’t appear possible to create a Site Column of type “Integer”, even though it appears as a valid Field type according to the Field Element (List – Definition) documentation on MSDN.

Integer doesn’t appear as an option for the type on the New Site Column page and, if created via an XML defintion file, then it will not appear on the Site Columns gallery. It can however be used when defining a custom Content Type or List Definition.

More details are to be found in the Community Content at the foot of the page linked to above.


External HDDs are your friend

Developing SharePoint solutions often involves running a virtual machine with a server operating system, SQL Server instance and SharePoint installed – all of this on hardware designed to run a client operating system. As you can imagine, this isn’t going to run very quickly.

However there is a simple and inexpensive way in which you can dramatically improve system performance – use a second HDD.

SharePoint and SQL Server talk incessently to one another and most operations involve some measure of disk IO; things are made worse as soon as the host operating system also wants to use the disk. A fast multi-core CPU and RAM aren’t going to help much if the system is suffering from long disk read/write times.

A simple solution to this is to have a second physical hard-disk dedicated to the virtual environment. Even if this is an external hard-disk connected via USB or e-SATA, it can still make a considerable difference.

Another advantage of the dedicated hard-disk is that it can be quickly defragmented. The large files used by virtual machines very quickly become fragmented and degrade system performance. Schedule a defrag of the dedicated drive in the morning before starting up the virtual envrionment; grab a coffee and read some email whilst it completes then enjoy the increased performance during the working day.

Using VSeWSS to create a List Definiton based on a Content Type

April 1, 2009 3 comments

Having created a custom content type, I wanted to use it in a series of list definitions and chose to use the VSeWSS List Definition from Content Type template to acheive this. This VSeWSS template provides a straightforward way to create list definitions based upon a custom content type within the same solution.

Unfortunately, although the lists could be provisioned successfully, it proved interesting to effect any edits to the schema.xml file. Whilst I was able to determine cause and solve the issues, I thought it may be of value to record the symptoms in case anyone else runs into the same problems and therefore can apply the same corrective measures…

Any changes to the All Items view appeared to be ignored and only the default ‘LinkTitle’ and ‘Attachments’ fields are displayed. If, on the other hand, I created a distinct content type for each list definition then it was possible to specify additional fields in the view. I had however hoped to re-use the same content type for all lists.

Also it didn’t appear to be possible to change the display name of the field from that defined within the source site column. Even though the Content Type specified a different display name for the site column, the actual provisioned list only ever used the value defined in the list definition. This appeared to be a result of having to specify the site column in the list definition using a <Field> rather than <FieldRef> element.

When specifying the list definition using a <ContentTypeRef> element within the schema.xml file, it appeared that whatever was set for the first list in the VSeWSS solution effected all lists that used that combination of Content Type and Site Columns.

The reason the above behaviour was experienced is because I’d forgotten to change the Type property to a unique value for each of the lists. Thus a change to the first list definition was reflected in all lists.

The Type property is set to 100 by default for all lists created using VSeWSS; it is essential that each list should have a unique Type so this value should be one of the first things that you edit in the ListDefinition.xml and Schema.xml files.

Alternatively using the SharePoint Solution Generator to produce a list definition from a list created via the UI based upon the custom content type does appear to work (changing the display name and editing the columns displayed in the All Items view) but this is a long route for what should be a simple enough task.

Examining the schema.xml produced by the SharePoint Solution Generator shows that the list defines it’s own list content type based upon the parent site content type; thus it uses a <ContentType> section rather than a <ContentTypeRef> section.

However it is worth noting that the SharePoint Solution Generator also sets the Type to be 100 and this should be set to a unique value within the scope of your farm.

Regardless of how the list definition uses the content type, whenever the site column is updated the changes overwrite whatever is defined in the site content type and effects the list directly.