I was working on a project for a customer today and needed to build a custom field control.  Visual Studio 2010 does not have a template for creating a field control.  I thought about crafting one by hand, but then I remembered that Visual Studio Extensions for Windows SharePoint Services 1.3 has a project item for creating a field control.  At first I thought I would just copy the items over into a new Visual Studio 2010 project, but I decided to try out the VSeWSS Import Tool for Visual Studio 2010. 

Building the VSeWSS Import Tool

To get started, you need to build and install the tool.

  1. Download and install the Visual Studio 2010 SDK.  This is required to build the VSeWSS Import Tool.
  2. Download and unzip the VSeWSS Import Tool for Visual Studio 2010. 
  3. In the directory you downloaded the VSeWSS Import Tool into, find the build.ps1 file.  Right-click it and choose Properties.  In that dialog, click the Unblock button.
  4. Open PowerShell, change directory to the directory containing the build.ps1 file, and run the script.
  5. Alternatively, you can open the VSeWSSUpgradeTool/Src/VSeWSSUpgradeTool.sln file in Visual Studio 2010 and build the VSeWSSUpgradeTool.Installer project yourself.

The output from the steps above is a file called VSeWSSUpgradeTool/Src/VSeWSSUpgradeTool.Installer/VSeWSSUpgradeTool.Installer.vsix.  When you double-click on this file, it will install an extension into Visual Studio 2010.

Using the Tool

Once the tool is built and installed, Visual Studio 2010 will have a new project template called “Import VSeWSS Project”.

image

Click OK, and a new dialog asks for more information such as the SharePoint site that is used for debugging, and whether you would like a sandboxed solution or a full trust solution.  Finally, it asks for the full path to the existing VSeWSS project.

image

Click Finish, and Visual Studio will churn for a minute as it converts the project to Visual Studio 2010.

image

One thing to note if you are importing field controls built with VSeWSS.  The XML file that is generated (in the screen shot above, fldtypes_FieldControl1.xml) has a value for the FieldTypeClass that is a GUID when you import it.  The correct value is a 5-part assembly name.  If you deploy and get an error that the field is not installed correctly, make sure to check that you replace the GUID with the 5-part name.  For instance:

<?xml version="1.0" encoding="utf-8"?>
<FieldTypes>
  <FieldType>
    <Field Name="TypeName">TimeCodeField</Field>
    <Field Name="TypeDisplayName">TimeCodeField</Field>
    <Field Name="TypeShortDescription">TimeCodeField</Field>
    <Field Name="ParentType">Text</Field>
    <Field Name="UserCreatable">TRUE</Field>
    <Field Name="FieldTypeClass">Empty2.TimeCodeField, AnnotationsProjectDemo, 
Version=1.0.0.0, Culture=neutral, PublicKeyToken=af55ed7e9eb0419d</Field>
  </FieldType>
</FieldTypes>

Make sure to not have a line break in the 5-part assembly name, I did that only for readability in the code sample above.

 

For More Information