Enhancements for SharePoint 2010

There are a number of platform and tool enhancements for SharePoint 2010.

I picked out a few favourites which I briefly explain below:

• LINQ to SharePoint (Language Integrated Query)
• Data Platform Improvements
• List Enhancements
• Business Connectivity Services
• Silverlight Integration
• Managed Client Object Model
• Sandbox Solutions
• Visual Studio 2010 for SharePoint
• WSP Changes
• Developer Dashboard
• Dialog Framework
• SharePoint Designer 2010
• Visio Services
• InfoPath (changes)
• Windows PowerShell

LINQ to SharePoint (Language Integrated Query)
LINQ is a feature of the programming languages C# and Microsoft Visual Basic .NET. Compilers are included with Visual Studio.
LINQ adds a SQL-like syntax and vocabulary to each of the languages, which can be used to query data sources. But unlike other languages and query syntaxes which vary from one type of data source to another, LINQ can be used to query, in principle, any data source whatsoever. For this reason, developers may find that it is the only query syntax that they ever need to know.
The LINQ to SharePoint Provider is defined in the Microsoft.SharePoint.Linq namespace. It translates LINQ queries into Collaborative Application Markup Language (CAML) queries. more details here...


Data Platform Improvements
The data platform improvements include: List Relationships, Unique Column Constraints, Data Validation, Column Formula Validation, etc
more details here... 

List Enhancements
The list enhancements in SP2010 include: Bulk Operations, New capacity limits(more details here..), XSLT Views (more details here..)

Business Connectivity Services (BCS)
BCS is a set of services and features that provide a way to connect SharePoint solutions to sources of external data and to define external content types that are based on the external data. External content types resemble content types and allow the presentation of and interaction with external data in SharePoint lists (known as external lists), Web Parts, Microsoft Outlook 2010, Microsoft SharePoint Workspace 2010, and Microsoft Word 2010 clients. External systems that Microsoft Business Connectivity Services can connect to include SQL Server databases, SAP applications, Web services (including Windows Communication Foundation Web services), custom applications, and Web sites based on SharePoint. more details here... 

Silverlight Integration
In Windows SharePoint Services 3.0, you could host a Microsoft Silverlight application in a Web Part. Microsoft SharePoint Foundation 2010 goes beyond by providing a built-in, extensible, Silverlight Web Part specifically designed to host Silverlight applications. Closely related to the new Web Part is Silverlight Cross-Domain Data Access (Silverlight CDA) that enables secure, cross-domain, integration between Silverlight applications and SharePoint Foundation deployments, and Silverlight CDA can be used by non-Silverlight external applications as well. more details here...

Managed Client Object Model

The SharePoint Foundation 2010 managed client object model lets you write client-side code to work with all the common objects in SharePoint sites. Through the object model, you can add and remove lists, add, update, and delete list items, change documents in document libraries, create sites, manage permissions of items, and add and remove Web Parts from a page.
With the SharePoint Foundation 2010 managed client object model, you can design client applications that access SharePoint content without installing code on the server that runs Microsoft SharePoint Foundation 2010. For example, you can build new categories of applications that include writing applications that are based on the Microsoft .NET Framework, rich interactive Web Parts, Microsoft Silverlight applications, and ECMAScript (JavaScript, JScript) applications that run client-side in a SharePoint Web Part.
more details here...

Sandbox Solutions
You can deploy a Microsoft SharePoint Foundation 2010 solution directly onto your SharePoint Foundation farm, or you can deploy the solution into a sandbox. A sandbox is a restricted execution environment that enables programs to access only certain resources, and that keeps problems that occur in the sandbox from affecting the rest of the server environment. 

Solutions that you deploy into a sandbox, cannot use certain computer and network resources, and cannot access content outside the site collection they are deployed in.
more details here... and here.

Visual Studio 2010 for SharePoint
A number of areas for SharePoint developers in Visual Studio 2010 are worth mentioning. First, you get SharePoint project templates in the box, so you can start right away on solution development. Second, tooling has standardized on the Windows SharePoint Package (WSP) packaging standard, so when you import or deploy a solution to SharePoint, Visual Studio treats it as a solution package. Third, some great deployment and packaging features, such as solution retraction and custom deployment configurations, ship with the SharePoint tools in Visual Studio 2010. And last, the new SharePoint Explorer provides a view into native and custom artifacts (for example, lists and workflows) that exist on your SharePoint server.

WSP Changes
SharePoint 2010 improves the WSP format so that it is supported across all tools, allowing you to export your site through the browser, SharePoint Designer, and Visual Studio. This means that you can quickly upgrade or downgrade your solutions between the tools.

SharePoint Online, the Microsoft - hosted version of SharePoint, supports this format so that you can move solutions to the cloud without having to rework the package.

Developer Dashboard
The developer dashboard is a new feature in SharePoint 2010 that is design to provide additional performance and tracing information that can be used to debug and troubleshoot issues with page rendering time. The dashboard is turned off by default, but can be enabled via the object model or stsadm (and PowerShell too, I just haven’t put together the script for it yet). When the dashboard is turned on you will find information about the controls, queries and execution time that occur as part of the page rendering process; this information appears at the bottom of the page.

more details here...

Dialog Framework
SharePoint 2010 has a new framework for showing dialogs to the end-user. The dialogs allow people to work with some data without losing focus on the page they were working on to get things done. Closing the dialog will often cause AJAX based refreshes to give a sense of stateful-ness.

The dialog is of course extensible through JavaScript code. You can either show a separate page, or use a DOM element on the source page and show that. You can then determine when the dialog closes and what happens when it has closed.

more details here...

SharePoint Designer 2010
There have been a large number of changes to SharePoint Designer. 

For a nice overview go to this post

Visio Services
Visio Services in Microsoft SharePoint Server 2010 is a service application that lets users share and view Microsoft Visio Web drawings. The service also enables data-connected Microsoft Visio 2010 Web drawings to be refreshed and updated from various data sources. 

Visio Web drawings (*.vdw files) can be rendered by Visio Services and viewed in a Web browser. This lets users view Visio documents without having Visio or the Visio Viewer installed on their local computer. Basic exploration and navigation of these rendered Web drawings are supported within the Visio Web Access Web Part. Page designers can configure the user interface and functionality of the Web Part. 
Visio Services can also refresh the data and recalculate the visuals of a Visio Web drawing hosted on a Microsoft SharePoint Server 2010 site. This enables published Web drawings to refresh connections to various data sources and to update affected data graphics and text fields. more details here...

InfoPath 2010 (changes)
InfoPath 2010 comes with a large number of enhancements which includes: 
Easy customization of list forms with InfoPath, an InfoPath Form Web Part, Forms with code-behind can be deployed using sandbox solutions, creating a site template will produce a WSP package which includes the InfoPath forms, Forms Services forms now support WCAG 2.0 standard, InfoPath forms can be made available offline using SharePoint Workspace 2010, Forms Services also support FireFox and Safari. 
more details here... and here. 

PowerShell for SharePoint 2010
Windows PowerShell is a command-line scripting tool that provides an administrator full access to applicable application programming interfaces (APIs), along with the ability to unlock the capability to interact directly with SharePoint 2010 Products to manipulate Web applications, site collections, sites, lists and much more. In addition, the administrator has the ability to script cmdlets (pronounced "command-lets"), which makes for an improved experience from past product versions.  more details here... and here

Other enhancements (not covered in this post):
Access Services
Central Administration (Redesigned)
Digital Asset Management
Enterprise Search
Excel Services
Health Monitoring
Managed Metadata
PerformancePoint Services
Enhanced Records Management
Changes to Social Computing (previous called Collaboration)
Upgrade

very nice and usefull for sharepoint 2010 blog

http://johanolivier.blogspot.com/2010/08/sharepoint-2010-ribbon-enabled-web-part.html

http://virtualizesharepoint.com/category/sharepoint-2010-search/

http://www.sharepointkings.com/2010/09/sharepoint-cascading-drop-downs-using.html

SharePoint solution to deploy InfoPath Form template as administrator approved form template

An InfoPath form template can be published into SharePoint in many ways. Below are the options available to you when you try to publish an InfoPath Form from Microsoft Office InfoPath application.

• Form Library: You can publish the info path form template as a template in a form library.
• Site Content type: You can publish this form template into a library in a site collection which will then be accessible by a content type. This content type can be used by multiple libraries.
• Administrator approved form template: Administrator can upload the form template in central admin form template gallery which can then be enabled into a specific site collection. When a template has been activated in a Site Collection, a copy of the template is stored in Site Collection “Form Templates” library which can be used by multiple sites, libraries within that site collection.

There might be times when you would want to be able to deploy/activate these form templates automatically via a SharePoint solution eliminating the manual processes. In this post, I will show you how you can package an InfoPath Form template into a WSP solution file and deploy it as administrator approved template. This will automatically, upload the template into the Central Admin Form Template gallery and also activate that form template to a Site Collection.

Tools: Microsoft Office InfoPath Designer 2010, Visual Studio 2010 Professional, SharePoint Server 2010

1) Create a new blank form using InfoPath Designer 2010 and add some controls to it. Mine looks like this.

2) Go to form options and in the security section, set the security level to “Domain”. Read more about the security level here.

3) Then you need to publish the form template. Mind you that we are not going to publish this form template directly into SharePoint server. This form template will be automatically published into SharePoint by our solution. So, we will publish this form template into a network location and include it in our SharePoint Solution.

Go to Publish section in InfoPath Designer and choose “Network Location”.

Select the published path with filename. Then go to next step.

Leave the input textbox blank and select next. You will receive a warning but you can ignore it for now.

After publish, you will get a screen like this.

4) You can now verify if this template can be uploaded into SharePoint server using “Upload form template” in central admin site.

select the published form template and then click verify. You should receive a message stating that the template is ready to be uploaded to the server.

5) Create a SharePoint 2010 project in Visual Studio 2010 and select “Module” to be added.

6) Opt to deploy as a farm solution

7) I’ve changed the name of the feature to “InfoPathDeploymentFeature”, “Module1” to “InfoPathFormModule” and also removed the default sample.txt file from the module.

 Add the published InfoPathForm.xsn file, one we created earlier, under the “InfoPathFormModule” element. Select the xsn file and in the properties windows, under “Deployment Location” property, clear the path value. The Elements.xml file now looks like this.

9) Change the scope of the feature to “Site”. 

10) Double click the feature and in the properties window, set the values for “Receiver assembly” and “Receiver class” as below.

Receiver Assembly: Microsoft.Office.InfoPath.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c

Receiver Class: Microsoft.Office.InfoPath.Server.Administration.XsnFeatureReceiver

11) Check the SharePoint url where you are deploying this feature. Make sure that the feature “SharePoint Server Enterprise Site collection features” is already activated in that site. You can add feature activation dependency also.

12) Then in the packaging explorer, select the module “InfoPathFormModule”. Then you can add features properties from the properties window. These are very important, if you do not add them, the form will not be uploaded in central admin form templates gallery. The manifest will then look like this.

13) Buid and deploy the project.

Check the form templates in the central admin at this locaiton: Central Admin->General Application Settings->Manage form templates. you will see that the template has been uploaded.

You will also notice this form template has already been activated to the site collection where we deployed the feature.

Go to Site Settings->Site Content Type, you’ll see that a content type by the name “InfoPathForm” has been automatically created. This means that now, we can just add this content type into a form library which we can use to fill out our info path form through browser.

So create a new form library, change it to allow management of content types, and add the “InfoPathForm” content type to that library. The settings of content type will now look like this.

You will now see a new content type option available when we create new document which will open our infopath form in browser. But to enable the infopath forms to be displayed in browser, you need to configure the form library which you can do by setting the value of “Openinig document in browser” to “Open in browser” in settings of the library.

14) Lastly, click on the new content type in form library, which will open the info path form in a web page.

I have also uploaded the Visual Studio 2010 Project which you can downloaded. Also, I will follow up on this post with other enhancements like feature receiver that will automatically add InfoPath content type to form library, promoting InfoPath Form fields into form library columns etc.

Reference: http://sandeepnakarmi.com.np/2011/03/sharepoint-solution-to-deploy-infopath-form-template-as-administrator-approved-form-template/

Customizing the user experience: Overview of the default interface

Refer:
http://sharepointmagazine.net/series/sp-userexperience

Customizing search
http://sharepointmagazine.net/series/customizing-sharepoint-search

Introduction to SharePoint Feature Stapling

Features allow you to add new functionality to SharePoint or make simple site customizations in an easy and consistent way. Features can be scoped to the Farm, Web Application, Site, and Web level depending on the purpose of the feature. The basis of a feature is implemented using a feature.xml file, but may also contain other supporting files. More information on Features can be found on the Microsoft MSDN site at http://msdn.microsoft.com/en-us/library/ms460318.aspx.
The focus of this article is going to be on a concept called Feature Stapling. Most, if not all, SharePoint developers know that Microsoft frowns on modifications to the “Microsoft” owned files that support SharePoint. If you modify these files you run the risk of your changes being broken with the installation of a service pack or hot fix. Sometimes this was your only option when attempting to customize SharePoint back in the WSS 2.0 days. The following KB article that outlines the supported / unsupported scenarios when it comes to modifying the default site definition files (http://support.microsoft.com/kb/898631).
Feature Stapling allows you to create a feature and then associate it with any site definition without ever touching the site definition files themselves. Your feature will be executed when the site is being provisioned.
As you read this series of articles I hope to explain how Feature Stapling works through the creation of a working feature and feature stapling example. I will also touch on some important points and considerations you need to be aware of about when in the life cycle of a site being provisioned your feature will be executed.

Feature Stapling

Feature Stapling is achieved through the creation of another feature that defines the association of your regular Feature and the site definition you want to “staple” it too. In other words, you need to create two Features to achieve a complete Feature Stapling implementation.

Creating Feature

There are many different recommendations on how to go about creating SharePoint Features within Visual Studio from the layout to the deployment. In this article, I am going to use the method that works best for me. I use Visual Studio 2008, a class library, and WSP Builder (http://www.codeplex.com/wspbuilder). WSP Builder is what I ultimately use to generate my solution file; however, it does have some features such as Copy to 12 Hive, and Recycle Application Pools that I used while creating my Feature.
In this scenario, I want to capture the Title and URL of any site that was created using the Team Site template in a central location.
Step 1: Create the 12 hive folder structure down to my actual Feature, created a strong named key, and added a reference to the Microsoft.SharePoint.dll assembly.
The following is a screen capture of my project in Visual Studio:

Step 2: Add a new class file in the root of the project folder called SampleFeatureReceiver.cs and use the following code:

using System;
using Microsoft.SharePoint;
 
namespace Liebrand.Sample
{
    public class SampleFeatureReceiver : SPFeatureReceiver
    {
        public override void FeatureActivated(SPFeatureReceiverProperties properties)
        {
            using (SPWeb web = (SPWeb)properties.Feature.Parent)
            {
                if (web.IsRootWeb)
                    return;
 
                using (SPSite site = web.Site)
                {
                    using (SPWeb rootWeb = site.RootWeb)
                    {
                        SPList createdSites = GetProvisionedSitesListId(rootWeb);
                        SPListItem newItem = createdSites.Items.Add();
 
                        newItem["Title"] = web.Title;
                        newItem["Url"] = web.Url;
                        newItem.Update();
                    }
                }
             }
        }
 
        private SPList GetProvisionedSitesListId(SPWeb rootWeb)
        {
            try
            {
                SPList list = rootWeb.Lists["Provisioned Sites"];
                return list;
            }
            catch (ArgumentException)
            {
                Guid listId = rootWeb.Lists.Add("Provisioned Sites",
                    "This list contains all the sites that have been provisioned.",
                    SPListTemplateType.GenericList);
 
                SPList list = rootWeb.Lists[listId];
 
                list.Fields.Add("Url", SPFieldType.URL, false);
                SPField field = list.Fields["Url"];
 
                SPView view = list.DefaultView;
                view.ViewFields.Add(field);
                view.Update();
 
                list.Update();
 
                return list;
            }
        }
 
        public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
        {
        }
 
        public override void FeatureInstalled(SPFeatureReceiverProperties properties)
        {
        }
 
        public override void FeatureUninstalling(SPFeatureReceiverProperties properties)
        {
        }
    }
}

This code basically adds the URL of the site being provision to a listed called Provisioned Sites that is located in the root site. If the list is not found, the list is created.
Step 3: Add a new XML file called feature.xml to the feature folder and paste the following contents:

"1.0" encoding="utf-8" ?>
"http://schemas.microsoft.com/sharepoint/"
         Id="2B3451F0-BC93-41A4-9FAD-3A81861D651A"
         Title="Liebrand Feature Sample"
         Description="This is a feature that will be used to demonstrate feature stapling."
         Scope="Web"
         Hidden="False"
         Version="1.0.0.0"
         ReceiverAssembly="Liebrand.Sample, Version=1.0.0.0, Culture=neutral, PublicKeyToken=057a20dd10f3b267"
         ReceiverClass="Liebrand.Sample.SampleFeatureReceiver">

Note: The Id attribute value was generated using the Create GUID menu item from the Tools menu in Visual Studio.

Creating the Stapling Feature feature

At this point, our primary Feature is ready to go. The last step is to simply create another Feature that will associate my LiebrandSample Feature with the Team Site site definition.
Step 1: Add another folder under the FEATURES folder called LiebrandSampleStapler and add a file called feature.xml then paste the following contents into it:

"1.0" encoding="utf-8" ?>
"http://schemas.microsoft.com/sharepoint/"
         Id="C384D136-79A8-48BD-AF73-C630547F4D8E"
         Title="Liebrand Sample Stapler"
         Description="This feature staples the LiebrandSample feature to the Team Site site definition."
         Scope="Farm"
         Hidden="False"
         Version="1.0.0.0">

  
    "elements.xml" />
  

Step 2: Add a XML file called elements.xml to the LiebrandSampleStapler folder and paste the following:

"1.0" encoding="utf-8" ?>
"http://schemas.microsoft.com/sharepoint/">
  "2B3451F0-BC93-41A4-9FAD-3A81861D651A"
                                  TemplateName="STS#0"/>

The ID attribute in the FeatureSiteTemplateAssociation element should match the ID of the Feature we created at the beginning of this article. The TemplateName attribute should match the site definition name and configuration ID found in the webtemp.xml file located in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1033\XML. Since we want to associate our new Feature to all Team Site sites we specify STS#0. STS is the name of the Template and 0 is the configuration ID for the Team Site.
At this point we are ready to deploy our new features and test it out.

Deployment

First build your project to insure you have no build errors and to generate the assembly Liebrand.Sample.dll.
To deploy these new Features using WSP Builder simply,

• Right-click on the project name and select WSPBuilder, then click Copy to GAC. This will copy the assembly into the Global Assembly Cache.
• Right-click on the project name and select WSPBuilder, then click Copy to 12 hive. This will copy the 12 hive folder structure in your project to the SharePoint 12 hive folder

• Install and activate the Features by running the following commands:

stsadm -o installfeature -name LiebrandSample
stsadm -o installfeature -name LiebrandSampleStapler

Test

At this point you can create a new sub-site using the Team Site template and you should see a new list called Provisioned Sites get created at the root site with a new entry added that will point back to the site you created.
After creating 3 team sites, this is what the Provisioned Sites list looked like:

Welcome to part 2 of my Introduction to SharePoint Feature Stapling. In part 1 I explained the process of creating a feature stapler and associating it with a site definition. In this small post, I’ll be providing some insight into the feature stapling lifecycle and also providing some potential solutions to some of the downsides of the feature stapling process.
Feature Stapling Lifecycle
The actual lifecycle of the feature stapling process is not documented actually documented anywhere. The following information has been solely gathered based on my testing and experimenting with the process.
If we step back and look at a site definition file we know that the GLOBAL#0 site template is applied to all site definitions. Many of the Microsoft provided site definitions enable functionality through the use of the feature system. If you open up the STS site definition ONET.XML file, you will see two sections near the bottom called SiteFeatures and WebFeatures:

You will notice that in many of the Windows SharePoint Services site definition files the ListTemplates section is not populated with anything; they use list definition features instead. As you can see, the Team Site site definition points to a feature called TeamCollab. This feature makes list definitions available to the web that is being created.
So what does this all mean when it comes to feature association? The important thing to remember here is that any feature receivers you develop and associate to a site definition will get executed before any of the lists on that site have been provisioned. However, anything provisioned via the Global Site Definition will be available to your feature receiver.
This is not a problem if you simply want to create new lists, libraries, etc. However, if you are attempting to manipulate any lists that are part of the site definition you are associating with you will find yourself looking at a System.ArgumentException stating “Value does not fall within the expected ranged.”
The following image shows what happens when I create a Team Site that has my custom feature receiver associated to it:

Solution
We have already determined that feature receivers make it extremely easy for a developer to extend and customize out of the box site definitions without touching the files. But we run into a road block when we attempt to customize the lists and libraries that are part of that site definition.
One way I have used to get around this is to simply delay the customizations until after the site has completely provisioned.
The following is an example using the ThreadPool.QueueUserWorkItem method:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    using (SPWeb web = (SPWeb)properties.Feature.Parent)
    {
        ThreadPool.QueueUserWorkItem(new WaitCallback(RunProcess), web.Url);
    }
}
 
private void RunProcess(object state)
{
    Thread.Sleep(5000);
 
    string url = (string)state;
    using (SPSite site = new SPSite(url))
    {
        using (SPWeb web = site.OpenWeb())
        {
            // at this point, the site should be provisioned
            // and we will now have access to all lists on it
            SPList list = web.Lists["Shared Documents"];
            list.Description = "Updated from Feature Receiver";
            list.Update();
 
        }
    }
}

Why are we running on a different thread? Well, this allows the site provisioning process to complete and then we come back in a few seconds later to customize it as needed. Of course, the sample above is not 100% perfect. What happens if it takes 10 seconds to provision a site – well the method above would fail out.
A more elegant way would probably be to check the SPWeb.Provisioned property which is False until after the provisioning process has completed; but you get the general idea

Summary

Features Stapling offers a great way for developers to extend, change, or customize the out-of-the-box site definitions without ever touching them. Hopefully this article gives you an idea of where you can utilize Feature Stapling. In the next article of this series, I am going to cover when Feature Stapling occurs in the creation of a site and some key points you need to be aware of when it comes to what elements are available to you when your feature is executed.