Creating a Feature with Custom Action to Add Site Manager Menu in Site Actions Menu

Overview

You can add a custom menu item to the default Site Actions menu in Microsoft Windows SharePoint Services by creating a Feature with a CustomAction element. In this way, you can add custom commands to the default SharePoint user interface. These commands are available to users as they move between pages on a SharePoint site. When you create a Site Actions menu item, you can configure it to redirect the user to any URL. For example, you can redirect the user to another Web site. You can also redirect users to a custom application page that allows them either to see a custom display of data, or to perform custom operations on the content within the current site.

Code It

1. Create a new Project in VS 2010 and under SharePoint (left) select Empty Project

2. Now enter the url of your SharePoint site for debugging and select deploy as a farm solution.
3. Now, once you have the project open, right click on the Feature folder and Add a new feature.
4. SharePoint automatically adds a feature and names it as Feature1. You can however change the feature name to something like CustomActionFetaure.
5. With this you will have a feature designer opened in front of you set the Title description and scope of the feature.
6. Now right click on the Project and add a new Item. In the Add New Item dialog, select Empty Element to create a blank element file.
7. Add the below Code to the element.xml file

8. Build the Project. Open the feature.xml file and verify that if contains the reference to the element.xml file.
9. Now Deploy the wsp and activate the feature in your site.

Read It

When you create a CustomAction element, you must add an inner UrlAction element that contains a Url attribute. When you redirect the user to an application page, such as ApplicationPage1.aspx, you must consider whether you want the application page to run inside the context of the current site or the current site collection. In the following example, the dynamic token ~site is added to the beginning of the URL. When Windows SharePoint Services parses this CustomAction element and creates the menu item, it replaces ~site with the actual URL of the current site.
"~site/_layouts/sitemanager.aspx"

The key to security trimming your custom action is the Rights attribute. This attribute allows you to specify SharePoint permissions that the user must have for the action to be visible. This can be a comma delimited list. For example:

Rights="ViewListItems,ManageAlerts"

When more than one value is specified, the set of rights are treated with an AND. This means the user must have all of the specified rights for it to be visible. Here is a list of the valid Microsoft.SharePoint.SPBasePermissions you could use:

http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.spbasepermissions

Also, When you create the element for a custom menu item in the Site Actions menu, you have the option to configure it so that it is shown only to users who have administrative permissions. Note in the following example the addition of a new attribute named RequireSiteAdministrator.

RequireSiteAdministrator="TRUE"

When you add the RequireSiteAdministrator attribute, Windows SharePoint Services does not show the menu item to users who do not have administrative permissions. For a CustomAction element in a Feature that is scoped at the site-collection level, the menu item appears only for the site collection owner or administrator. For a CustomAction element in a Feature that is scoped at the site level, the menu item appears only to those who have administrative permissions within the current site.

Finally

Visual Studio 2010 Console Application for SharePoint 2010 (Target Platform + .NET Framework)

Most of the time it is very handy to test out something using
console application against SharePoint 2010. But this could be painful for at
times as developers finds it that references does not pick the assembly
correctly/build fails

Here are two things that you need to be careful of when
developing something on console application.

1. The target platform of your console application
needs to be set as x64(64 bit) in the Build configuration of your project.

2. The target framework needs to be .NET 3.5

As soon as setting up the User Profile Synchronization Application service, when clicking on User Profile Service Application in SharePoint 2010 - UserProfileServiceUserStatisticsWebPart:LoadControl failed

As soon as setting up the User Profile Synchronization Application service, when clicking on User Profile Service Application in SharePoint 2010 - UserProfileServiceUserStatisticsWebPart:LoadControl failed

[UserProfileServiceUserStatisticsWebPart:LoadControl failed, Exception: System.IO.FileLoadException: The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager.InitializeIlmClient(String ILMMachineName, Int32 FIMWebClientTimeOut) at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager..ctor(UserProfileApplicationProxy userProfileApplicationProxy, Guid partitionID)]
Check-1: You may have forgotten to issue iisreset /noforce
Check-2: Verify that “Forefront Identity Manager Synchronization Service” and the “Forefront Identity Manager Service” are running

SPSite Constructor throws FileNotFoundException

Most of the time we try out a Console application to test a specific piece of code, but when you do this on a x64 bit platform there is a chance that you might come across an exception as “FileNotFoundException” – complaining that the site not found.
The most basic reason for this issue could be that your output assembly is not compatible with the SharePoint assembly which is running out.
Ensure that your target platform is set to “AnyCPU”, before you further investigate on any other reasons.

Issues when running SharePoint 2010 Products Configuration Wizard - System.Security.Cryptography.CryptographicException: Keyset does not exist

Here the encryption key was created on a specific thread which was impersonated under a specific users account. When the .NET Finalizer processes the encryption key while the timer service shuts down it executed on a different thread which is not impersonated - so the key does not exist and you get an exception like "keyset does not exist".
To configure the server to no longer show a dialog when an unhandled exception occurs, use the registry editor to delete the following registry keys:

- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger
On a 64-bit operating system also delete the following registry keys:

- HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
- HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger

iisapp equivalent in IIS7 (Related to Windows 2008 or above)

When working with IIS 6.0 it was pretty handy to use the iisapp VbScript to find out which w3wp worker process relates to which Application Pool. In IIS7, this script doesn’t work anymore. There is a replacement though. You can add the command below to a batch file and just call it:

%windir%\system32\inetsrv\appcmd.exe list wp

How to migrate your WSS 3.0 & MOSS 2007 (32-bit) Products to SharePoint 2010

The paths depicted below could help migrate your WSS 3.0 & MOSS 2007 (32-bit) Products to SharePoint 2010.
Products are needed to be migrated in their respective 64-bit versions and then their 64-bit versions will be Migrated to SharePoint 2010 which doesn’t offer any 32-bit support.
E.g. If you want to upgrade from 32-bit version of MOSS 2007 then firstly you need to upgrade to the 64-bit version of MOSS 2007 and then from 64-bit version of MOSS 2007 you can upgrade to SharePoint Server 2010.