This post was most recently updated on September 30th, 2022.

2 min read.

This post describes the easiest (probably) and most straightforward way of creating a new Thread in your SharePoint (or any other .NET) server-side/desktop code.

Solution

Let’s face it – one should not create new Threads lightly when developing SharePoint solutions, but sometimes it is difficult to avoid. Or sometimes it’s just the simplest way to get around weird framework limitations.

This one time we were developing a pretty simple functionality, where we needed to create a few fields on a certain title when the user activated a feature. However, because of the complexity of the environment, we encountered problems while changing the title of the new field. Now, that’s usually pretty simple, but this time some other functionality, most likely developed by someone else, was changing it to the internal field name – which doesn’t look too good.

So, to resolve the case we just extracted our list handling code from the feature activation and started it as another background thread. Instead of building a somewhat heavy and long-running functionality as part of the feature activation, in which it’ll freeze the UI and have a limited runtime before the user doesn’t want to wait anymore, we just fired off a new thread that’ll run as long as it takes.

Time needed: 1 minute

How to create a New Thread

Add a reference to System.Threading
Like here:

using System.Threading;
Example of a Thread-creating code on SharePoint
Thread thread = new Thread(delegate()
{
// example: let a background thread take care of adding fields
// to a SharePoint list while the UI stays responsive
listFieldsUpdateSuccess = Helper.EnsureListFields(list);
// rest omitted for clarity
});
thread.IsBackground = true;
thread.Start();

This, of course, applies to server-side code (like a full-trust solution, a .wsp-package).

However, the same pattern works for most .NET-based environments, it’s not really SharePoint-specific.
Take care of the lifecycle of your thread
Depending on what you’re doing, you might or might not need to verify that your application doesn’t shut down before the thread is finished!

You might not need to worry about this (if you know your application will just stay running), or you might need to do something like:

thread.Join();

Just please note, that this will in turn block the calling thread.

That’s it! Easy to do in most .NET environments.

But for my particular case – SharePoint – to be honest I’m not even sure, why this worked. I suspected it might be because of the current culture of the thread, but changing it didn’t have any effect. Sometimes SharePoint is weird, you know?

Anyway, I’m glad this worked, whatever the reason for that is.

Author
Recent Posts

Antti K. Koskela

Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.

He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.

This is his personal professional (e.g. professional, but definitely personal) blog.

Latest posts by Antti K. Koskela (see all)