I recently published a new online training course about Developing Custom Timer Jobs for SharePoint 2013! Over 1300 students have signed up so far! Once you sign up, you get lifetime access to the course and materials (which are periodically updated). There are no monthly subscription fees or anything like that.
This course goes beyond the simple mechanics of creating a job definition and deploying it with a feature. Some examples of what’s covered include:
- The different types of jobs you can create and the considerations in choosing one type over the other
- How jobs are represented in SharePoint’s configuration database and why you should care (hint: it has to do with troubleshooting)
- Some different base classes beyond SPJobDefinition that can save you time in different scenarios
- How to properly report errors and progress from your jobs
- Choosing how to manage configuration data for your jobs (options, trade-offs, etc.)
- Testing and debugging timer jobs
And while this course focuses on SharePoint 2013, most of the content applies to SharePoint 2010 as well.
As a SharePoint developer, I frequently need to generate new GUIDs. If I happen to have Visual Studio open, I’ll often just use the GUID generator tool that’s built into Visual Studio.
However, if I’m working on a machine where VS isn’t installed or if I need a format that’s not supported by the normal GUID generator tool, PowerShell comes in extremely handy! Most modern Windows machines already have PowerShell installed, so why not use what you already have?
For example, let’s say I’m logging onto a machine running SQL Server and I need to generate a new GUID for a database record. Supposing that server is running any modern Windows OS, I can just follow these steps to generate a GUID:
- Hit the Windows ‘START’ key on my keyboard, and type ‘PowerShell’ into the search box (remember this will be on the START screen if using Windows 8 or Windows Server 2012).
- Open a Windows PowerShell command window.
- Type this command: [System.Guid]::NewGuid()
- Copy the GUID out of the command window (right-click on window title bar and select Edit > Mark) and now my GUID is on the clipboard!
That’s it. No need for Visual Studio or any GUID generation tools.
But what if you want a specific format? Easy. Just add ToString() to the end of the above PowerShell command and pass it the format specifier you want. If you want curly braces and lowercase letters, for example, then call [System.Guid]::NewGuid().ToString(“b”).
Here’s a page on MSDN that lists the format specifiers you can use: http://msdn.microsoft.com/en-us/library/97af8hh4.aspx
While happily writing code and enjoying a fresh Spring breeze through my office window today, I received an ominous email from a user at a client’s company. The email said the user was trying to edit the membership of a group in SharePoint when they saw this:
An error occurred during the compilation of the requested file, or one of its dependencies. Warning as Error: 'System.Web.UI.Page.GetPostBackEventReference(System.Web.UI.Control)' is obsolete. 'The recommended alternative is ClientScript.GetPostBackEventReference. http://go.microsoft.com/fwlink/?linkid=14202.'
This seemed very odd to me because the URL of the page was “/_layouts/people.aspx,” which is obviously an out-of-the-box page that’s supposed to work. Also, this error was only happening on one of the three zones we’d configured for this web application. The page loaded fine in the other two zones. I did some searching online but didn’t find anything useful other than one guy saying he’d restored the DLLs in the SharePoint ‘ISAPI’ folder from a backup and that fixed the problem for him.
In hopes of getting a better error, I enabled debugging in the web.config file for the zone where the user was seeing this, including setting “<compilation debug=’true’ />.” The next time I loaded the site the problem was gone. So it appears that causing ASP.NET to recompile the web app was sufficient to solve the problem. When I finished testing I turned debug mode off and everything still worked.
Assuming you have the appropriate permissions and server access to run PowerShell cmdlets against your SharePoint 2010 or 2013 farm, here’s a super quick way to get the current build verison of your farm:
Sample output from 2 farms of mine:
- SharePoint Server 2010: 14.0.6129.5000
- SharePoint Server 2013: 15.0.4420.1017
Like most developers, I’m pretty lazy. I like to automate things whenever possible so that (a) I don’t have to perform manual steps over and over, and (b) I’m ensuring a certain degree of consistency.
One area where I particularly love automation is SharePoint configuration and administration. It’s extremely frustrating to deploy something to SharePoint, get an error when you know it worked just a couple of days ago, and spend time tracking down the issue only to find you forgot something trivial like activating a feature or putting a setting in a web.config file. Maybe you didn’t have enough coffee that morning? Probably…. at least, that’s what I usually blame it on. :-)
Automation can drastically reduce issues like I just described plus make your life much easier by just running a PowerShell script and letting it do the work for you.
Of course, like most programs that do work for you, PowerShell scripts tend to require a certain amount of configuration as you move them across environments (e.g. development to test) and so on. There’s not really a concept of “app.config” or “web.config” built into PowerShell like we might be accustomed to in the .NET universe. HOWEVER, PowerShell does have the ability to easily read an XML-based configuration file into a strongly typed .NET object (System.Xml.XmlDocument) so you can easily access your settings. This effectively gives you the concept of an app.config or web.config file except you make up your own schema to fit your requirements.
Interested in learning how to do this? Check out a YouTube video I made that demonstrates how to do it.
In the video I walk you through how to use this technique to perform configuration tasks against a site and web application in SharePoint 2013. Enjoy!
I recently had a case where I needed to programmatically determine which zone in my SharePoint 2010 web application had forms-based authentication enabled and then return the public/default URL of that zone.
The reason was a custom application page in SharePoint was sending out emails with links back to SharePoint, and in this case those links needed to always redirect users to the FBA-enabled zone so we send them through a custom login/registration process we’d configured on that zone. Administrators using this custom application page might be accessing the page from one of the non-FBA-enabled zones on the web application – hence the reason to programmatically determine the correct URL to include in the email.
Here’s the code I ended up using to find the URL:
public static string GetFbaZoneUrl(SPWeb web)
string url = null;
foreach (var zone in webApp.IisSettings.Keys)
var settings = webApp.IisSettings[zone];
var fbaProvider = webApp.IisSettings[zone].FormsClaimsAuthenticationProvider;
if (fbaProvider != null)
// We found the zone on the web app where FBA is enabled.
// This is the zone whose URL we want.
SPAlternateUrl fbaUrl = webApp.AlternateUrls.GetResponseUrl(zone, false);
if (fbaUrl != null)
url = fbaUrl.IncomingUrl;
if (url != null && !url.EndsWith("/"))
url += "/";
As you can see in the code, I break from the loop after finding the first FBA-enabled zone in my web application because I know there will never be more than one in my case. If for some reason you have multiple zones configured to use FBA, you could modify this code slightly to return a list of all FBA URLs or filter down to the one(s) you want by some criteria (such as the membership/role provider names). The AlternateUrls property of the SPWebApplication object allows me to grab the response URL (i.e. the default URL) for a given zone.
As a SharePoint developer, I’m a big fan of PowerShell. One of the main reasons I like it is because I can essentially write and test .NET code to work out issues and bugs before I go through the cycle in C# of writing the code, compiling it, deploying it to SharePoint, and then testing it.
In the spirit of sharing development tips and techniques, I published a short video on YouTube demonstrating how I use PowerShell to test and debug CAML queries for SharePoint: http://youtu.be/Umcfew-_92E