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.

Silverlight in SharePoint – Basics of Hello World!

I’m going to build a Silverlight application that can be hosted from within a SharePoint web part. We will use Visual Studio 2010 to build a simple “Hello World” type application, but add a few touches to make our application configurable.
In SharePoint 2010, we have an out of the box Silverlight web part that can host almost any Silverlight application. For now, we will utilize this built-in web part and later in the series, we will create our own web part to host our applications.
The Silverlight application in this example asks the user to enter 3 words. The words can also be configured through the Properties of the web part. These words will be passed to the Silverlight application, which will render these words in an animated way.

Developing a Simple Silverlight application

You can create a simple Silverlight 4 application using Visual Studio 2010. If you need more complex design you will need tools like Microsoft Expression Blend, but the sample Silverlight application for this article can easily be build in Visual Studio 2010 using the Silverlight Application template.
When creating a Silverlight application with Visual Studio 2010, you will be asked which version of Silverlight application you want to design. For this sample I selected Silverlight 4. You can also indicate whether you want to create a test web site or not. As the sample needs to communicate with SharePoint, it cannot be easily tested running outside the SharePoint context, so I choose not to host the Silverlight application in a web site.

When a Silverlight application is created, the following parts are automatically added to the project:

App.xaml	The App.xaml file is typically used to declare resources that can be used throughout the application. These resources consist of brushes, styles and animations.
App.xaml.cs	The App.xaml.cs file is the code behind file for the App.xaml and can be used to handle application level events. There is already a method stub for the Application_Startup, Application_Exit and Application_UnhandledException events available. When the Silverlight application initializes the Application_Startup event is triggered. I typically use this event handler to retrieve the incoming parameters.
MainPage.xaml	The MainPage.xaml file is by default the initial UI control. Within this UI control you can start defining the user interface.
MainPage.xaml.cs	The MainPage.xaml.cs file is the code behind for the MainPage.xaml. The events generated in the UI control are handled here. You can also dynamically load controls in code behind and consume WCF services, or communicate with SharePoint using the Silverlight Client object model.

Besides these parts a Silverlight application can also contain other user controls, other classes and interfaces.
The point of entry of the Silverlight application is the Application_Startup method. The StartupEventArgs argument contains information on how to initialize the Silverlight application. One of these elements is the InitParams dictionary. It can be used to pass information from SharePoint to Silverlight.
The Silverlight application in this sample accepts 3 words that will be rendered using storyboards. The values are stored in static variables that can be accessed form within the different controls that make up the Silverlight application .

public static string Word1 = null;
    public static string Word2 = null;
    public static string Word3 = null;

The Application_Startup method looks as follows:

private void Application_Startup(object sender, StartupEventArgs e)
    {
        if (e.InitParams != null)
        {
            Word1 = GetParam(e.InitParams, "word1");
            Word2 = GetParam(e.InitParams, "word2");
            Word3 = GetParam(e.InitParams, "word3");
        }
        this.RootVisual = new MainPage();
    }
    private string GetParam(IDictionary<string, string> initParameters,
        string paramName)
    {
        if (initParameters.ContainsKey(paramName)&&         
            ! string.IsNullOrEmpty(initParameters[paramName]))
        {
            return initParameters[paramName];
        }
        else return null;
    }

The last statement in the Application_Startup method shown above initializes the main user control of the Silverlight application. The XAML of this control is very simple and contains the following elements:

• a Canvas: this is the root control of the user control.
• 3 TextBox controls: these will be populated with the words passed in
• 3 Storyboard elements: these element are responsible for making the words mover over the screen from bottom to top.
• a Circle which represents the dot of the sentence.
• a fourth Storyboard that will move the dot over the screen as flying comet.

The code behind of the MainPage user control is stored in the MainPage.xaml.cs file and starts storyboard after storyboard: when the first storyboard finishes, the second is started and so on. The following code snippet demonstrates this technique:

private void StartAnimation()
{
   Word1TextBlock.Visibility = Visibility.Visible;
   Storyboard sb = (Storyboard)this.FindName("MoveWord1");
   if (sb != null)
      sb.Begin();
}
private void MoveWord1_Completed(object sender, EventArgs e)
{
   Word2TextBlock.Visibility = Visibility.Visible;
   Storyboard sb = (Storyboard)this.FindName("MoveWord2");
   if (sb != null)
      sb.Begin();
}

That’s it for the code in the Silverlight application.

The Silverlight Web Part

Now it is time to deploy the Silverlight application to SharePoint. The easiest way is to upload the .xap file to a document library. In this demo I’ll upload it to a document library with the name XAPS. SharePoint 2010 comes with an out of the box Silverlight web part. You can add this web part to any SharePoint page and host your Silverlight application from within it. You can add this web part to for example the home page. When in the Web Part Gallery, you can find the Silverlight web part in the Media and Content category.

When you choose to add a Silverlight web part to your page, a dialog pops up asking you to enter the location of your Silverlight application.

In the editor part of the web part you can enter the initParams string requested by your Silverlight application. In this sample you have to pass the name of the list where the service offerings are stored. Scroll down in the editor part and expand the Other Settings section. There you can enter your initialization parameters. If you have a parameter to pass, you have to specify the name of the parameter followed by an equal sign and the value:

param1=value1

If you have more than one parameter to pass, you’ll have to separate them with a comma:

param1=value1,param2=value2

Pay attention not to add spaces in between. The maximum length of this string is 255 characters. If you need to pass more data, you’ll have to use a workaround. These workarounds will be explained in further articles of this series.
Our parameter string exists of 3 words:

The initialization parameters are passed to the Silverlight application as a comma separated string but inside the Silverlight application it comes in as a dictionary as a property of the StartupEventArgs argument of the Application_Startup method.

Once you set the initialization parameters you can click the OK button of the web part. The Silverlight application will rendered on the page.

If your Silverlight application doesn’t show on the page, it is possible you have typed an error in the path to the Silverlight application, you can always correct by editing the web part and clicking the Configure button in the Properties pane.