Here is a sample C# method that I used to make this happen:


private void SetPeopleEditorVisibility(ref PeopleEditor pe, bool visible)
{
    if (pe.Style.Keys.Count > 0 && pe.Style["display"] != null)
    {
        pe.Style.Remove(”display”);
    }

    if (visible)
    {
        pe.Style.Add(”display”, “block”);
    }
    else
    {
        pe.Style.Add(”display”, “none”);
    }
}

Improving SharePoint Search Relevancy through Scopes
6:30pm - 8:00pm - QuickStart, Irvine, CA

Organizations struggle with delivering information within the scope and context of business users needs.  Understanding scope and contextual search needs can be a daunting task.  However, results can be dramatically improved through careful planning, architecture, design, and development techniques.

 

In this session, you will learn the techniques and best practices required to deliver a SharePoint solution that supports scoping of information.  We will cover appropriate architecture, design, and configuration techniques then dive into development.  Development topics will include an introduction to search syntax options and the key query classes offered in MOSS, and search object model with a demonstration of executing queries with scope information.

• MCTS: Windows SharePoint Services 3.0 – Configuration via exam 70-631
• MCTS: Microsoft Windows SharePoint Services 3.0 – Application Development via exam 70-541
• MCTS: Microsoft Office SharePoint Server 2007 – Configuration via exam 70-630
• MCTS: Microsoft Office SharePoint Server 2007 ― Application Development via exam 70-542

Usually, the next question I get is… Which one should I take? This question is a bit harder to answer since the answer depends on the individual goal of certification. Nevertheless, I will try to break it down.

Every person who wants to get “SharePoint certified”  should start with exam 70-631 (WSS 3.0 Configuration). This certification shows that you understand how to install and configure a SharePoint farm, use Central Administration, and use and customize out-of-the-box features such as site templates, lists, libraries, and web parts. From a professional perspective, this exam is the corner stone for all things SharePoint since it ensures that the individual with this certification has the essential knowledge to create out-of-the-box solutions using WSS 3.0. To begin preparing for this exam, I suggest strong familiarity with the WSS 3.0 TechNet library.

The next certification to go for depends on your professional goals. If you are a developer and want to build custom solutions, then take the 70-541 exam (WSS 3.0 Development). If you are not a developer and plan on building out-of-the-box solutions with MOSS 2007, then take the 70-630 exam (MOSS 2007 Configuration). My reasons follow below.

Exam 70-541 (WSS 3.0 Development) certifies general knowledge of custom development and advanced customization of WSS features. This includes knowledge of the programming against the WSS object model and using the collaborative application markup language (aka CAML) to create custom applications, templates, features, definitions, and more. It also demonstrates the ability to package and deploy custom solutions using the WSS solution deployment mechanism. To begin preparing for this exam, I suggest strong familiarity with the WSS 3.0 MSDN library. If you are not a developer, then skip this exam.

Exam 70-630 (MOSS 2007 Configuration) certifies the ability to deploy, maintain, monitor, and administrate operations of MOSS 2007. This includes deploying and managing a Shared Service Provided (SSP), search, business intelligence, business forms, user profiles, my sites, business data catalog, and more. Basically, it’s the same as exam 70-631 but with a focus on the premium out-of-the-box features of MOSS 2007 not included in WSS 3.0. If you want to prepare for this exam, then get familiar with the MOSS 2007 TechNet library.

The last exam is 70-542 (MOSS 2007 Development) is another developer focused exam similar to the 70-541 exam. However, the focus shifts from the WSS object model and features to the MOSS object model and features. This exam assumes that you are comfortable with CAML, the .NET framework, and developing applications with WSS. If you want to prepare for this exam, then get familiar with the MOSS 2007 MSDN library.

Sometimes people also end up asking me if using TechNet and MSDN are enough to prepare for the exams. This totally depends on your experience and your level of familiarity with SharePoint and only you can decide if TechNet and MSDN are enough for you. Rest assured there are lots of good learning resources out there to help you prepare for the exams such as books, classes, and more. If you need helping preparing for an exam and finding classes or other learning resources, then go check out the Microsoft Learning.

Why did this happen?

A few months ago, I explained how WSS deploys and retracts solution packages. In that explanation, I explored how the WSS run-time checks the solution manifest of the solution package (WSP file) and removes any files, features, and other solution components from the file system and content databases. This includes both the SPTHEMES.XML and OOB_SPTHEMES.XML files that were specified in the solution manifest of the theme package. Take a look at the bold-ed lines in the manifest excerpt below:

<?xml version=“1.0” encoding=“utf-8“ ?>
<Solution xmlns=“http://schemas.microsoft.com/sharepoint/”
          DeploymentServerType=“ApplicationServer”
          ResetWebServer=“TRUE”
          SolutionId=“D250636F-0A26-4019-8425-A5232D592C10“>
 <TemplateFiles>
  <TemplateFile Location=“LAYOUTS/1033/SPTHEMES.XML“/>
  <TemplateFile Location=“LAYOUTS/1033/OOB_SPTHEMES.XML“/>
  <TemplateFile Location=“THEMES/MYNEWTHEME/MYNEWTHEME.INF“/>
  <TemplateFile Location=“THEMES/MYNEWTHEME/mossExtension.css“/>
  <TemplateFile Location=“THEMES/MYNEWTHEME/theme.css“/>
  <!–Additional images and icons (gif, jpg, png files)
       can be added here using <TemplateFile> elements –>
 </TemplateFiles>
</Solution>

So when I retracted my theme solution, both the SPTHEMES.XML and OOB_SPTHEMES.XMLfiles were deleted from the file system and the original SPTHEMES.XML was not restored. Luckly, I had a copy of the themes WSP file from which I extracted the OOB_SPTHEMES.XML file and manually copied back to the 12/LAYOUTS/1033 directory. This resolved the odd theme behavior that my environment was experiencing.

Lesson learned?

If you are going to modify files in the SharePoint HIVE in an unsupported manner (such as was the case with the theme package), make sure you have a back up of the original file system files. Like we did with the OOB_SPTHEMES.XML file and make a note on additional steps, aside from solution retraction and deletion, that need to be taken to restore the file system to it’s original state. This means don’t just test the deployment, but also the retraction process before using this type of solution in a production environment.

If you missed the presentation, feel free to take a look at the materials:

• Introduction to the Search Query Object Model [PPTX]
• Introduction to the Search Query Object Model [PDF]
• Sample Code

Oh, and there is one more excellent resource that I forgot to include in the slide deck is the Enterprise Search Team Blog.

Packaging SharePoint Themes

SharePoint themes are an interesting feature in SharePoint that allow site owners to quickly change the appearance of colors, icons, and images buy injecting an additional style sheet that overrides some of the existing styles found in the core.css style sheet. Creating a custom theme involves a couple of simple steps:

1. Creating a new folder in the 12/TEMPLATE/THEMES directory
2. Creating a theme.css file to override the out of the box styles defined in the core.css style sheet in the directory created in the previous step
3. Creating a mossExtension.css file which is appended to theme.css file to create a the actual style sheet that is actually used when viewing pages in the SharePoint site
4. Creating a <directory name>.inf file that contains some basic setup information about the theme
5. Adding all the images and icons referenced in the custom style sheets in step 2 and 3 to the new directory created in step 1
6. Modifying the SPTHEMES.XML file in the 12/TEMPLATE/LAYOUTS/1033 directory

A word of caution! Modifying the SPTHEMES.XML is not a recommended customization practice since this file maybe overwritten by future SharePoint service packs.

It’s easy enough to take an existing theme directory out of the 12/TEMPLATE/THEMES directory, make a copy of it, rename the directory, rename the INF file, edit the INF, theme.css, and mossExtension.css file to create a new theme. However, this approach is not practical in a production SharePoint farm. The practical approach is to use the WSS solution framework to create our own solution package to deploy the custom theme. For more information, I covered the creation of solution packages (WSP files) in detail in a previous post. Let’s take a quick look at the solution manifest for our theme package:

<?xml version=“1.0” encoding=“utf-8“ ?>
<Solution xmlns=“http://schemas.microsoft.com/sharepoint/”
          DeploymentServerType=“ApplicationServer”
          ResetWebServer=“TRUE”
          SolutionId=“D250636F-0A26-4019-8425-A5232D592C10“>
 <TemplateFiles>
  <TemplateFile Location=“LAYOUTS/1033/SPTHEMES.XML“/>
  <TemplateFile Location=“LAYOUTS/1033/OOB_SPTHEMES.XML“/>
  <TemplateFile Location=“THEMES/MYNEWTHEME/MYNEWTHEME.INF“/>
  <TemplateFile Location=“THEMES/MYNEWTHEME/mossExtension.css“/>
  <TemplateFile Location=“THEMES/MYNEWTHEME/theme.css“/>
  <!– Additional images and icons (gif, jpg, png files)
       can be added here using <TemplateFile> elements –>
 </TemplateFiles>
</Solution>

The solution includes a modified SPTHEMES.XML file where we added an element to define the custom theme named MYNEWTHEME. You can also see that we included a copy of the original SPTHEMES.XML file and renamed it OOB_SPTHEMES.XML since it’s always a good idea to have back up copy of the file we modified. Finally, you see the critical MYNEWTHEME.INF, mossExtension.css, and theme.css files. For the sake of brevity, additional image and icon files were excluded on purpose.

The WSP file was then generated using a directive file and the MAKECAB utility (directive files and the MAKECAB utility are also covered in my previous post) and deployed using the STSADM utility.

Packaging Branding

There are many different SharePoint Products and Technologies branding techniques. In the presentation, I demonstrated how quickly and easily we can use a solution to deploy custom style sheets, master pages, and page layouts and how we can use a feature receiver to programmatically apply the branding using the object model. Again for the sake of brevity, the demonstration illustrated how a master page can be deployed and applied. However, a similar approach can be used for page layouts, cascading style sheets, XSL files, image files, and any other branding components and artifacts.

The solution manifest to accomplish our task is relatively basic. Here it is:

<?xml version=“1.0” encoding=“utf-8“ ?>
<Solution xmlns=“http://schemas.microsoft.com/sharepoint/”
          DeploymentServerType=“WebFrontEnd”
          SolutionId=“A250636F-0A26-4019-8425-A5232D592C10“>
 <FeatureManifests>
  <FeatureManifest Location=“MyBranding\feature.xml“/>
 </FeatureManifests>
 <Assemblies>
  <Assembly DeploymentTarget=“GlobalAssemblyCache”
            Location=“CustomThemeFeature.dll“ />
  </Assemblies>
</Solution>

As you can see, the solution manifest only includes a feature manifest and an assembly that will be deployed to the GAC. The assembly only contains a custom feature receiver class that programatically applies the custom master page and the custom theme discussed earlier in this post.

Let’s take a look at the feature manifest:

<Feature xmlns=“http://schemas.microsoft.com/sharepoint/”
         Id=“D250636F-0A26-4019-8425-A5232D592C11”
         Description=“My custom master page feature.”
         Title=“My Custom Branding”
         ReceiverAssembly=“CustomThemeFeature, Version=1.0.0.0, PublicKeyToken=1ff5d2fddf39f61b, Culture=neutral”
         ReceiverClass=“CustomThemeFeature.FeatureReceiver”
         Scope=“Web“>
 <ElementManifests>
  <ElementManifest Location=“elements.xml“/>
  <ElementFile Location=“mycustom.master“/>
 </ElementManifests>
</Feature>

The feature manifest is also pretty simple as it includes one element manifest and one element file. The element file is the custom master page that was created. The element manifest will declare a module that will be used to populate the master page gallery with the custom master page. An important thing to notice here is the ReceiverAssembly and ReceiverClass attributes in the Feature element. These attributes tell the WSS solution framework to use a custom assembly and feature receiver class to handle the feature related events. We will look at the feature receiver class in a bit. First lets take a look the element manifest:

<Elements xmlns=“http://schemas.microsoft.com/sharepoint/“>
 <Module Name=“MasterPages“
         List=“116”
         Url=“_catalogs/masterpage“>
  <File Url=“mycustom.master“
        Type=“GhostableInLibrary“ />
 </Module>
</Elements>

The element manifest is simploy responsible for populating the master page gallery with the custom master page. If our solution and feature also had custom page layouts, those can be added to the master page gallery by adding File child elements to the Module element. Additionally, we could add more modules to populate the style library with custom style sheets and/or XSL files or add other media files to other SharePoint libraries.

Finally let’s take a look at the custom feature receiver class:

using Microsoft.SharePoint;

namespace CustomThemeFeature {
 public class FeatureReceiver: SPFeatureReceiver {
  public override void FeatureActivated(SPFeatureReceiverProperties properties) {
   SPWeb site = (SPWeb)properties.Feature.Parent;
   site.MasterUrl = “/_catalogs/masterpage/mycustom.master”;
   site.CustomMasterUrl = “/_catalogs/masterpage/mycustom.master”;
   site.ApplyTheme(“MYNEWTHEME”);
   site.Update();
  }
  public override void FeatureDeactivating(SPFeatureReceiverProperties properties) {}
  public override void FeatureInstalled(SPFeatureReceiverProperties properties) {}
  public override void FeatureUninstalling(SPFeatureReceiverProperties properties) {}
 }
}

The class simply takes advantage of the feature activated event and to set the values of the master pages and apply a theme to the SPWeb object where the feature is activated.

Similar to the custom theme discussed earlier in this post, a WSP solution file was created using a directive file and the MAKECAB utility. The solution was then deployed with the STSADM utility. The feature was installed with the STSADM utility as well.

The meeting agenda includes two presenters:

• Dan Kruger from Quest Software will be giving us an over view of Quest’s Development Studio for SharePoint.
• Jim Duncan (a former MVP), Senior SharePoint Architect of ShareSquared, will be presenting a dive into Using the Business Data Catalog from SharePoint.

More information is available at http://www.laspug.org/Lists/Events%20Calendar/DispForm.aspx?ID=10

Just remember that I do this in my development environment only. I don’t recommend changing the web.config files in any other environment.

Enabling the Call Stack

Set the value CallStack attribute in the SafeMode element in the web.config file to true.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <configuration>
  ...
  <SharePoint>
   <SafeMode MaxControls="200"
             CallStack="true"
             DirectFileDependencies="10"
             TotalFileDependencies="50"
             AllowPageLevelTrace="false">
    ...
   </SafeMode>
   ...
 </SharePoint>
 ...
</configuration>

Disabling Custom Errors

Set the value of the mode attribute in the customErrors element to Off.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <configuration>
  ...
  <system.web>
   ...
   <customErrors mode="Off" />
   ...
  </system.web>
 ...
</configuration>

Enabiling Compilation Debugging

Set the value of the debug attriute in the compilation element to true.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <configuration>
  ...
  <system.web>
   ...
   <compilation debug="true">
    ...
   </compilation>
   ...
  </system.web>
 ...
</configuration>

 Putting it all together

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <configuration>
  ...
  <SharePoint>
   <SafeMode MaxControls="200"
             CallStack="true"
             DirectFileDependencies="10"
             TotalFileDependencies="50"
             AllowPageLevelTrace="false">
    ...
   </SafeMode>
   ...
 </SharePoint>
 <system.web>
   ...
   <customErrors mode="Off" />
   ...
   <compilation debug="true">
    ...
   </compilation>
   ...
  </system.web>
 ...
</configuration>

Daniel Larson, a MOSS MVP, has been ranting over the past few days about the use of the SPSecurity.RunWithElevatedPrivileges method. While I have been amused with his rants, I share his concerns and frustrations as a result of using the method in my SharePoint development experience and seeing the method abused and missused in many code reviews. Today, he posted a list of his best practices for gaining “elevated privileges” SharePoint.

Daniel Larson’s list of best practives for elevated privileges in SharePoint:

• Avoid using SPSecurity.RunwithElevatedPrivilege to access the SharePoint object model. Instead, use the SPUserToken to impersonate with SPSite.
• If you do use SPSecurity.RunwithElevatedPrivilege, dispose of all objects in the delegate. Do not pass SharePoint objects out of the RunwithElevatedPrivilege  method.
• Only use SPSecurity.RunwithElevatedPrivilege to make network calls under the application pool identity. Don’t use it for elevation of privilege of SharePoint objects.
• Always use the SPSite constructor with an SPUserToken to create an elevated privilege security context in SharePoint. To impersonate the system, use the SystemAccount.UserToken property of the current SPSite context, such as:
  var site = new SPSite(SPContext.Current.Site.ID,  SPContext.Current.Site.SystemAccount.UserToken);
• Avoid passing SharePoint objects between different security contexts (SPSite instances), with the exception of the SPUserToken used in the SPSite ctor. An SPUser object created from SPSite A cannot (reliably) be passed to SPSite B. This can be the source of obscure bugs in production that are difficult to reproduce in development. For example, an SPUser reference created from SPContext.Current.Site cannot reliably be used in an elevated site context, as the user reference may take on a different meaning in the alternate context.
• Never use elevated privilege to bypass security– always use it to work with security.
• Restrict what assemblies can use elevated privilege by running in minimal trust, avoiding the GAC, and auditing any CAS policies deployed with vendor solutions.