A cool feature of Visual Studio 2010 is the ability to have configuration files that are build configuration specific. Handling build configuration specific config files was always a challenge in the past where one had to store multiple config files for a dev environment versus a staging environment versus a production environment.

For example, a dev environment specific conf file would store the connection string to your dev database and the production envirnment web.config would store the connection string to your production database. Now when you moved your code between environments, you would have to make sure that the correct config file is copied over and that your production environment code is not accidentally pointing to your dev database.

This problem is solved by visual studio 2010 that allows cbuild configuration specific config files. In VS 2010, whenever you create a new web application project now, you'll see that your web.config in your solution explorer actually appears as an expandable node. When you expand it, you will see multiple configuration files for each of your build configurations, that can hold different values for each configuration.

Now when you build your application in a specific build configuration, the correct web.config settings get applied. Similarly when you publish, the correct web.config settings get published.

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.