Incompatible Webpart Markup - .dwp vs .webpart

SharePoint 2010 allows us to extend out of the box web parts. When I try to inherit search box webpart (one of the out of the box webparts), and try to add new web part to a SharePoint page, I got this error:

“Incompatible Web Part markup detected. Use *.dwp Web Part XML instead of *.webpart Web Part XML.”

Problem:

Both .dwp and .webpart file types are used to describe where the code is for a web part. They are XML web part descriptors deployed with the web part. The difference is .dwp was the file extension used in version 2 of SharePoint and .webpart is a new extension used in version 3.  Inside the files, the schemas are different. Microsoft.SharePoint.Portal.WebControls.SearchBoxEx is one of the older ones and therefore requires a .dwp descriptor.

Solution:

We have to create a .dwp descriptor for the webpart.

1. Add a new XML file to the web part and give it the same name but with a .dwp extension

2. Add this content to the .dwp file

<?xml version="1.0" encoding="utf-8"?>

<WebPart xmlns="http://schemas.microsoft.com/WebPart/v2">

    <Assembly>$SharePoint.Project.AssemblyFullName$,Version=1.0.0.0,Culture=Neutral,PublicToken=6476a1ad7b812768</Assembly>

  <TypeName>SharePointProject1.ExtendedWebPart.ExtendedWebPart</TypeName>

  <Title>Extended SearchBox</Title>

  <Description>Extended SearchBox WebPart</Description>

</WebPart>

It is important to note that there are two main differences in the schema compared to the .webpart file;

· The xmlns is http://schemas.microsoft.com/WebPart/v2 instead of http://schemas.microsoft.com/WebPart/v3 

·         We need the assembly's public token.

3. Set the Assembly version to your assembly's version. This is usually 1.0.0.0, but you can find it in AssemblyInfo.cs in your project.

4. Replace the PublicKeyToken

5. Replace the TypeName with the type name in the .webpart file.

6. Select the .dwp file in Solution Explorer and change its Deployment Type property from NoDeployment to ElementFile. This will ensure .dwp file is deployed with the web part.

7. Verify that Step 6 adds an entry to the .spdata file.

8. Delete the .webpart file. So the final view will be like this.

9. Edit Elements.xml file and replace both instances of .webpart with .dwp

<?xml version="1.0" encoding="utf-8"?>

<Elements xmlns="http://schemas.microsoft.com/sharepoint/" >

  <Module Name="ExtendedWebPart" List="113" Url="_catalogs/wp">

    <File Path="ExtendedWebPart\ExtendedWebPart.dwp" Url="ExtendedWebPart.dwp" Type="GhostableInLibrary">

      <Property Name="Group" Value="My Webparts" />

    </File>

  </Module>

</Elements>

10. Build and deploy the project

This is how I extended Microsoft.SharePoint.Portal.WebControls.SearchBoxEx. For the purpose I had to reference two assemblies Microsoft.Office.Server.Search.dll, microsoft.sharepoint.portal.dll from ISAPI folder (Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI).

Modify Languages and Result Types in SharePoint Advanced Search

SharePoint 2010 advanced search window by default let us search by set of languages and result types as below.

We can customize this set of languages and result types from the properties window of the webpart. If we expand the Properties section of the Advanced Search Box window, we can notice that there are three options:

1.    "Show Properties" checkbox

2.    Properties section label

3.    "Properties" text field

The first two options, the checkbox and properties section label fields display and label the Properties list, the last part of the webpart.

The third option, Properties field is which we going to use for languages and result types customization. As you can see in the small part shown in this text box, it is an XML definition, which will look like as follows.

Here we can see four primary nodes under the root of the XML:

1.    LangDefs

2.    Languages

3.    PropertyDefs

4.    ResultTypes

First node, LangDefs (Language Definitions) provides a list of all the languages that SharePoint Search supports.

Second node, Languages lists down all the languages shown in the webpart. It should be noted that the LangID parameter from the LangDefs is used as the LangRef in this section.

LangDefs - <LangDef DisplayName="English" LangID="en"/>

Languages - <Language LangRef="en"/>

So if we want to display only the English, French and Spanish languages in the webpart, languages node should look like:

<Languages>

   <Language LangRef="en"/>

   <Language LangRef="fr"/>

   <Language LangRef="es"/>

</Languages>

The languages will be presented in the webpart in the order they listed in above XML node.

Third node in the XML definition, the PropertyDefs are used for the ResultTypes. PropertyDefs represent the standard managed properties used by SharePoint Search. Each PropertyDef provides the actual managed property name, a DisplayName for use in the Property Restrictions dropdown, and a DataType to allow the UI to provide appropriate comparison prompts. If we define our own managed properties in Search, we will need to manually add each property to this list in order to let our users to be able to choose them in the "Add property restrictions" section.

Forth node, the ResultTypes node contains the definitions for the items which appear in Result type dropdown. Each ResultType contains PropertyRef references from the PropertyDefs. Which means if we define our own managed properties in PropertyDefs, we will need to add them to the appropriate ResultTypes as well.

So a customized advanced search window will look like:

Differences between Basic Search Center, Enterprise Search Center and Fast Search

Some useful information I found in the Web which helps in deciding between SharePoint Search Centers.

The main differences between Basic Search Center and Enterprise Search Center are the abilities to customize.

Basic Search Center (contextual scope) only allows to search within lists or within sites.  Search results are displayed on a system page where we cannot customize easily. We can only edit the existing search page and search result page and we cannot add more pages of our own to it.

Enterprise Search Center allows for much more flexibility. We can search across site collections and even web applications (assuming they share the same index). Much more flexibility to customize the search experience, better scalability, we can author our own pages, and overall much better control over searching in general. Enterprise Search Center only available in SharePoint server (Standard or Enterprise), also we need to enable the following site level features for it:

1.    “SharePoint Server Standard Site Collection features” feature

2.    “SharePoint Server Publishing Infrastructure” feature

FAST Search for SharePoint does everything that SharePoint Search does, plus a few more things like document previews, deep refiners, user context, and visual best bets.  It is extremely scalable and a great choice for organizations that have high volumes of content to be searched.

A comparison between search server products from Microsoft site is as below. More information on which Search Server product is right for you is here.

Product Features	Search Server 2008 Express	Search Server 2010 Express	SharePoint Server 2010
Performance with sub-second response time	3 million items1	10 million items1	100 million items
Search analytics reporting	*	*	*
User interface–based (UI-based) administration	*	*	*
Relevancy tuning by document or site promotions	*	*	*
Common connector framework for indexing and federation	*	*	*
Search from Windows 7 and Windows Mobile		*	*
Metadata-based refinement panel		*	*
Metadata extraction on managed properties		*	*
Scriptable deployment and management using Windows PowerShell		*	*
Relevance improves with social behavior		*	*
Query suggestions, related searches, and improved “Did you mean?”		*	*
People and expertise search			*
Taxonomy and term store integration			*
Phonetic and nickname search			*
Integration with My Site			*

¹ Assumes use of Microsoft SQL Server.