As shown in the code snippet above, Id is the name of the action. GroupId is the sharepoint defined GroupId and Location is also sharePoint defined location. Sequence will define the sequence number of the menu item. Url Action is the page where user will be navigated when user will click the menu.

Wednesday, September 22, 2010

We all SharePoint developers are familiar with Feature.xml and Elements.xml files. We usually defines feature’s resources in Element files. However, in Visual Studio 2010 to add Elements file to Feature we need to do few extra works. You can’t just add the Elements files directly in a feature folder in Visual Studio. You may still need to add the Feature element manifest file, for example in cases where you want to add a custom menu or hide existing menu for site actions. The following steps show how to add Elements.xml file in a SharePoint Feature from Visual Studio 2010.

Step 1: Create a new Feature

Create a feature for which you want to add the Element manifest file. If you have the feature already, then you can the feature to be used for attaching Element.xml file.

Step 2: Add Empty Element File

You need to add an empty element file in the project. To add Element.xml file, create a Empty Elements file in the project from ‘Add new Item’ window as shown below:

For manageability, you can keep all Element files in a single folder, say “FeatureElements” folder.

Step 3: Add ElementFile to elements.xml

Now, let’s say you want to add a configuration xml file (say MyConfig.xml) to element file. To do so right click on the newly created empty element and add a new item or existing item. Then open the properties of the new/existing item (so, MyConfig.xml) and set the ‘Deployment Type’ to ElementFile.

Step 4: Attach Elements file to Feature

Now you need to attach the Element file to a feature. To do so open the feature designer by double clicking on the feature name from Visual Studio’s solution explorer. Then make sure your Element file is on the right side (Items in the feature) of the designer. The following figure shows the Element file MyFeatureElement is attached with the feature whereas YourFeatureElemet is not attached.

Tuesday, September 21, 2010

In SharePoint 2007, we used to put the custom features in folder “12\TEMPLATE\FEATURES”. In SharePoint 2010, feature management is mostly done by Visual Studio 2010 UI. We mostly don’t care where the features are installed. However, with surprise I noticed that the feature is installed in the Features folder but not directly under the Features folder. Visual Studio creates a new folder under “14\TEMPLATE\FEATURES” folder and copy the features under that new folder.The name is in the format “VisaulStudioProjectName_FeatureName”. The name comes from feature’s properties and you can change the format. The following image shows the feature properties defining the naming format.

Figure 1: Feature deployment path in properties window

Now if you want to put the features just directly under the ‘14\Template\Feature’ folder, then just the set the ‘Deployment Path’ property value to '

$SharePoint.Feature.FileNameWithoutExtension$

Maybe sometimes you want to install the feature just under Features folder and in that case changing the deployment path will be helpful.

Sometimes, we need to move the site from one server to another, usually in development environment. In that case its required few steps to make sure you have moved your site in new server. I have successfully move my sites and I’m pointing here the exact steps that worked for me.

Backup the site or export the web

First of all you need to take backup of the site (if you want to move site collection). If you want to move a single site then export the web contents. For site backup use the following command:

Create Dummy site or web on the destination server to overwrite

Before restoring or importing site/web you need to create a dummy site/web on the destination server. In case of site restore, create a new site collection. In case of web import, create a site with the same name and template used in source server’s web.

Deploy code on the server

If possible, then deploy the sharepoint solution (generated from your developer code in Visual Studio) on the destination server. In some case the restore/import operation looks for features/resources on the site/web that is referenced in the backup/export file. So deploying the code on the server make sure the code (that will be finally used in the restored site/web) is on the destination server. If your code has web level feature/resources then use the root web as the default one to deploy code.

Restore or import the site/web

Finally you are ready to restore the site. Run the following command to restore a site collection.

Check user Permissions

If you restored a site collection then you need to change site collection administrator as the restored site is still pointing to the old site collection administrators (and maybe the administrator is invalid in the new server). From SharePoint central administration site change the site collection administrator to proper one.

Few points to notice

When you move the site/web few points need to remember:

If you restore just a web then your import operation may fail saying a feature is not installed on the web/site. This may happen in case where the source site /web’s backup file is referring a resource (say feature) that is not available on the destination server. In this case, make sure your code is deployed properly on the destination server. If you get the error for a particular web, then create a dummy web with the same name as on the source server, on the destination server and then deploy the code on the web and finally try to restore the web.

In case of web import, make sure you have created the new web on the destination server with the same template. You can’t overwrite a web on destination server with a source one that is using different template.

Sunday, September 19, 2010

Today I was trying to export one of my site from one Virtual machine to another. First I took a export of the web from my source server and then I tried to import the content in the destination server. And then the import failed with the error “The exported site is based on the template STS#1 but the destination site is based on the template STS#0”. I couldn’t remember the template with which I created the source site but I took for granted from the error message that the source and destination web are not created from the same template. After googling I finally found import will only work if source and destination web are created from the same template. In my case the source site was created from Blank Site template (STS#1) but the destination site was created from Team site template (STS#0).

So I deleted the destination site and recreated with the source template and the import was successful. For full lists of web site templates you can follow Aravindhan’s posts.

Sunday, September 12, 2010

When we develop visual WebPart in Visual Studio, we may follow some best practices for better management and organization of WebParts. Here are few good practices to follow:

1. Group your web parts: Set the group property in the Elements.xml file of WebPart to make sure the webparts comes under a specific group. This will make easier to find the webpart from sharepoint site. The following image shows how to modify group property:

Figure 1: WebPart’s group property in Visual Studio

Setting up the group property will show the webparts under ‘Test Group’ as shown below:

Figure 2: Webparts under Group.

Organize webparts under folder in Visual Studio: Often we are uses to create webparts in the root folder of the Visual Studio Projects. As the number of webparts grow, the folder starts to increase and navigability/manageability problem comes to light. One solution is to keep all webparts under a different folder. Another option is to keep related items under a particular folder. For example all items for navigation can be kept under a root folder “Navigation”. The following image shows all webparts are kept under ‘webparts’ folder.

Figure 3: Webparts organized under folders

Enter descriptive name and description for your webparts: As soon you create an webpart, enter descriptive name and descrition. To do so open the file with .webpart extension and modify Title and Description property as shown below:

Friday, September 3, 2010

Sometimes in development environment and even in production you may need to rename a site url. For example you have planned a site with URL www.mysite.com in Development or in Production. Later you have decided to rename the site url to www.yoursite.com. There’s no shortcut way to do that in SharePoint. You need to delete the existing web application for url www.mysite.com and create a new one with url www.yoursite.com.

1. Backup the site collection first

Run the following powershell command to backup site.

Backup-SPSite –Identity SiteUrl –Path BackupLocation

2. Delete the existing site from central admin.

Navigate to central admin and delete the web application including database and IIS site as shown below: