A couple of weeks ago I demoed an example of how to create a basic SharePoint 2010 “Change Site Title” feature using Visual Studio 2010. A video of the demo is now available on the SharePoint Tech Dives site at http://www.sptechdives.com/?p=185
A little bit about SharePoint Tech Dives (http://www.sptechdives.com): Each meeting is an open forum for discussion and learning around specific topics chosen by the community. Technology experts provide structure and guidance around each of the topics selected, while attendees are encouraged to ask questions as well as share their views, experiences, and opinions. At the end of each meeting attendees will help determine the topic for the following meeting.
Next Event – Wednesday, November 11th from 6:30 pm to 8:30 pm.
Developing SharePoint Features, Feature Receivers, and Feature Staplers
During this session we will discuss best practices and provide guidance around SharePoint Feature development, Feature Receivers, and Feature Staplers. The session will include a hands on lab with step by step instructions on how to create a simple Feature with a Feature Receiver and Stapler. We will also demo how to create a similar Feature for SharePoint 2010, using the upcoming version of Visual Studio. Space is limited, so be sure to reserve your seat. We look forward to seeing you there.
This is a fairly common and non-descriptive error that continues to surface more and more as the SharePoint developer community continues to grow. Surprisingly, I’ve found very little information in the web regarding what I believe to the most common cause and solution (hence this blog post).
Many things can trigger this error, and as you might expect by the description the error is security/permissions related. I’ve seen it most often, when browsing the Site Features and Site Collection Feature pages… but it has been known to take down a whole site; although mostly (and luckily) in dev environments.
So why do I keep referring back to development? And more importantly, what is this “most common” cause/solution? Its mostly tied to “drag and drop”; when you drag and drop files, permissions usually go with them (albeit there are a few exceptions.) With development rarely taking place directly in the 12 hive features, or layouts folder; its shouldn’t be surprising to see developers (and administrators alike) deploying and often testing changes to features by dragging and dropping files from their Desktop, My Documents, or project folders. Naturally this approach doesn’t follow best practices, but I wont deny having made the mistake while testing a quick change to a feature or elements xml file in a development environment. All updates to production environments should be done via WSPs.
So how do you solve the problem? Finding the culprit shouldn’t be too difficult, think of any items that have been recently deployed/updated. Cant think of any, search for any recently updated files of folders. If you do think of or find any; check the permissions and make any required modifications; also consider redeploying them via a WSP.
This posting is in response to a comment I had on a previous posting; “Using the InputFormSection and InputFormControl to build Custom Application Pages that look like OOTB Pages”. One of the readers posted a comment asking how to go about using the submit button to post to a list. Needless to say, I didn’t feel that answering his question by replying to his comment would be the best response. So I’ve decided to post my response here, where its a little bit easier to elaborate on the subject.
Application pages can in fact be used to create list items, but there are a number of things to consider. The first and probably most important thing, is that application pages can be accessed from any site in your SharePoint farm. If the list the form is meant to write to is accessible globally this may not be much of a problem, but I’d have to question how that list was created and where it is stored. Application pages are part of what I consider to be a fairly modular development framework in SharePoint, and the scenario mentioned doesn’t sound very modular at all; a page that is deployed or accessible from every site, but the list it writes to is only deployed to one. What if the site containing the list is deleted? Or certain fields changed? The site administrator would likely be able to do either, but he/she wouldn’t be able to update the Application Page, which would likely break.
So how do I recommend using Application Pages to write to lists? There are many ways, most (if not all) of which would involve Features. The following is a sample approach:
1. Develop a site or site collection Feature that creates a list. Since we will be writing to this list from a Custom Application Page, I recommend that the list be hidden. This recommendation stems from the fact that we don’t want anybody accidentally deleting or modifying the list, which may impact the Application Page. Of course this would probably mean creating another page to view and/or edit list items; this could be a Content Page or Application Page.
2. Develop the Application Page that writes to the list created by the feature, including logic in it that checks if the feature is activated. If the logic determines that the feature is not activated, the page should display a message stating that the feature needs to be activated for the page to work.
3. Use Custom Actions and Custom Action Groups to create a link to the Application Page(s) from the “Site Settings”, or “Site Actions” menu.
I don’t mean to imply that an Application Page shouldn’t be used to save items to a single globally accessible list. But it requires even more consideration and planning than the scenario mentioned above. Actually, I’ve had to develop such pages; in one example the list resides in Central Administration and is created as part of a Feature scoped at the Farm level.
In another scenario, the list may not be hidden, or even created by the feature. The list may be manually created (to capture very specific criteria) by a site or farm administrator, in which case another Application Page may be used to capture the location of the list, and save it in the property bag of the site or site collection. The Application Page that writes to the list, fist looks at the property bag to determine its location, if the property has not been set, the page simply returns a friendly error.
Like the above mentioned scenarios, I’m sure there are hundreds more. The point is all of them require some thought. Unless strictly used to display information that you know is always available, an Application Page is rarely a solution as a whole. Take time to carefully plan and design your Application Pages, examine your solution from multiple angles making sure it doesn’t easily break. Remember, if you fail to plan you are planning to fail.
SharePoint Site Enumeration Page: Get a list of all the sites in your SharePoint farm from Central AdministrationPosted: July 25, 2008
Updated 8/25/2008: Updates to formatting in code blocks and removed recursive call that was causing duplication.
In my previous post “Iterating through SharePoint Web Applications, Site Collections, and Sites (Webs)” I provided a simple script to iterate through all web applications, sites and site collections. In this post, I will use much of that code to create an application page that returns a list of all the sites in the farm in XML. I will also create a feature to display a link to the application page from the Application Management section in Central Administration.
First I create a new file called EnumerateSites.aspx in c:\program files\common files\microsoft shared\web server extensions\12\template\admin. I will be accessing the page from the Central Administration site; I prefer to put such pages in the “admin” folder which is not accessible from regular SharePoint sites, as opposed to the “layouts” folder.
Since this file will be returning a list of all the sites in XML, we need to make sure the browser renders it properly. To do so we change the content type of the page to “application/xml”
Next,we create references to the necessary SharePoint and XML assemblies:
Since we are only displaying XML we wont need to reference a master page; so the rest is pretty much the same code from the previous post executing in the OnLoad event of the page. I use the XMLTextWriter class to build the XML document, and incorporate a number of “try catch” statements throughout the code to ensure that any errors that may be encountered are properly displayed in the XML. I’ve pasted all of the code for the application page (including the 2 previous excerpts) below:
With the page saved in the admin folder, you could just access it via the URL of your central administration site:
I personally prefer to build a Custom Action which adds a link to the page from Application Management in Central Administration. The steps to do this are relatively simple:
- Create a new folder for the feature and call it “EnumerateSites”. We will use the feature to add a link to the page from Central Administration.
- Open the folder and create a new empty file naming it FEATURE.xml
- Open the file and paste the following XML, replacing NEWGUID with a newly generated GUID.
Title=”Enumerate Sites in XML”
- Save and close the file.
- Create another file, this time naming it “Elements.xml” and paste the following XML, replacing GROUPGUID and ACTIONGUID with newly generated GUIDs (use the same GUID in both occurrences of GROUPGUID):
Title=”Application Management Utilities” Sequence=”1010” />
Sequence=”10” Title=”Enumerate Sites in XML” Description=”“>
<UrlAction Url="_admin/enumeratesites.aspx” />
- Save and close the file
- Package the EnumerateSites.aspx page and feature using your method of choice. Don’t have one? Checkout WSPBuilder by Carsten Keutmann
- Deploy your solution and you are done!
You can access the page from the Application Management section of Central Administration, you’ll see a new section titled Application Management Utilities with a link to Enumerate Sites in XML.
Click on the link to get an XML page enumerating all of the sites in your farm, it should look similar to the following
In my previous post, “Hidden SharePoint Lists, Fields, and Other Advanced List Settings”, I demonstrated how we can develop a custom application page to easily expose and modify list and field settings. But once the custom application page has been created, how do we expose it to our users? Ideally we would create links to our Application Pages by adding new menu item entries to the SharePoint Site Settings and Site Actions menus. Fortunately, SharePoint allows us to do just that via Features and the CustomActionGroup and CustomAction elements.
The CustomAction element refers to the actual link or menu item.
The CustomActionGroup element, as Microsoft puts it, “contains the core definition for a grouping of custom actions.” Such as when you see a group of links or menu items grouped together in the “Operations” and “Application Management” pages of the Central Administration site.
What about the “Site Actions”, list or library “Actions” and “Settings” menus? These, like most other SharePoint menus, can also be configured via CustomActions.
The following steps demonstrate how we can use features and CustomActions to add a new menu item to the Site Settings page.
Creating the Feature
- Browse to the file system Feature folder located in “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\”
- Create a new folder for your feature. In my case I will call it “AdvancedListSettings” as I will use the feature to add a link to the Custom Application Page I created in my previous post; Hidden SharePoint Lists, Fields, and other Advanced List Settings
- Open the folder and create a new empty file naming it FEATURE.xml
- Open the file and paste the following XML, replacing NEWGUID with a newly generated GUID.
I like to call this file the “feature definition file”. It contains the general settings of our feature such as; title, description, feature scope, and whether or not the feature is hidden; but it doesn’t necessarily contain any of the “meat” or instructions for the feature, we’ll put those in our Elements Manifest file which we’ll create next.
- Save and close the file
- Create another file and name it “CustomMenuItem.xml”, we’ve specified this as an Elements Manifest file in our feature definition.
- Open the file and paste the following XML
- Looking at out CustomAction element the attributes break down as follows:
- ID – The ID specifies a unique identifier for the custom action, keep in mind that it must be unique, you may want to use a GUID.
- GroupID – Identifies an action group that contains the action, for example, "SiteManagement". If contained within a custom action group, the value of the GroupId attribute must equal the group ID of the CustomActionGroup element.
- Location – Specifies the location of this custom action. In this example we specified “Microsoft.SharePoint.SiteSettings", which tells SharePoint to create the custom action in the Site Settings Page.
- Sequence – Indicates what position the custom action should be placed in regards to other custom actions that may be in the same group.
- Title – Gives it the text to display
- Save and close the file.
- Open the command prompt and execute the following command to install the feature:
stsadm -o installfeature -file AdvancedListSettings
Where “AdvancedListSettings” is the name of the new feature folder in “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\”
- Browse to the Site Settings page of one of the SharePoint sites in Internet Explorer and click on the “Site Features” link
- Click the “Activate” button next to the new feature
- Go back to the Site Settings page to see your new menu item / custom action.
To create a new section in the site settings page and have the link appear in that new section, the elements manifest file (i.e. CustomMenuItem.xml in this example) would have too look as follows:
Notice the new CustomActionGroup element, it uses many of the same attributes of the CustomAction element. The GroupID attribute of the CustomAction element now references the ID of newly created CustomActionGroup.
For additional information see Custom Action Definitions in the SharePoint General Reference section of the MSDN:
I recently performed another upgrade from SharePoint Portal Server 2003 to MOSS, and while the upgrade was executed without any major problems(I’ve earned bragging rights); we experienced a large number of calls due to broken links from other sites, and links that where saved as shortcuts or browser “favorites”. Most of them were due to a very large information re-architecture.
Some of the more important links where accounted for and redirected to the proper pages by adding URL mappings to the web.config file, a surprisingly easy though not very common technique. Undoubtedly many files would be left out, as its rather difficult (never say never) to find out what links and shortcuts people have saved. Ultimately they wanted a custom 404 page that would display a page with a friendly message using the portal look and feel.
This is fairly easy to accomplish as SharePoint does provide an SPWebApplication property (FileNotFoundPage) to specify a custom 404 page. Unfortunately the property is only accessible via the API, and the file must be an HTML page located in \\Program Files\Common Files\Microsoft Shared\web server extensions\12\LAYOUTS\Locale_ID
Of course it would be easier if we could set this property from Central Administration, and why stop there, why not allow an administrator to specify a page in the portal, or anywhere else, and of any type for that matter. So I developed a SharePoint solution containing the following:
- An HTML page to specify as the FileNotFoundPage of the web application. This page redirects all requests to custom application page where its easier to handle the request.
- A settings page from where custom settings on how to handle the request can be specified for each web application.
- A SharePoint application page that handles the request based on the custom settings specified for the web applicaiton
- A feature that creates a menu item in “Central Administration > Application Management” for the settings page
The HTML file is simply a copy of the sps404.htm file that SharePoint installs by default in “c:\program files\common files\microsoft shared\web server extensions\12\template\layouts\1033″, I’ve simply replaced the path it uses to redirect requests to with that of my custom 404 handler aspx page.
The Custom404Settings.aspx page allows the user to select a web application and specify a custom 404 page. The value specified is saved to a custom property of the web application that can later be referenced by the Custom404Handler.aspx page.
The following code is used to update the FileNotFoundPage property of the web application and create a new property “Custom404Path” to store the specified custom 404 path value.
SPFarm farm = SPFarm.Local;
SPWebService service = farm.Services.GetValue("");
string webAppPropertyKey = "Custom404Path";
Guid webAppGuid = new Guid(lstWebApplications.SelectedValue);
SPWebApplication webApp = service.WebApplications[webAppGuid];
//create a web application property to store the
//path to the custom 404 page
webApp.Properties[webAppPropertyKey] = txtCustom404Path.Text;
lblMessage.Text = "Changes saved";
//update the FileNotFound property of the web application
//this needs to be an html page in the LAYOUTS/1033
webApp.FileNotFoundPage = "Custom404Page.htm";
//update the web application
The Custom404Handler.aspx page checks the value of the Custom404Path property of the web application and redirects the browser to that page. If the custom 404 path specified returns as the path not found (“oldUrl” querystring parameter) the page does not redirect the user and serves the custom 404 message itself (this is to avoid going into an endless redirect loop).
The following code is used to check the custom 404 path of the web application and perform the redirect.
using (SPSite thisSite = new SPSite(SPContext.Current.Site.Url))
string custom404Path = "";
string pageNotFound = Request.QueryString["oldUrl"];
SPWebApplication webApp = this.Site.WebApplication;
custom404Path = (string)webApp.Properties[webAppPropertyKey];
if ((custom404Path != "") && !(custom404Path.ToLower().Contains("custom404handler.aspx")) && !(pageNotFound.ToLower().Contains(custom404Path.ToLower())))
The feature.xml and elements.xml files add a custom menu item to “Central Administration > Application Management” from where the users can specify the custom 404 settings.
Updated 7/28/2008 : Updated Samples, Project Files and WSP to include recommended changes for handling anonymous requests.
- features that create workflows requiring specific groups for approvers
- features that create custom libraries or list which only specific users(groups) should be able to access
- features with custom application pages that provide specific functionality based on group membership
The list goes on and on; and while you could let the site owners create these groups and assign the necessary permissions (for most of these scenarios); wouldn’t it be safer if this was done by you. Think of all the time you’ll save on calls where you would otherwise have to explain how to do this, or troubleshooting where they’ve gone wrong. True, they’ll still have to add the users to the groups; but if they cant even do that maybe their place shouldn’t be anywhere near SharePoint.
In this posting I hope to demonstrate just how to do this by developing a feature that creates a Custom Group when activated.
We’ll begin by creating a folder called “CustomGroup” in the SharePoint feature directory (ie. “c:\program files\common files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\FEATUES\CustomGroup”)
Next we’ll create the FEATURE.xml file, it should look as follows:
Description="This Feature Creates a Custom Group"
Notice the ResourceAssembly and ReceiverClass attributes. These serve as references to the assembly that will handle the FeatureActivated, FeatureDeactivating, FeatureInstalled and FeatureUninstalling events. The PublicKeyToken of the ReceiverAssembly attribute has been set to TBD, we wont have this until we’ve created and compiled the class.
Next we’ll create the SPFeatureReceiver class referenced above. Your code should look as follows:
class FeatureReceiver : SPFeatureReceiver
public override void FeatureActivated(SPFeatureReceiverProperties properties)
//get a reference to the site collection where the feature is activated
using (SPSite site = properties.Feature.Parent as SPSite)
//get a reference to the root site / web of the site collection
using (SPWeb web = site.RootWeb)
//get a reference to a Site Owner
//(there should always be at least 1; position 0 of the
//we'll make this user the owner of the custom group
SPMember siteOwner = web.SiteAdministrators;
//prepare the group name
string grpName = "Custom Group";
//check if group exists
bool grpExists = false;
//THIS CODE SHOULD BE MOVED TO ITS OWN HELPER FUNCTION
//OR UTILITIES CLASS. IN FACT MOST OF THIS CODE NEEDS
//TO BE REFACTORED
foreach (SPGroup group in web.SiteGroups)
if (group.Name.ToLower() == grpName.ToLower())
grpExists = true;
//add the custom group to the site
//if it doesnt allready exist
web.SiteGroups.Add(grpName, siteOwner, null,
"Custom Group that I created because I can!");
//get a reference to the group we just created
SPGroup customGroup = web.SiteGroups[grpName];
//add the group to the quicklaunch
web.Properties["vti_associategroups"] + ";"
//.....FeatureDeactivating, FeatureInstalled, and FeatureUninstalling methods
The code has enough comments to be self explanatory. Make sure you create your class under the right namespace, as this is referenced in the FEATURE.xml file. You’ll also need to sign the assembly (give it a strong name), go to http://msdn2.microsoft.com/en-us/library/ms247123(VS.80).aspx for step-by-step instructions on how to do this.
Compile the assembly and add it to the GAC. While in the GAC,right click the assembly, select properties and make a note of the Public Key Token. You’ll need to update it on the FEATURE.xml file.
Deploy your feature via the Installfeature command in STSADM or by packaging it and deploying it in a WSP file.
Since we’ve set the scope of the feature to “Site”; you’ll have to activate your feature from the “Site Collection Features” link on the Site Settings page. If you are on a sub-site/web you’ll need to click on the “Go to top level site settings” link first.