SharePoint Web Services Wrapper

Recently I noticed that a common reason for developers to seek help on the MSDN forum is related to difficulties understanding and/or utilizing the SharePoint Web Services. You can’t blame the developers. It’s much more convenient to work with an Object Oriented API, rather than exchanging XML messages with a Web Service. For example, take a look at the Lists.asmx -> GetListItems. Of course it’s no rocket science, but it will sure save time if you could avoid dealing with the XML directly.

I spent some time researching if there is some kind of a library out there which provides ‘managed’ access to those Web Services. I.e. – work with .NET objects, rather than construct and parse XML elements. The closest thing I have found is this and it’s totally outdated and incomplete. At least it’s some reassurance to me that I am not missing the big picture and indeed, there might be people who would appreciate such framework.

So, I decided to start a project which will try to implement such .NET Object Oriented API around the SharePoint Web Services. Of course, for those corner weird cases (as well for the advanced developers), the underlying XML will still be accessible. Here is a good description of all the SharePoint services. My goal is to cover them all, eventually. I will start with the most commonly used ones.

It is hosted on CodePlex –
The project is not published yet, as there is no single line of code written yet. I will be doing this in my spare time. Once I shape it to my liking, it will become open source and everyone is welcome to contribute.

Got comments? Suggestions/Objections? There is a similar library already implemented? Please do let me know.



SharePoint bug udating title of uploaded xml

Another interesting case…

Programmatically upload an xml file (extension should be .xml) to SharePoint document library. As soon as you upload it, try to change the Title field of the item.

So here is the code:

// We upload the file to SharePointSPFile file = Web.Files.Add(itemUrl, buff, true);Web.Update();

string newTitle = "Sample Title";SPListItem destItem = file.Item;destItem.File.CheckOut();// Try to change the titledestItem["Title"] = newTitle;destItem.UpdateOverwriteVersion();destItem.File.CheckIn(string.Empty,SPCheckinType.MinorCheckIn);

For any non-xml extension files it works, but for xml files the Title doesn’t change – it remains the same as the original name of the uploaded file. If you try doing this with another field of the item, it would work.

I came up with the following workaround:

SPFile file = Web.Files.Add(itemUrl, buff, true);Web.Update();

string newTitle = "Sample Title";SPListItem destItem = file.Item;destItem.File.CheckOut();destItem["Title"] = newTitle;destItem.UpdateOverwriteVersion();

// Work-around startdestItem["Title"] = newTitle;destItem.Update();// Workaround end

destItem.File.CheckIn(string.Empty, SPCheckinType.MinorCheckIn);

Anyone has clue what’s going on? Original MSDN forum thread is here.

Extending SharePoint Web Part


SharePoint provides a lot of different out-of-the-box Web Parts. But sometimes we wish a particular web part behaved in a little different way, or have some small extra functionality. Or we may want to implement a heavily modified Web Part, based on already existing one.

Today, I will show you how to extend the functionality of an already existing web part.

We will take for example the SharePoint RSS Viewer. It loads an RSS feed and visualizes it in a web part on a SharePoint site. One of its visible properties in the UI is the Feed URL. It’s a static string and doesn’t allow any kind of dynamic parameters. Example:


Those placeholders in my example are fictional, but you should get the idea of a dynamic value passed as a parameter to the service.

Our goal is to override the default behavior of the Feed URL field. We want to get to a point where we actually control how the Feed URL is being interpreted. We may want to replace placeholders with actual values, or do any other kind of adjustment of the URL, based on current and dynamic conditions. So here is the plan: we create a new web part, inherit the RSS Viewer web part and extend the Feed URL property.

Let’s start. Here is how the RSS View part settings look like in edit mode:

See the RSS Feed URL field? That’s what we are interested in.

Ok, start Visual Studio 2008 with the VSeWSS plugin installed. From the menu, start a new SharePoint -> Web Part project.

Give it a full trust

Change your namespace to something you prefer (for example, I will change it to HristoYankov). Rename the folder ‘WebPart1’ to ‘RSSAggregatorWebPartDynamicParam’. It will rename all classes and files for you. In the Solution Explorer, expand Properties and open AssemblyInfo.cs. Add this to the bottom:
[assembly: AllowPartiallyTrustedCallers]

and this to the top:
using System.Security;

Your Solution Explorer should look similar to:

Right click on your project, click on Properties, go to the Debug tab and set the SharePoint site URL you will be deploying to.

Open the RSSAggregatorWebPartDynamicParam.webpart file and set Title and Description to whatever you like.

Now, after your project is setup, starts the interesting part. Let’s inherit the RSS View control! What you need to do is…

Add this file as a reference – C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\microsoft.sharepoint.portal.dll. This is where the RSS View class is defined.

Open your RSSAggregatorWebPartDynamicParam.cs file and change your class from this:
public class RSSAggregatorWebPartDynamicParam : System.Web.UI.WebControls.WebParts.WebPart

to that:
public class RSSAggregatorWebPartDynamicParam : RSSAggregatorWebPart

And add this statement:
using Microsoft.SharePoint.Portal.WebControls;

Basically, we no longer inherit the basic WebPart class. Instead, we now inherit the whole functionality of the RSS Viewer web part and all of its user interface!

You can also delete this function, as we are not going to do any changes there.
protected override void CreateChildControls()

So far so good. Now let’s override the Feed URL property! Add this to your class:

[DefaultValue(""),Resources("RSSWebpart_Property_FeedUrl_Text","RSSWebpart_ToolPart_Group","RSSWebpart_Property_FeedUrl_Description"),Personalizable(PersonalizationScope.Shared),WebBrowsable(true)]public new string FeedUrl{get{return base.FeedUrl;}set{base.FeedUrl = value;}}

And add this statement:
using System.ComponentModel;

Three things to note here:
1. The FeedUrl property is the one which handles the URL which points to the RSS feed.
2. Note the attribute on top of the property. If you don’t add it, it won’t be visible in the UI
3. Note the ‘new’ keyword. This way we hide the underlying base FeedUrl property.

Ok, now we have control over the Feed URL. What we should do, is change the way FeedUrl is being returned. Change your get to look like:

get{return OverrideURL(base.FeedUrl);}

And create this function:

private string OverrideURL(string url){// TODO: Process the URLreturn url;}

So, in OverrideURL we can change any way we like the URL that is set in the User Interface and then return it modified. At this point, it is up to you how to utilize this capability.

For the purpose of the example, let’s just look for the string #current_date# in the URL and replace it with the current date.

private string OverrideURL(string url){return url.Replace("#current_date#", DateTime.Now.ToShortDateString();}

At the end, your code should look like:

using System;using System.Runtime.InteropServices;using System.Web.UI.WebControls.WebParts;

using Microsoft.SharePoint.WebPartPages;using Microsoft.SharePoint.Portal.WebControls;using System.ComponentModel;

namespace HristoYankov{[Guid("03badfa9-53e4-401a-bc60-28db88b202ac")]public class RSSAggregatorWebPartDynamicParam : RSSAggregatorWebPart{   public RSSAggregatorWebPartDynamicParam()   {   }

   [DefaultValue(""), Resources("RSSWebpart_Property_FeedUrl_Text", "RSSWebpart_ToolPart_Group", "RSSWebpart_Property_FeedUrl_Description"), Personalizable(PersonalizationScope.Shared), WebBrowsable(true)]   public new string FeedUrl   {       get       {           return OverrideURL(base.FeedUrl);       }       set       {           base.FeedUrl = value;       }   }

   private string OverrideURL(string url)   {       return url.Replace("#current_date#", DateTime.Now.ToShortDateString());   }}}

Now, right click your project and do ‘Deploy’. It should add a RSSAggregatorWebPartDynamicParam assembly to your GAC. When you go to your SharePoint site and do ‘Edit Page’ -> ‘Add Web Part’

you should be able to see your newly created web part listed in the pop up. Add it to the page. Put it in Edit Settings mode and set the Feed Url to something like:

It will be replaced by:
http://servername/service/Param1=06/06/2009 (for example)

NOTE: I just noticed this – as soon as you set the URL which contains the ‘placeholder’, the web part which is still in edit mode starts showing it with a replaced value (the date). I believe that the underlying value is still http://servername/service/Param1=#current_date#. So perhaps, in the method OverrideURL we should be taking into consideration if the web part is in edit mode. And if it is – just return the original parameter that was passed. Something like:

private string OverrideURL(string url){if (this.NotInEditMode){// Not in edit mode, perform changesreturn url.Replace("#current_date#", DateTime.Now.ToShortDateString());}else{// We are in edit mode, return URL as isreturn url;}}

I will be checking this later. As usual, you can get the full source code here.

But basically that’s it. With minimum amount of code and effort, we have extended the functionality of an already existing web part, to something that serves our concrete needs.

Hope this was helpful!

SharePoint Solution Hello World Tutorial


In this post, I will explain to you how to create your first SharePoint 2007 ASP.NET application. We will cover what tools you would need and what are the steps to creating a SharePoint Hello World app! I will keep the article short and clear on the necessary steps to be followed.

First, let’s start with the tools. You will need Visual Studio 2008 SP1 (preferably) this freely available plugin for it Visual Studio 2008 extensions for Windows SharePoint Services 3.0. It is a toolset for developing custom SharePoint applications: Visual Studio project templates for Web Parts, site definitions, and list definitions; and a stand-alone utility program, the SharePoint Solution Generator.

We assume that you have setup and you do have available a SharePoint site, on which we will be deploying our solution.

So, start your Visual Studio 2008. From the menu choose to start a new Project.

Visual Studio will show this window. Select GAC and proceed.

Your Solution Explorer would look like this, initially:

We need to create a couple of folders. Recreate the folder structure described in the screenshot below:

Right click on HelloSharePointWorld and select add new item. Select text file, but name it “Hello.aspx”

Put the following content in your newly created ASPX page.

<%@ Page Language="c#"Inherits="Hello, SharePointHelloWorld, Version=,Culture=neutral, PublicKeyToken=3cf44204a7ad1f1e"MasterPageFile="~/_layouts/application.master"%>

<asp:Content ID="Content1"ContentPlaceHolderID="PlaceHolderMain"runat="server"><asp:Label ID="lblLabel1" runat="server" Text="Hello World!"></asp:Label></asp:Content>

Note the PublicKeyToken value. It will be changed later. Now, create a new class in the App_Code folder. Name it Hello.aspx.cs. Your directory structure should look like:

The content of your Hello.aspx.cs should read:

using System;using Microsoft.SharePoint.WebControls;

public partial class Hello : LayoutsPageBase{ protected void Page_Load(object sender, EventArgs e) { }}

Right click on your project, select Properties from the menu. Go to the Debug tab and set the hostname and port number of the SharePoint site where you want your project to be deployed.

Then save.

Now, right click on your project in Solution Explorer and rebuild it. Then right click on it and Deploy.

Now, open Windows Explorer and navigate to C:\WINDOWS\assembly. You should see an assembly called SharePointHelloWorld there. Right click it and select Properties.

Copy the Public Key Token (highlighted, note that it would be different for you) and click Cancel button. Now go back to your ASPX page in the project and replace the incorrect Public Key Token with the one you just copied.

Redeploy your application. Start Internet Explorer and navigate to http://%5Bserver name]:[port]/_layouts/HelloSharePointWorld/Hello.aspx

You should see something similar to:

Congratulations, you have created your first SharePoint solution. If you start the Central Admin for SharePoint and go to Operations -> Solution Management you should see a solution named sharepointhelloworld.wsp.

Let’s add one more modification. Open the Hello.aspx.cs file and change it to:

using System;using Microsoft.SharePoint.WebControls;using System.Web.UI.WebControls;

public partial class Hello : LayoutsPageBase{ protected Label lblLabel1;

 protected void Page_Load(object sender, EventArgs e) {     lblLabel1.Text = "Hello world! Time is: " +     DateTime.Now.ToString(); }}

By that, we utilize the code behind to output data on the screen. Rebuild, redeploy and refresh the page.

This is a good starting point for further learning by experimenting and example.

Of course, the full code for this project can be found here.

SharePoint 2010 overview

SharePoint is a collection of products and software tools by Microsoft that mainly provides collaboration functions, process management, searching and document management. Currently, the most popular version is SharePoint 2007. At this very moment Microsoft is working very hard on releasing the next version of the product – SharePoint 2010. This article will try to cover areas such as: what new features will be there, what changes from developer’s standpoint, what are the requirements, release date and others.

The product is no longer code-named “14”. The official name is Microsoft SharePoint Server 2010. The ‘Offfice’ part of the name finally drops out. The Office brand will no longer include Server side components (such as SharePoint). It now clearly refers to the client applications, such as Word, Excel and etc.

On a separate note, Exchange 2010 will be shipped separately of Office (beta is out already).

New Features

  • Groove (document collaboration application, acquired by Microsoft) is now being renamed and transformed into Microsoft Office SharePoint Workspace 2010.
  • SharePoint 2010 is not going to support Internet Explorer 6 (awesome). However, it will be supporting Firefox 3.x on Windows and perhaps even Firefox 3.x and Safari on non-Windows platforms.
  • Master Data Management (MDM) will be integrated with Office 14.
  • SharePoint 2010 will be able to interact with other CMS systems through CMIS.
  • You will be able to map SharePoint lists directly to database tables, which will provide great performance and scalability, especially on large lists.
  • There will be Silverlight support and maybe AJAX!
  • SharePoint Designer will support saving workflows to re-use for provisioning.
  • BDC might support Updating and Inserting data
  • Faceted Search
  • FAST Search for SharePoint. A new version of FAST Search for SharePoint at a lower cost.
  • “Web edit”“Microsoft has made it much easier for users to customize their own sites in SharePoint 2010. A new feature called Web edit allows site owners to edit their sites almost as if they were typical Office documents, making it easier for them to carry out common Web editing tasks like uploading and changing images or editing text.”
  • Other user-focused upgrades include the ability to use Office themes in SharePoint, for example by customizing a team site with the color palette of a SharePoint slide deck.
  • Read Visio documents in SharePoint
  • Improved administrative capabilities with a dashboard that uses the ribbon interface
  • Set of tools to monitor server farm health and data performance
  • Standardized UI across all Office products, browsers, mobile devices
  • Open API support

The free (and light) WSS version of the product will still be available, although there is no much information regarding it. Microsoft announced that it will get a lot of new features and will be a “great release”.

Developer tools
So, having said all that, what changes from the developer perspective? Is our life going to become easier, or even harder?

Microsoft announced “deep support for industry standards” and the main development tool will be Visual Studio 2010. It will ship with comprehensive support for development in all SharePoint areas – Web parts, features, solutions, content types, etc.

Deploy and debug from VS
You should be able to build, deploy and debug SharePoint applications directly from Visual Studio! If this is true, it will save us a lot of time!

Also, there will be a new Server Explorer window within VS, which we will use to explore SharePoint objects such as: Sites, Lists, Documents and other.

The Feature Designer embedded in Visual Studio 2010 will provide a detailed look at all the components of a Feature.

Package Explorer will provide you a WYSIWYG view to your package. You should be able to re-arrange items within the package by drag&drop!

There is extended support and integration of the Team System, if you are into this kind of a Source Control.

It is a good idea to start getting prepared for this release of SharePoint, as it has very specific system requirements.

  • SharePoint 2010 will be 64-bit only
  • SharePoint Server 2010 will require 64-bit Windows Server 2008 or 64-bit Windows Server 2008 R2.
  • SharePoint Server 2010 will require 64-bit SQL Server 2008 or 64-bit SQL Server 2005.
  • As mentioned, IE 6 won’t be supported.

Out of the article:
So, what can you do today to get into the best shape for SharePoint Server 2010?
1. Start by ensuring new hardware is 64-bit. Deploying 64-bit is our current best practice recommendation for SharePoint 2007.
2. Deploy Service Pack 2 and take a good look at the SharePoint 2010 Upgrade Checker that’s shipped as part of the update. The Upgrade Checker will scan your SharePoint Server 2007 deployment for many issues that could affect a future upgrade to SharePoint 2010.
3. Get to know Windows Server 2008 with SharePoint 2007, this post is a great starting point.
4. Consider your desktop browser strategy if you have large population of Internet Explorer 6 users.
5. Continue to follow the Best Practices guidance for SharePoint Server 2007.
6. Keep an eye on this blog for updates and more details in the coming months.

And here are two interesting Q&As:

Q: Why are you only supporting the 64-bit versions of SQL Server 2005 or 2008 for SharePoint Server 2010?
A: This decision was based on our current test data for SharePoint Server 2010 and real world experience from customers running SharePoint Server 2007 with 32-bit SQL Server. SharePoint performance and scalability can benefit significantly from 64-bit SQL Server and the throughput increases are significant enough for us to make the difficult decision to only support SharePoint Server 2010 on 64-bit SQL Server 2005 or 2008. It has been our strong recommendation for some time that SharePoint Server 2007 customers take advantage of 64-bit SQL Server due to the inherent performance and scale benefits it can provide.

Q: Where can I find more information on the advantages of 64-bit hardware and guidance on how to migrate SharePoint from 32-bit to 64-bit.
A: These two TechNet articles are a good starting point;

Release date
According to Chris Capossela (senior vice president of Microsoft’s Information Worker Product Management Group) SharePoint 2010 will enter a technical preview in the third quarter of 2009 and will release to manufacturing in the first half of 2010.

Microsoft announced that it is now testing the software in an invitation-only technical preview, with a public beta to follow later this year. It focuses on a number of its enterprise customers and target specific enterprise deployment scenarios.

So, there is still some waiting to be done. But waste no time, instead, start preparing your 64-bit environments!

SharePoint regional settings double value bug

Here is an interesting one…

I had to set the regional settings of my SharePoint site to Hungarian, so the DateTime fields get localized properly. This has been discussed previously here.

However, I started experiencing problems with the double values. Explanation by example:
(myField is of type SPFieldNumber)

double myDouble = 123.45;
myField.DefaultValue = myDouble.ToString();

Basically, I am trying to assign the value of a type double variable as the default value of my SharePoint field (which I am about to render).

At this point, when I check (using Quick Watch in Visual Studio) the value of myField.DefaultValue it shows 123,45 (which is ok, for the localization I am using). However, myField.DefaultValueTyped shows 12345. Looks like SharePoint is ignoring the fact that the site is localized and does not consider ‘,’ to be in the role of a ‘.’

The solution I came up with is:
double myDouble = 123.45;
myField.DefaultValue = myDouble.ToString(CultureInfo.InvariantCulture);

Perhaps it is not the best, but at least the output now is:
myField.DefaultValue = “123,45”
myField.DefaultValueTyped = 123.45

Which is what is expected! Let me know if you know of a better way!

stsadm command line error

There is a common problem with stsadm being executed from the command line. For example, you run:
stsadm -o installfeature -name [featurename]

And you get “Command line error.” in the console. It is because you have copy/pasted the command from your browser or somewhere else. There is a problem with the encoding.

Solution: Type the command in the console window, don’t paste it.

Hope this helps.