When developing a custom field type using VseWSS 3.0 v1.3, I encountered a strange problem. The field type compiled successfully and deployed successfully as well, but whenever I tried to use the custom field type, I just got a generic error in SharePoint: “Field type <blah> is not installed properly. Go to the list settings page to delete this field.” Looking into the event log, the SharePoint logs and the vsewss log didn’t come up with anything useful either.
After searching a while online and coming up with a bunch of different solutions documented by other people, I found nothing worked. I went back to reading the VseWss 3.0 v1.3 release notes a couple of times over; especially the following couple of lines under the “Known Issues” section:
-
Custom Field Controls
- During packaging additional XML configuration code will be added to the fldtypes_FieldControlName.xml file. To ensure the correct deployment of your field control you must add (if not already present) and Guid attribute to your SPField derived class.
Example:[Guid("f5627588-e216-402e-844f-f85a0db34aa5")]
public class MyFC1Field : SPFieldText
- After packaging your project you must modify the fldtytypes_FieldControlName.xml file and synchronize the following element with your class's Guid:
<Field Name="FieldTypeClass">f5627588-e216-402e-844f-f85a0db34aa5</Field>
· Field control items are not able to be deployed due to a GUID being inserted instead of the type in the XML. This is a known issue , you can manually add the correct entry which will result in two entries in the fldTypes*.xml file
I wasn’t entirely sure what this meant by when comparing the fldtypes_blah.xml that gets generated for the field type at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML and the fldtypes_blah.xml in my vsewss project, there was a difference.
The vsewss fldtypes_blah.xml contained:
<?xml version="1.0" encoding="utf-8"?>
<FieldTypes>
<FieldType>
<Field Name="TypeName">LogFieldFieldControlField</Field>
<Field Name="TypeDisplayName">LogFieldFieldControlField</Field>
<Field Name="TypeShortDescription">LogFieldFieldControlField</Field>
<Field Name="ParentType">Text</Field>
<Field Name="UserCreatable">TRUE</Field>
<Field Name="FieldTypeClass">b2931c02-1f9c-4eeb-8839-421be14a38d5</Field>
</FieldType>
</FieldTypes>
The generated fldtypes_blah.xml that gets put in the 12 hive contained:
<?xml version="1.0" encoding="utf-8"?>
<FieldTypes>
<FieldType>
<Field Name="TypeName"BlahFieldControlField</Field>
<Field Name="TypeDisplayName">BlahFieldControlField</Field>
<Field Name="TypeShortDescription">BlahFieldControlField</Field>
<Field Name="ParentType">Text</Field>
<Field Name="UserCreatable">TRUE</Field>
<Field Name="FieldTypeClass">blah.blahcontrolfield</Field>
</FieldType>
</FieldTypes>
Looks like the FieldTypeClass field node that contained the guid of the field type class gets replaced by the class name on deployment. But the class name is not fully qualified like most manual steps state that it should be.
I replaced it in the deployed fldtypes_blah.xml so that the xml node now looked like:
<Field Name="FieldTypeClass">Blah.BlahFieldControlField, blah, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8adae1dce348f885</Field>
i.e. the value is namespace.classname, assembly name, version, culture, publickeytoken
Then restart IIS
that got my custom field type working. So what you need to do is deploy the solution using vsewss 3.0 v1.3, then go into C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML, find your fldtypes_blah.xml and replace the FieldTypeClass node text which contains the class name to contain the fully qualified class name. Then restart IIS. So far this is what has worked for me, but if I come up with a better way, I’ll update this post.
Subscribe