SharePoint, especially 2010 release, is becoming more popular as a public site platform – and with an increased number of mobile devices – mobile site experience is expected.

Both SharePoint and SharePoint 2010 have mobile support. When user with a mobile device accesses the site – the site redirects users to a mobile version of the site. In this article we will cover how to make sure that you redirect all of the latest devices to a mobile site as well as how the actual redirect happens.

If you Navigate to the root of your SharePoint site in IIS (Ex. C:\Inetpub\wwwroot\wss\VirtualDirectories\80) you will locate App_Browsers – the folder that contains browser definitions. In order to ensure you have support for all of the latest browsers – you can download the latest browser definition file (mobile.browser) from codeplex – Mobile Device Browser File (credit goes to Mark Bice for this one) .

Now copy the mobile.browser file you downloaded to Devices folder in App_Browsers which you will have to create.

If you worked with ASP.Net before you probably know that HttpContext has a property that will determine whether your browser is a mobile browser – HttpContext.Current.Request.Browser.IsMobileDevice . This will ordinarily return false unless you have an up to date mobile.browser file – so keep your browser definitions current.

What happens next is really up to you. You can create a user control in the masterpage of your SharePoint site; the user control will have a code behind that will determine whether the current browser is a mobile device browser and redirect users to more simplified version of a site.

Here is how my user control code behind could look like:

HttpRequest req = HttpContext.Current.Request;

string pageName = req.Url.Segments[req.Url.Segments.Length - 1];

string mobileUrl = MobileHelper.getMobilePage(pageName);

if (HttpContext.Current.Request.Browser.IsMobileDevice)

{   if (!string.IsNullOrEmpty(mobileUrl))

{        Response.Redirect("~/Mobile/Pages/" + mobileUrl);    }

else    {        Response.Redirect("~/Mobile/Pages/" +

MobileConstants.NotFoundPage);    }   }

Good Luck!

If you worked with timer jobs in SharePoint (both MOSS and 2010) – you know that those execute on Web Application level. There in Central Administration you can see all of the definitions and statuses of running job. In SharePoint 2010 you can even change the schedule of those definitions.

The most typical way to provision new timer job is to use Web Application scoped feature which will all the definition to SharePoint  - which basically is a record in SharePoint configuration DB.

If you open SharePoint central administration and take a look at the list of timer job definitions – you will see that some of them are scoped to various site collection. In fact there are duplicates of the same timer job definition running on several sites.

So how do you provision site collection specific timer job from Web Application scoped feature?

Here is one of the ways to do it. Assuming your site inherits from a custom site template, we can enumerate web application site collections that have that template and provision our time job as we normally would once we find our site template.

The code would look like this:

public override void FeatureActivated(SPFeatureReceiverProperties

properties)

{

SPWebApplication webApp = properties.Feature.Parent

as SPWebApplication;

foreach (SPSite site in webApp.Sites)

{

string template = site.RootWeb.WebTemplate.ToString();

if (template == "MYTEMPLATE")

// code to execute for this site collection to provision a job

}

}

One of the other ways to do it, is to accept feature parameters which will denote your Url in this case you would use:

webApp.Sites[site].Url

One of the things that becomes an issue though is when you use an automated tool to deploy your site – your web application gets created first – seemingly activating all the dependent features. In our case this means that actions will be taken on site collections that don’t yet exist.

In this case, you would need to activate your features manually once the structure has been provisioned using your automated tool.

Good Luck!

One of the cool features in SharePoint 2010 is it’s ability to easily upgrade the site from MOSS. Just recently I have been upgrading a heavily customized site that had custom branding (and I’m talking custom-custom), JQuery calls to web services, custom web parts targeted for SharePoint 2010, site definitions, page layouts and many more. The upgrade went seamlessly and I think I was asked less questions than when I installed MS Excel.

As soon as the site is upgraded you will see all of the 2010 features available and event some of the icons in system UI will look 2010-ish; your Central Administration will have 2010 UI. Your site however, will still be based of UI Version 3 (MOSS). You can upgrade it by using Visual Upgrade :

You will be given 3 options:

Use the previous user interface
Preview the updated user interface
Update the user interface

Usually when your site definitio(s) use custom master page, you will break your site when upgrading the UI to version 4. You will get an error message similar to this:

“Cannot find ContentPlaceHolder ‘PlaceHolderCSSLayout’ in the master page ‘/_catalogs/masterpage/v4.master’, verify content control’s ContentPlaceHolderID attribute in the content page.”

In case your users broke the site this way – you can always restore it back to the previous version by either using an upgrade page on your site: _layouts/prjsetng.aspx

or programmatically by updating the value of the SPWeb object of your root site collection site:

SPWeb web = SPContext.Current.Web; // or web you want to access

web.UIVersion = 3; // 3/4 version
web.UIVersionConfigurationEnabled = true; // is upgrade option locked?

here you can also toggle whether you want to see upgrade option in Site Actions menu event though the upgrade has been successful – in case you want to toggle between UI versions in your development environment.

Good Luck!

SharePoint 2010 allows you to create custom alert templates per list, meaning you can customize what’s going to show up in your SPList alert body.

In this example I won’t focus how you can actually edit the alert CAML – you can figure it out based on existing list of templates, let`s see what`s involved in creating a new alert template and assigning it to the list:

1. Create a new Visual Studio 2010 SharePoint solution.

2. Map a TEMPLATES folder in your solution directory and create a new folder underneath it called XML. This XML folder will contain an XML file that will define your alerts.

3. Create a new file in sub folder (project specific name) inside XML folder in your solution and add XML File into a sub folder.

4. Navigate to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\XML on your file system and open alerttemplates.xmlthis is out-of-the-box alert definition that you should not modify. Take a loot at the structure of the file and how each alert is defined.

5. Copy alert definition of the list type that closely resembles what you want your new alert to look like ad paste it into your solutions custom alert XML file. If we were to copy generic list template – everything including the XML below would have to be copied:

<AlertTemplate Type="List" 

Name="SPAlertTemplateType.GenericList">
</AlertTemplate>

6. Make any adjustments to the custom alert CAML (this is something you will have to figure out based on your needs).

7. Create a new site scoped feature which will add our custom alert template to the list of your choice and not to any other list on the site.

8. Add a receiver to the feature and in FeatureActivated method place the following code:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    SPSite site = properties.Feature.Parent as SPSite;

    XmlDocument xmlDoc = new XmlDocument();

    // The path to your alert templates
    xmlDoc.Load(SPUtility.GetGenericSetupPath(@"XML\YourProject")

+ "YourAlertTemplates.xml");

    // The list you want to have custom alert template
    SPList list = site.RootWeb.Lists["YourList"];
    SPAlertTemplate template = new SPAlertTemplate();
    template.Xml = xmlDoc.InnerXml;
    template.Name = "YourAlertTemplate";

    list.AlertTemplate = template;
    list.ParentWeb.AllowUnsafeUpdates = true;
    list.Update();
}

Above is going to take care of loading the template and assigning it to the list.

Now when this code is executed and template loaded to the list – new alert that are triggered with the template are going to come with the definition you have specified in your custom alert template file.

Good Luck!

Let’s say you have few site collections each representing separate department within organization; you want to enable your users to be able to search each department site separately to narrow down their results. In another scenario – you may have many site collections representing client site – where the structure of lists and libraries is still the same – yu may also want to help your users with searching those sites by creating a scope specific to the URL of the current site collection.

You can set up site collection scope using UI – but if you have many sites or you need to create scopes as a part of automated site provisioning – it’s much eaasier to create those programatically.

Assuming you are using SharePoint feature to do the job, here is how your feature.xml is going to look like:

<?xml version="1.0" encoding="utf-8"?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
 Id="BBDCB6EC-833D-4b99-A93D-19E16B0B4ED0"
 Title="Set Search Scopes"
 Description="Set Search Scopes"
 Version="1.0.0.0"
 Scope="Web"
 Hidden="False"
 ActivateOnDefault="FALSE"
 AlwaysForceInstall="TRUE"
 ReceiverAssembly="MyAssembly, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=0bcd2fea03ff3d79"
 ReceiverClass="MySolution.SetSearchScopes">
  <ElementManifests>
  </ElementManifests>
</Feature>

And here is the feature receiver FeatureActivated method contents :

using (SPWeb web = properties.Feature.Parent as SPWeb)
{
    SearchContext searchctx = null;

    searchctx = SearchContext.GetContext(web.Site);

    Scopes scopes = new Scopes(searchctx);

    Scope currentScope = scopes.AllScopes.Create(
        "CurrentScopeName", string.Empty, new Uri(web.Site.Url), true,
        string.Format("{0}/Search/Pages/Results.aspx", web.Site.Url),
        ScopeCompilationType.AlwaysCompile);

    currentScope.Update();

    currentScope.Rules.CreateUrlRule(ScopeRuleFilterBehavior.Include,
        UrlScopeRuleType.Domain, web.Site.Url);

    ScopeDisplayGroup group = scopes.GetDisplayGroup(new Uri(web.Url),
        "Search Dropdown");

    group.Add(currentScope);
    group.Update();

    scopes.StartCompilation();
    scopes.Update();
}

As you can see our feature is activate on a root web level and passes on the context of the current site collection. This context is used to create a new scope and to create a rule which will filter out all of the results except the results coming from the existing site collection:

currentScope.Rules.CreateUrlRule(ScopeRuleFilterBehavior.Include,
        UrlScopeRuleType.Domain, web.Site.Url);

To try it out – install this feature in your farm and activate it – when you navigate to Search Settings of your site – you will notice a new scope created with a name specified under Search Dropdown  group.

Good Luck!