At the SharePoint Conference in Las Vegas, Paul Andrew gave a thorough overview of the new features for developers in SharePoint 2010.

This is my modest attempt to convey Paul’s presentation in a simple blog post. Please note that the session contained a huge amount of information and I probably (definitely!) didn’t manage to take it all in. Read on at your own risk…

Development environment and tools

Traditionally, the path to your first SharePoint hello world-web part is littered with technical obstacles in the shape of tedious installation problems, Windows Server 2003 blues, virtual server nightmares etc. No more. Now you just need your laptop to develop SharePoint applications.

The box

SharePoint developers no longer need to run a Windows 2003 Server. In fact, SharePoint and the development tools can now be installed directly on Windows 7 or Vista (service pack 1). Either versions of SharePoint can be used, i.e. SharePoint Foundation (formerly WSS) or SharePoint Server.

The operating system must be 64 bit since SharePoint 2010 only runs in a 64 bit environment.

SharePoint on a desktop operating system is just for developers and not for running a production environment.

Visual Studio 2010

Many of SharePoint 2010’s new features can be accessed from inside Visual Studio 2010. Also, quite a few third-party add-ons may not be needed anymore as the functionality is now covered by Visual Studio.

Highlights:

• Built-in designers for:
• Web parts
• BCS (formerly BDC)
• Workflows
• Package and deploy SharePoint projects
• Generate WSPs
• View SharePoint sites in server explorer
• Integration to Team Foundation Server
• Support for SharePoint sandboxed solutions
• WSPs from SharePoint Designer can be imported (including workflows)
• Build workflow steps for SharePoint Designer
• SharePoint Business Connectivity Services support
• New events projects templates

General improvents

Developer dashboard

A developer dashboard can be displayed automatically at the bottom of every page. The DD displays valuable information about how the page is generated, for instance:

• Timing and duration of events
• Database queries (even the ones SharePoint does in the background)

The DD is activated with the follow stsadm command:

stsadm –o setproperty –pn developer-dashboard –pv ondemand

Coding

Coding for SharePoint just got slightly easier due to the many improvements in .NET framework 4.0 and SharePoint 2010.

Below is a rundown of some of the new features:

• LINQ for SharePoint
• After-synchronous events
• New event types:
• Site-scoped events
• Web creation events
• Workflow improvements:
• Initiation and association forms in Visual Studio
• New design user interface for workflows in SharePoint Designer
• Use Visio 2010 to design workflows
• SharePoint UI can now be saved as a template
• WSP is now the unified developer format – works in site collections and machine

Improvements to lists

In SharePoint 2007, lists can cause any developer headaches. Hopefully, the new list architecture in SharePoint 2010 will solve this. Below is an overview of some of the improvements:

• Validation with Excel-like Formula – forms can be validated using simple syntax
• Lookup to multiple columns
• Lookup fields have true relations which ensure proper deletion (transaction-style)
• List index auto-creation
• Scalability and performance vastly improved:
• Lists and folders can now contain a million elements
• Document libraries can contain 10 million documents
• List query throttling
• Lists views no longer based on CAML but XSL-T. Queries still use CAML

Ribbon and Dialog framework

The ribbon we know (and some love) from Microsoft Office is now used in SharePoint 2010.

Some of the highlights:

• Custom actions can be embedded in the ribbon
• The ribbon is context sensitive
• The SharePoint out-of-the-box forms are replaceable
• New web dialog functionality:
• A dialog floats on top of the SharePoint page and is used to get input from the user
• Fully programmable

Silverlight 3

Silverlight plays an important part in SharePoint 2010 and is used in many of the improved UI elements. From a developer’s point of view, these are the highlights:

• Built-it and customisable media player web part
• List and site creation from within Silverlight
• Office web applications run in Silverlight
• Client object model – call SharePoint APIs from within Silverlight

Last year we at PeopleNet ran into a problem when using lists with many columns, i.e. around 1600!

Indexing such a list would almost always fail with a timeout or out of memory error in the log, even though SharePoint is supposed to be able to handle at least 2000 columns without performance issues.

We corresponded back and forth with a Microsoft support engineer about the problem and it turned out that lists with many multiple value lookup fields will bring the SQL Server to its knees fairly quickly.

Microsoft has recently released a KB article in relation to this, however, it doesn’t specifically single out multiple value lookup fields as the culprit, although they almost always are.

As a SharePoint developer you’ve probably run into this problem several times: How to make sure that links to application pages stay valid irrespective of where within a site collection your web part is placed.

If you hand-code links you’re likely to get the path relative to the root site wrong. Even worse, if the the filename of an application page is changed, e.g. from DispForm.aspx to DispFormNew.aspx, your links will surely break.

The application pages

Generally, a SharePoint list contains the following application pages:

• AllItems.aspx
  Shows all items in the list
• DispForm.aspx
  Displays a read-only version of a list item
• NewForm.aspx
  Form for creating a new list item
• EditForm.aspx
  Form for editing an existing list item

More applications pages exist but these are the ones most commonly used.

Ensuring unbroken links programmatically

The PAGETYPE Enumeration gives you access to the application pages and enables you to build links that always work.

Assuming you have already created your SPList and SPListItem objects the below snippet builds a link to the correct DispForm:

Of course, the same applies to NewForm and EditForm.

Linking to the default view of a list

Below a list of elements you may wish to link to the underlying list’s default view. In many cases this will be the AllItems.aspx page but what happens if a user changes the default view in the settings of the list? If you’ve hardcoded a link to AllItems.aspx you may be lucky that the link still works but if AllItems.aspx has been renamed or removed, you’re out of luck.

Instead of hardcoding the link you should use PAGE_DEFAULTVIEW, like this:

Simple, isn’t it?

Here’s a quick tip for you: How to check if the latest version of an element in a SharePoint list is published.

Once you’ve got hold of an SPListItem, you can check the Versions property (an array containing all the versions of the element).

In this block of code IsPublished becomes True if the latest version is published:

That’s it.

I’ve gatherered a few productive tips for using JavaScript within SharePoint. The below commands can be used within webparts etc. or directly in the browser’s address field while you’re on a SharePoint page, like this:

Putting javascript: in front of your script snippet will fire it right there and then.

These commands are neither terribly advanced nor applicable on all pages, but they make for a useful reference all the same. I aim to continually update this page with new content so if you have any JavaScript tips, feel free to drop them in the comments.

Edit an application page: MSOLayout_ToggleLayoutMode()

This enables edit mode on SharePoint’s application pages, like EditForm.aspx, DispForm.aspx etc. so you can insert web parts above or below the normal content:

Pop-up an alert with the User ID og the logged-in user: alert(_spUserId)

Enable the Edit toolbar: javascript:__doPostBack(‘ctl00$PlaceHolderTopNavBar$SiteActionsMenuMain$ctl00$wsaShowMenu_CmsActionControl’,'reviewPage’)

Simply enables the toolbar where you can access the page edit functions:

Hide the Edit toolbar: __doPostBack(‘ctl00$PlaceHolderTopNavBar$SiteActionsMenuMain$ctl00$wsaHideMenu_CmsActionControl’,'exitMenu’)

No prizes for guessing this one.

Show help: TopHelpButtonClick(‘NavBarHelpHome’)

Pops up the built-in help page. Interestingly, you can try this on Microsoft’s SharePoint Conference web site:

As most companies are moving to the 64-bit platform of Windows Server and MOSS, more SharePoint developers are adopting this as their main dev environment.

However, if you plan to develop SharePoint workflows in Visual Studio 2008 on your new 64-bit box, you’re going to be disappointed.

Upon creating a new workflow in VS, an “Object reference not set to an instance of an object”-error pops up:

You can still get to the next step in the process where you have to chose the site which will be used to debug the workflow. Here too, you will be faced with an error:

The solution

Well, there isn’t any. Not right now anyway.

The only thing you can do is to continue developing in your old 32-bit environment and then move your WSP to the 64-bit box for installation.

All this is not a bug per se, rather, it’s down to Microsoft’s lack of resources in their dev team:

 
(source)

Hmm…

Many of you have probably encountered the problem where a workflow triggers itself several times because the code carries out one or more Item.Update() commands. This can be extremely annoying because running extra workflows can be taxing on the server – even if you make sure that the extra workflows don’t make any changes to the element.

Then, you may have discovered Item.SystemUpdate() which in theory should rid the list of the all the extra instances of workflows because it doesn’t trigger an update event and thus flies under the radar of the workflow engine.

This seemed to work just fine for a while. Lately, however, it seems that SystemUpdate() has startet triggering events just like a normal Update().

Post Service Pack 1?

I found that many of my workflows now started behaving differently, i.e. they began triggering multiple instances of workflows.

It took me a while to realise that it probably was a “bug fix” in SharePoint SP1 that was causing the problem.

A glance at the documentation for SystemUpdate() reveals that events are indeed triggered:

There is no mention of SP1 but I assume that this was when the changes were made.

Solution

This is bad news for many developers but obviously a design decision at Microsoft so things probably won’t be changed back to the way they were.

From now on you have to make sure that your workflows only make changes to elements when needed. I.e. you need to only use Update() and SystemUpdate() when they are really needed and thereby minimise the number of redundant workflow cycles.

Alternatively, you could look into programming your own event handlers to obtain more granular control of when events are triggered. I may explore this subject in a future post.

Sometimes you may need your web part to perform tasks for which the current user doesn’t have priviliges. For instance, we needed a sign up form for our WCM web site where the user could enter contact information that should be stored in a list.

Naturally, our web site runs with anonymous access and the the anonymous users do not have access to the underlying lists, including the list where the contact information goes.

Thus, submitting to the list is not just a matter of doing an Items.Add() because this causes a login dialogue to pop up and ultimately a 401 Unauthorized error.

Normally you’d create an element in the list with code similar to this:

However, if the logged-in user doesn’t have sufficient credentials to write to the list, a login dialogue will pop up.

Run with Elevation

To get around this problem you can use SPSecurity.RunWithElevatedPriviliges() like this:

For this to work, you need to instantiate the SPSite and SPWeb objects inside delegate():

Now the list will be updated with a new element, created by the system account.

The lack of a built-in overview of all users in SharePoint makes it difficult to create a simple phone book of your company’s employees. The object UserProfileManager would be the obvious starting point if you were to create your own phone book for SharePoint – and many have tried this. Google this object and you’ll find that the only real way to query all users effectively is using the built-in web services of MOSS.

Specifically, UserProfileService (http://server/_vti_bin/userprofileservice.asmx) is ideal for querying user profiles from e.g. within a web part.

In Visual Studio, when you’ve set up the web service, you connect to the web services like so:

Then, you can query the number of profiles in the user profile database by calling the method GetUserProfileCount:

Knowing the number of user profiles, you can iterate through them and pull the user data:

Some names show up several times

You will find, however, that GetUserProfileByIndex only holds information about users whom have active MySites. Strangely enough, even if the total number of users exceed the number of users with MySites, you can still iterate through all the user profiles you found with GetUserProfileCount.

Say, you have the following people in your User Profile database:

1 – Ted Pattison
2 – Liam Cleary
3 – Amanda Murphy
4 – Yvonne Harryman
5 – Steve Pietrek

Let’s assume that Amanda and Yvonne don’t have MySites. Then the output of the above loop would look like this:

1 – Ted Pattison
2 – Liam Cleary
3 – Liam Cleary
4 – Liam Cleary
5 – Steve Pietrek

GetUserProfileByIndex will not fail when you loop through 5 profiles because that is the number of profiles present in the database. On the other hand, querying a profile that doesn’t have a MySite, e.g. GetUserProfileByIndex(3) and GetUserProfileByIndex(4), will return the latest user with a MySite, in this case Liam Cleary (index no. 2).

Solution

In order to avoid this situation the value stored in NextValue can be used. NextValue contains the index of the next user with a valid MySite user profile. Looking at the first table again, the NextValue values are shown in parentheses:

1 – Ted Pattison (2)
2 – Liam Cleary (5)
3 – Amanda Murphy (5)
4 – Yvonne Harryman (5)
5 – Steve Pietrek ()

The following line can then be added to the loop to ensure that the next profile to be shown contains usable information:

Now you just need to output all the information in an SPGridView and the phone book is ready to be implemented.

It’s simple, really. Whenever you install a web part, it probably needs a few settings to work properly.

Maybe the web part needs to know the name of a specific list to be able to gather information and display it to the user. Or perhaps it requires the email address of the person who should receive status updates from the web part.

In any case you want the web part to be able to store simple textual and persistant information to be used in your code. You may of course decide to store this information in, say, a SQL Server table but – unless you need to store vast amounts of information – this is overkill and makes installation of the web part unecessarily difficult.

Custom web part properties to the rescue

You can add your own properties to the tool pane which appears when you access the settings of a web part in the browser. You can even make your properties appear in its own section, like this:

To achieve this, first add the following namespaces to your web part code:

Then, for each property you need, insert a code block similar to this:

Note that Category, WebDisplayName and WebDescription are optional but they do make your custom property much more readable for the end user.

In the above example, propEmail contains the default value of the property.