SELECT
UserProfile_GUID, PreferredName, JobTitle, Department, WorkPhone, OfficeNumber,
AboutMe, PictureURL, WorkEmail, WebSite, Path, HitHighlightedSummary,
HitHighlightedProperties, Responsibility, Skills, SipAddress
FROM scope()
WHERE freetext(defaultproperties,'+trent')
AND ("scope" = 'People')
AND CONTAINS(Skills, '"numchucks"')
AND CONTAINS(Skills, '"rockstar"')

Use of the CONTAINS predicate was purely due to my need to query multi-valued properties. If you are not querying a multi-valued property, you may simply use the ‘=’ or ‘LIKE’ predicates.

It turns out that the CONTAINS predicate will only work against managed properties that have been enabled as FullTextQueriable. I am not aware of a way to enable a property in the SSP Search Settings, so this has to be done using the API. I ended up including the following method as part of a Web Application scoped Feature Receiver to ensure certain Managed Properties were ‘FullTextQueriable’.

    using Microsoft.Office.Server;
    using Microsoft.Office.Server.Search.Administration;
 
    private void EnsureFullTextQueriableManagedProperties(ServerContext serverContext, params string[] managedPropertyNames)
    {
        var schema = new Schema(SearchContext.GetContext(serverContext));
        foreach (ManagedProperty managedProperty in schema.AllManagedProperties)
        {
            if (!managedPropertyNames.Contains(managedProperty.Name))
                continue;
 
            if (managedProperty.FullTextQueriable)
                continue;
 
            try
            {
                managedProperty.FullTextQueriable = true;
                managedProperty.Update();
                Log.Info(m => m("Successfully set managed property {0} to be FullTextQueriable", managedProperty.Name));
            }
            catch (Exception e)
            {
                Log.Error(m => m("Error updating managed property {0}", managedProperty.Name), e);
            }
        }
    }

So on the same note of Managed Property flags not visible in the SSP Search Settings, you may also want to know about the Retrievable flag. This flag prevents a Managed Property’s value from being returned if specified as a column in the SELECT statement.

The following table lists most of the out of the box Managed Properties and their default FullTextQueriable, HasMultipleValues, and Retrievable flag values.

Name	FullTextQueriable	HasMultipleValues	Retrievable
AboutMe
Account
AccountName
AssignedTo
Assistant
Author
Authority
BestBetKeywords
Birthday
CachedPath
CategoryNavigationUrl
CollapsingStatus
Company
contentclass
ContentSource
ContentType
Created
CreatedBy
DataSource
DatePictureTaken
Department
Description
DisplayTitle
DocComments
DocKeywords
DocSignature
DocSubject
DottedLine
EMail
EndDate
Fax
FileExtension
Filename
FirstName
FollowAllAnchor
HighConfidenceDisplayProperty1
HighConfidenceDisplayProperty10
HighConfidenceDisplayProperty11
HighConfidenceDisplayProperty12
HighConfidenceDisplayProperty13
HighConfidenceDisplayProperty14
HighConfidenceDisplayProperty15
HighConfidenceDisplayProperty2
HighConfidenceDisplayProperty3
HighConfidenceDisplayProperty4
HighConfidenceDisplayProperty5
HighConfidenceDisplayProperty6
HighConfidenceDisplayProperty7
HighConfidenceDisplayProperty8
HighConfidenceDisplayProperty9
HighConfidenceImageURL
HighConfidenceMatching
HighConfidenceResultType
HireDate
HitHighlightedProperties
HitHighlightedSummary
HomePhone
Interests
IsDocument
JobTitle
Keywords
LastModifiedTime
LastName
Location
Manager
MemberOf
Memberships
MobilePhone
ModifiedBy
MySiteWizard
NLCodePage
Notes
objectid
OfficeNumber
OWS_URL
PastProjects
Path
Peers
PersonalSpace
PictureHeight
PictureSize
PictureThumbnailURL
PictureURL
PictureWidth
PreferredName
Priority
ProxyAddresses
PublicSiteRedirect
Purpose
Rank
RankDetail
Responsibilities
Schools
SID
SipAddress
Site
SiteName
SiteTitle
Size
Skills
StartDate
Status
Title
UrlDepth
UserName
UserProfile_GUID
WebId
WebSite
WorkAddress
WorkCity
WorkCountry
WorkEmail
WorkId
WorkPhone
WorkState
WorkZip

Downloads

SharePoint Smart Editor Parts.docx (~159 KB)
A complete writeup of the SharePoint “Smart” Editor Part framework

Trentacular.SharePoint.SmartEditorPart.zip (~ 320 KB)
The Visual Studio solution of the SharePoint “Smart” Editor Part framework
(Requires Visual Studio 2010 and WSPBuilder Extensions 2010)

Introduction

About the SharePoint Web Part Platform

Windows SharePoint Services 3.0 (WSS) offers a robust platform for hosting Web Parts, providing a Web Part Manager implementation that builds a rich tool pane for configuring the Web Parts.  Out of the box, WSS provides tool panes for customizing the appearance and layout, and will even generate basic fields for custom Web Part properties that are marked with the appropriate attributes.   The following table describes how custom property types are displayed in the property pane:

Building Custom Editor Parts

When a custom property requires a user interface element other than the ones listed above or needs custom validation, you can write a custom Editor Part that inherits from System.Web.UI.WebControls.WebParts.EditorPart and have your Web Part implement System.Web.UI.WebControls.WebParts.IWebEditable to create your custom Editor Part.

If you would like to build your custom Editor Part using a User Control, there are a few more steps you will have to take, because the abstract System.Web.UI.WebControls.WebParts.EditorPart base class does not inherit from the System.Web.UI.UserControl class.  The rest of this guide will walk you through the steps to create a framework for building Editor Parts with User Controls.

Inheriting from a Web Part Base Class

Web Parts inheriting from Microsoft.SharePoint.WebPartPages.WebPart can also take advantage of this framework with slight modifications to this guide.  You will be creating a base class that inherits from System.Web.UI.WebControls.WebParts.WebPart that will encapsulate the majority of the Editor Part framework and will be used by the example Site Members Web Part.  If you prefer to inherit from Microsoft.SharePoint.WebPartPages.WebPart, you may change the base class you will be creating to inherit from this class instead; however, Microsoft recommends that you inherit from System.Web.UI.WebControls.WebParts.WebPart whenever possible.

Overview of the User Control Editor Part Framework

Overview of Building an Editor Part

In order for a Web Part to have a custom Editor Part, the Web Part can implement the System.Web.UI.WebControls.WebParts.IWebEditable interface.  The abstract WebPart class that is typically used as the base class for custom Web Part implementations already implements the IWebEditable interface, which includes two exposed members.  The WebBrowsableObject property provides a way for EditorPart controls to get a reference to the associated Web Part.  The CreateEditorParts method is used to create an instance of each custom EditorPart control associated with the Web Part, and return them as a collection.  Custom Web Parts that inherit from the abstract WebPart class need only to override the CreateEditorParts method in order to add additional Editor Parts.

The EditorPart class exposes a property named WebPartToEdit of type WebPart that the Editor Part can use to read and set the configurable properties of the Web Part.  Additionally, two abstract methods SyncChanges and ApplyChanges are exposed that are called by the Web Part framework at the appropriate times when the Editor Part should read or set these properties on the associated Web Part.

Extending the Editor Part Framework to Support User Controls

In order to use a User Control as an Editor Part, a generic Editor Part called UserControlEditorPart<T> is needed that will wrap the appropriate User Control.  The UserControlEditorPart<T> will also need to pass the SyncChanges and ApplyChanges method calls along to the User Control.  This can be accomplished by defining an interface to be implemented by the User Control.  This interface will be called IWebPartEditor<T>.

The UserControlEditorPart<T> class is generic because it will inherit from another base class that is also generic called BaseEditorPart<T>.  This base class is extracted so that it can be inherited by both the UserControlEditorPart <T> and any other custom non-User Control Editor Parts.  Its sole purpose is to provide the convenience of casting the WebPartToEdit property of the EditorPart abstract class to the specific Web Part type associated to the EditorPart.

Enabling Attribute Decorations for Editor Part Associations

While it is relatively straight-forward to implement the IWebEditable interface’s CreateEditorParts method in a custom Web Part class, the framework additionally abstracts this step away, enabling you to associate Editor Parts to your Web Part using attributes.  This is accomplished by supplying two additional classes: WebEditableWebPart and EditorPartAttribute.

The WebEditableWebPart class is a new base class to be used by your custom Web Parts.  The class inherits from WebPart and overrides the CreateEditorParts method to add any Editor Parts to the Web Part that are specified by the EditorPartAttribute class.

The EditorPartAttribute class is to be applied as a class attribute to a Web Part requiring a custom Editor Part.  The attribute allows for an Editor Part to be specified by either its type or by a virtual path to a User Control that implements IWebPartEditor<T>.

Using the User Control Editor Part Framework

With the User Control Editor Part framework in place, there are now just three steps needed in order to create an Editor Part as a User Control:

1. Ensure the Web Part inherits from WebEditableWebPart.  In the case where you are already using a custom base class for your Web Parts, you may simply change your custom base class to inherit from WebEditableWebPart.
2. Create a User Control that implements IWebPartEditor<T>.
3. Decorate your Web Part using the EditorPartAttribute class specifying the virtual path to the User Control.

When using FBA, the only “non-SharePoint” groups available to us are the roles exposed by an ASP.Net Role Provider.  If you are already using a custom Role Provider and are not able to make changes to it, then you can stop here.  This post is not for you.  If you are like me though, and are using FBA merely for authentication and are leveraging SharePoint for all authorization, then the single “All Authenticated Users” role is all I need from my Role Provider.  As a result, there is no need to use a heavy weight Role Provider (i.e., the SQL Role Provider) to accomplish this, but rather roll your own very dumb role provider.  There is only a single method that you will need to implement – GetRolesForUser – in which you can assume the user is already authenticated and always return the “All Authenticated Users” role for the user. Here is the Role Provider I am currently using:

using System;
using System.Web.Security;
 
namespace Trentacular.Web.Security
{
    public class SimpleAllAuthenticatedUsersRoleProvider : RoleProvider
    {
        public const string AllAuthenticatedUsersRoleName = "All Authenticated Users";
 
        public override string ApplicationName { get; set; }
 
        public override string[] GetRolesForUser(string username)
        {
            return new[] { AllAuthenticatedUsersRoleName };
        }
 
        #region Methods Not Implemented
 
        public override string[] GetAllRoles() { throw new NotImplementedException(); }
        public override bool IsUserInRole(string username, string roleName) { throw new NotImplementedException(); }
        public override bool RoleExists(string roleName) { throw new NotImplementedException(); }
        public override void AddUsersToRoles(string[] usernames, string[] roleNames) { throw new NotImplementedException(); }
        public override void CreateRole(string roleName) { throw new NotImplementedException(); }
        public override bool DeleteRole(string roleName, bool throwOnPopulatedRole) { throw new NotImplementedException(); }
        public override string[] FindUsersInRole(string roleName, string usernameToMatch) { throw new NotImplementedException(); }
        public override string[] GetUsersInRole(string roleName) { throw new NotImplementedException(); }
        public override void RemoveUsersFromRoles(string[] usernames, string[] roleNames) { throw new NotImplementedException(); }
 
        #endregion
    }
}

After rolling your own role provider, you will need to register it in the web.config inside the <system.web> section as such:

<roleManager enabled="true" defaultProvider="SimpleAllAuthenticatedUsersRoleProvider">
    <providers>
        <add name="SimpleAllAuthenticatedUsersRoleProvider" type="Trentacular.Web.Security.SimpleAllAuthenticatedUsersRoleProvider, Trentacular.Web, Version=1.0.0.0, Culture=neutral, PublicKeyToken=aaaaaaaaaaaaaaaa" />
    </providers>
</roleManager>

1. Accepts as input either a single Solution filename or a filename of a text file containing a list of Solutions to be upgraded
2. Extracts and parses the Solution manifest file from each existing Solution to be upgraded in order to determine the Features that will be affected by the upgrade
3. Inventories the deployment states of the existing Solutions
4. Inventories the activation states of the affected Features at all scopes within the SharePoint Farm
5. Deactivates all affected Features
6. Retracts each of the existing Solutions and deletes them from the Solution store
7. Adds the updated Solution to the Solution store
8. Deploys each of the upgraded Solutions according to their previous deployment state
9. Activates all affected Features according to their previous activation state

Usage

stsadm -o smartsolutionupgrade [-filename <Solution filename>] [-filenamelist <Path to text file containing each of the solution filenames on separate lines>]

Job Definition Execution

Included in the project is a Job Definition Executor that takes care of running one-time scheduled service jobs and waiting for their completion before releasing control.  One particular issue addressed by the Job Definition Executor is the “A web configuration modification operation is already running” error caused by successive execution of the stsadm -o activatefeature command on Features that perform web configuration modifications.

In a multi-server farm, web configuration modifications are delegated to Timer Jobs; therefore, the return from execution of the activatefeature command does not mean the Feature activation (and thus the web configuration modification) has completed.  So you might say, well duh, you need to also execute the execadmsvcjobs command, but this command simply kicks of the job execution and returns from execution while still not waiting for the jobs to actually complete.

The Job Definition Executor solves this problem by kicking of the jobs and monitoring for their completion.  We can now safely execute multiple web configuration modification Features in sequence.

Update

I just released a second stsadm command called smartexecjobdefs that simply wraps the Job Definition Executor and can be used as a substitute for the execadmsvcjobs command.

• Toggling of views in place (without leaving the web part page)
• Ability to display lists located in different sites of the same SharePoint Farm

Development of this Web Part has proved to be a very difficult undertaking, and I would love for any assistance or ideas with how to go about accomplishing this differently.

Here is where I’ve currently landed in the Web Part’s development:

• I am accessing the SPLimitedWebPartManager at the selected view’s url to load the SharePoint List View Web Part that was provisioned for the view when created
• I then use reflection to invoke the private RenderView method of the Web Part

Yes, this sounds extremely hacky, and it is. Using the avaliable SharePoint ListView control didn’t play nice with many custom views (especially when the list used managed content types).  I’ve also tried the SPView.RenderAsHtml method, but this also presented problems.

Another possible option would be to use the ListViewByQuery WebControl, but this would require an intense amount of code to duplicate the sorting and filtering that is available through the ListView control. So if you think this Web Part would be useful and would like to contribute to furthering it along, please get in touch.

Here are some screenshots:

The Feature currently adds just a single custom action and page for exposing and managing Web (Site) properties with a similar UI as the previously released Farm Properties Editor (part of the Central Administration Extensions Feature).

The Web Properties Editor has proved convenient for externalizing site-specific configuration settings from which your custom features, whatever they may be, can read from. It also abstracts away the peculiarities of the SPWeb.Properties and SPWeb.AllProperties API which I wrote about in my last post – a must read if you are a SharePoint developer and haven’t already.

If you haven’t already noticed, there are two different API properties on the SPWeb class – AllProperties (a Hashtable) and Properties (a PropertyBag). Apparently the AllProperties is meant to replace Properties, but Properties was left in place for backwards compatibility. Here’s where things get wicked …

The unconventional PropertyBag data type stores its keys in all lowercase, thus not supporting case-sensitive keys, while the conventional Hashtable does support case-sensitive keys. On top of that, while entries added to Properties get propagated to AllProperties with a lowercase key, entries added to AllProperties do not get propagated to Properties. So this what Microsoft gives us developer peons to work with. This is why consultants like myself stay employed.

If you are working with property entries that only your custom application will be reading and writing from, simply always use AllProperties and you will be good to go. However I often find myself having to work with properties that are read or written by SharePoint internals, and SharePoint itself is very inconsistent in its interaction with Web (Site) properties, probably due to its evolving nature being a rather old product as far as software is concerned.

So the best solution that I have come up with to date is to add your entries to both API properties. This ensures the entry will be present in both collections, and also ensures the key will have the correct case in AllProperties. I have found though in order to add to both, the order of the update API calls is important – you must first update the SPWeb object followed by updating the SPWeb.Properties PropertyBag. Performing the updates in the reverse order prevents an entry with a case-sensitive key from being added to AllProperties, and only the lowercase-keyed entry will be exposed in AllProperties. Now that you are probably thoroughly confused, here is the code:

// Add a property entry
web.Properties[key] = value;
web.AllProperties[key] = value;
web.Update();
web.Properties.Update();
 
// Remove a property entry
web.AllProperties.Remove(key);
web.Properties[key] = null;
web.Update();
web.Properties.Update();

Take a look, or straight up copy, my SharePoint utility class that abstracts away Web property interactions.

The solution currently deploys just a single custom action and page for managing farm properties. This has proved useful for us as a means to centralize configuration that is applicable across our entire SharePoint farm, such as custom application connection strings, log4net config file location, etc.

If you are a seasoned ASP.Net developer, you may also find the included Delegate Data Source useful. It essentially exposes the 4 main data source methods (select, insert, update, and delete) as events that can be handled directly in your code behind.

Globally Deployed Solutions

When a solution is deployed globally, all SharePoint application pools, including Central Administration’s, are recycled automatically. This can be good and bad. This is good because any GAC installed DLL that has been upgraded needs to be reloaded. This can be bad though with regards to the availability of your entire SharePoint Farm.

In my particular case, I am working with a SharePoint administrator to deploy a globally deployed solution that is used by only a single web application. It is fine for this web application to be unavailable, as we have cleared it with our change control process and made announcements of the downtime, but we haven’t announced to users of the other SharePoint web applications in the Farm that their sites will be coming down along with it. So be forwarned.

Web Application Targeted Solutions

I have become fond of web application targeted solutions because they offer me a workaround to the above availability problem. I now even trick my solutions to be web application targeted that otherwise would be deployed globally by including a dummy web application scoped feature in them.

When a web application targeted solution is deployed or retracted, only the application pools of the targeted web applications are recycled.

Enterprise Farm Strategies

• When upgrading solutions, the upgradesolution stsadm command only gets you so far. I’ve found it is best to fully retract and remove the old solution and then add and deploy the new solution in order to be sure your upgraded features actually take.
• Avoid the -allcontenturls switch – When deploying and retracting a web application targeted solution, deploy or retract it only to those web applications that will use it … thus preventing unnecessary recycling of application pools. I was being lazy in my deployment script and instead of specifying the particular web application url, I used the -allcontenturls switch to retract my solution, hoping SharePoint would be smart enough to recycle only the application pools of the web applications the solution was actually retracted from. Bad assumption. They all get recycled.

A Big Gotcha that Got Me

If you are upgrading a web application targeted solution using the retract, remove, add, deploy strategy mentioned above and your web application scoped Features have associated Feature Receivers, then you MUST recycle the Central Administration application pool after removing the old solution and before adding the new solution. It is the Central Administration application pool that executes your web application scoped Feature Receivers, and if not recycled, it will continue to use the loaded cached old versions of assemblies updated by your solution.

The Feature is naturally scoped to a Web Application and adds ASP.Net 3.5 entries to the particular Web Application’s web.config file. It works for both WSS and MOSS and also supports clean deactivation by iterating through the SPWebConfigModification collection and removing modifications by owner instead of recreating the modifications. All modifications are done through a utility class called SPWebConfigModificationHelper which can be taken advantage of alone if you are writing your own modifications.

Before deciding to write this feature, I tried several others that have been published. Each had its own issues, from not supporting clean deactivation to simply just not adding the correct entries. The entries this feature writes were taken from the Visual Studio ASP.Net 3.5 Web.config template.

If you give this Feature a shot, please let me know how it goes.